On Thu, Mar 11, 2004 at 01:52:24PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > We've had this argument before. We continue to disagree. I think we'll > > have to leave it at that for now. I cannot spare the resources at this > > moment and for the short-term to have this argument again. We may have > > this argument again later though. > > > > As a reminder, my position is: > > > > - RFC2743 does not say this > > Those who can read have an advantage. > > Go an reread rfc-2743 Section 1.1.5: Naming > It's a very detailed and explicit requirement!
Again, nothing in sections 1.1.5, 2, 2.4.14, or elsewhere in rfc2743 is explicit about this. BUT, I'll concede that this is implied. Further, I'll concede that GSS_Canonicalize_name() should, indeed, behave as you insist, and as the thread on w2k3 AD canon issues makes clear that it should. When we revise the base specs (and I do believe that we should consider revising the base specs) we should clarify this. Further still, the mechanism requirements doc should also explicitly require that mechanism specs describe how names are to be canonicalized. 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. 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). Cheers, Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== 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]
