On Wed, Mar 10, 2004 at 11:59:33PM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> > I'm not sure what you mean by name games, but I'm guessing that you
> > don't like the desired names (both, of credentials and the
> > requested target name in GSS_Init_sec_context()) to differ from what is
> > returned by GSS_Inquire_context().
>
> No, it is different (more complex):
>
> Assuming that
> name1 = gss_import_name("some printable name")
> ctx = gss_init_sec_context(target_name=name1)
> name2 = gss_inquire_context(target_name)
>
>
> GSS-API does *NOT* require that the name that gss_inquire_context()
> returns (visualized via gss_display_name()) looks character for character
> like the name that was passed to gss_import_name().
>
> What GSS-API v1 and v2 require is that gss_compare_name(name1,name2)
> will return TRUE when name1 was the input of gss_init_sec_context() and
> name2 was the output of gss_inquire_context().
>
> What GSS-API v2 additionally requires is that
> (1) gss_export_name(gss_canonicalize_name(name1)) results in the same binary
> blob as (2) gss_export_name(name2), simply because (1) will be used
> to (pre-)populate a access control list and (2) will be used to match
> authenticated users against that access control list.
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
- That anyone making ACLs from exported names must use canonical names
as the input to GSS_Import_name() to get the behaviour you say is
required. Not only that, they can be expected to know what those
canonical names are.
That said, I may be open a canonicalization service for the Kerberos V
mechanism in the future. But I don't agree that one is needed in order
to support name canonicalization during context setup.
> > Sam means that designing GSS-API mechanisms is too hard, so folks are
> > designing SASL mechanisms instead when we'd all really rather they
> > design GSS-API mechanisms.
> >
> > Sam is proposing, and I second this, that a document be written offering
> > guidelines to mechanism designers.
>
>
> A BCP document? That would probably be helpful.
More or less.
> But it takes quite a lot of time to get an overview about
> current implementation practice. Kerberos5 and even Grid is
> only a small piece of the whole picture.
This isn't about implementation. It's about mechanism design.
Look at how the SPKM and Kerberos specs dealt with name types. The
Kerberos V mech spec (rfc1964, and now CFX) got it right, the SPKM spec
got it wrong and is in need of major clarifications with respect to
naming. This document would help, we hope, prevent such errors in the
future.
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]
