Subject: Re: KITTEN BOF at IETF 60?

From: Martin Rex <[email-masked]>
Date: Fri, 23 Apr 2004 21:37:11 +0200 (MET DST)

Nicolas Williams wrote:
> 
> Further still, the mechanism requirements doc should also explicitly
> require that mechanism specs describe how names are to be canonicalized.

Of course, the mechanism spec should describe how names are
to be canonicalized and it should standardize the format of
the binary canonical exported name, so that ACLs are not implementation-
specific but mechanism-specific, which is called "portability" at
the API level.

> 
> We should also add text to the base spec's Security Considerations
> section about the perils of name-based authorization, specifically the
> referential integrity problems that arise when principals are
> renamed/deleted or principal names reused.
> 
> An optional facility to obtain internal identifiers for principals
> should be provided, as internal identifiers rarely change (indeed, many
> organizations ban the reuse of internal identifiers, such as POSIX UIDs
> or GIDs, Windows RIDs, etc...).  Some platforms, including Solaris, for
> example, already have such a facility, but a generic interface that can
> be used by portable applications is, IMO, highly desirable.
> 
> I'm also willing to consider the possibility of allowing new mechanisms
> to not support the notion of canonical names provided that: a)
> GSS_Canonicalize_name() and GSS_Export_name() fail for such mechanisms,
> and b) that a facility for obtaining the internal identifier(s)
> associated with principals is provided.

GSS-API v2 defines "binary" canonical names, not printable canonical
names.  That was done so that internal identifiers can be used for
mechanisms that universally support them.  Unfortunately Kerberos
is not one of them, the true Kerberos 5 authentication is strictly
name-based and both kerberized and gss-api based applications
could always rely on (and actively do) that the Kerberos principal
name found inside the ticket of an AP_REQ is canonical and can
be used for access control and authorization decisions.

> 
> I'm also interested in other name-related extensions, specifically an
> interface by which one could query the mechanism of an MN and an
> interface by which one could query whether a given MN is compatible with
> a given name type (e.g., a krb5 MN that originally derived from
> GSS_C_NT_HOSTBASED_SERVICE may display as GSS_C_NULL_OID or
> GSS_KRB5_NT_PRINCIPAL_NAME, but it would be nice to know that it is a
> name for what qualifies as a hostbased service).

Huh?

rfc2743 2.4.4 GSS_Display_name call

   The GSS_C_NO_OID name type is to be returned only when the
   corresponding internal name was created through import with
   GSS_C_NO_OID. It is acceptable for mechanisms to normalize names
   imported with GSS_C_NO_OID into other supported types and, therefore,
   to display them with types other than GSS_C_NO_OID.

Otherwise, gss_display_name() must ALWAYS return an explicit
nametype OID (if the output parameter is requested).

*I* requested that gss_display_name() should be allowed to GSS_C_NO_OID
for this special case.  No other GSS-API call was ever allowed to
return GSS_C_NO_OID in an OID output parameter on successful return.
Check rfc2078 and rfc1508, they don't have this exemption.

-Martin
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]