Subject: More side issues (Re: Working Group Last Call: GSS-API Domain-Based Service Names and)

From: Nicolas Williams <[email-masked]>
Date: Wed, 23 Aug 2006 12:27:04 -0500

[New thread.  I'm breaking threading.]

On Wed, Aug 23, 2006 at 06:37:25PM +0200, Martin Rex wrote:
> Host-based and domain-based service names are the only names for
> which an application or protocol might perform an endpoint
> identification instead of an authentication by deriving the
> acceptors identity from the network location given by the
> user or caller.

In all cases when the initiator provides a target_name it must have come
from somewhere, and user input is just fine.

Just because historically Kerberos V mechanism implementations have
performed (and some still do) insecure hostname canonicalization does
not mean that using user-provided hostnames is inherently insecure.  (Or
were you making a different point?)

> For other names, it will be generally impossible to substitute
> the authentication with an endpoint identification.

I guess so.  I don't have much experience with acceptors that lack
hostbased service names or other well-known/formed names (think
"kadmin/admin").

> If a mutual authentication is to be performed, then the
> user or caller must know and provide the identity of the
> acceptor to gss_init_sec_context().

Yes.

> Nametype (OIDs) are difficult to memorize and enter by a user and
> nametype OIDs may even be non-portable among independent implementations
> of the same gssapi mechanism -- e.g. with rfc-2025 (SPKM)

That's why we have GSS_C_NT_* symbols associated with name type OIDs.
Yes, I know, given a pluggable GSS-API implementation you could not
count on new name type OIDs being present in the header file (assuming C
bindings) that comes with the pluggable GSS-API framework you're using
and yet the name type may be available through specific mechanism
plug-ins.  In such cases portable applications have a high incentive to
hardcode the constant octet strings whose values are the encoded OIDs
for the desired name types.

I'm not sure I feel too much sympathy -- we're talking about constant
strings.

> Therefore GSS-API v2 permits the use of a NULL nametype
> OID when importing a printable name, which is a request for
> a mechanisms "native" nametype -- for SPKM usually some kind
> of printable distinguished name.

We are aware.  SPKM might want to deal with subjectAltNames, BTW.

> Applications that call gss-api ought to provide a means for the user
> to provide the name that is passed to gss_init_sec_context() and
> is entirely seperate from the network location parameters.

I doubt many users would actually use such a facility, but on principle
I agree.

> Applications should also provide a means to pass along a nametype
> with the name, but they should not require a nametype and they
> should not assume/attach a specific nametype (other than NULL) either.

Here I don't agree.  Standards-Track Internet applications that use the
GSS-API have, do, should and will continue to require support for of
host-based (and now, I hope, domain-based) service names.  They should
NOT preclude use of other name types for acceptors, IMO, but it is
perfectly legitimate to require support for specific name types -- in
some cases it is even legitimate to require use of specific name types.

Examples: SSHv2, DNS GSS-TSIG[1], SASL/GS1 and SASL/GS1 applications.

Interestingly, neither NFSv4 nor RPCSEC_GSS say a word about the subject
(the latter shouldn't, but the former should!).

[1]  GSS-TSIG doesn't say "host-based service names are required"
     directly, but strongly implies it.  Sigh.

Nico
-- 

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten