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 PROTECTED]
