Nicolas Williams wrote:
>
> I myself have no intention whatsoever to change or remove either
> gss_canonicalize_name() or gss_export_name() or the format of exported
> names.
>
> I'm too busy for now to fully engage in any debate in this area and,
> frankly, I don't care to get into this at all, as I don't think these
> functions need any changes -- clarifications at most.
I'm glad to read that.
>
> 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.
Now what this all effectively requires is that any kind of KDC-based name
canonicalization must be available without security context establishment,
and I guess this can only be done if a new kind of communication with
the KDC is invented (and it will likely require to secure this
communication as well).
I have only briefly glimmed at DCE, but I'm pretty sure such functionality
is available. Although similar functionality should be theoretically
available with Microsoft's Active Directory, it is either incomplete
or broken or both.
>
> 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.
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.
-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]
