Re: Draft available on GSSAPI naming issues

Sam,

Sam Hartman wrote:
> 
> Please take a look at
> http://www.ietf.org/internet-drafts/draft-hartman-gss-naming-00.txt.
> This describes problems I see with GSSAPI's naming architecture and a
> proposal to solve these problems.  I will be presenting at the BOF
> meeting.
> 
> I'm particularly interested in things I've missed in the problem
> description or other open issues that I failed to mention.

There are zero problems with existing GSS-API naming.

I have three major problems in the above document:

 (1) it fails to distinguish authentication from authorization.

     In the past I have seen two proposals to extend GSS-API
     authentication with an API for authorization
     (presented in CAT wg sessions at IETF meetings),
     one was XGSS-API from the SESAME project and the other
     one was "GAA" (Cliff?)

 (2) it fails to recognize where existing infrastructures deliberatly
     abuses the underlying protocol (e.g. Microsoft entirely ignores
     the Kerberos name-based authentication and uses a proprietary
     extension to convey authentication and authorization information).

 (3) it fails to realize that *ALL* access control schemes require
     a canonical representation of either the identity or some
     standarized authorization information in order to work.

     On Microsoft platforms the "canonical" name appears to be a "SID",
     which is what gets stored in their (D)ACLs.  The printable representation
     of a SID is a "SAM account name" (LanManager style).


The provision of GSS-API to (pre-)populate ACLs using
gss_import_name()+gss_canonicalize_name()+gss_export_name() is
absolutely necessary.  Btw: It is extensible since gss_canonicalize_name()
already requires a (mechanism) OID input parameter as a hint what kind of
transformation is required.

I don't see a problem in defining mechanism- or environment-specific
OIDs which can be used to draw a canonical name from a particular
namespace -- or alternatively from some kind of authorization data.

But don't fall prey to illusions, any such approach is no longer
a general abstraction.  It will actually turn out to be extremely
implementation specific.  The acceptor would have to use
gss_canonicalize_name() on the src_name returned from
gss_accept_sec_context() upon successful authentication in order
to transform the name to the alternative namespace (currently no
gssapi-based server needs to do that).  Keep in mind that the
authentication may be successful, but a transformation of the
identity into a particular namespace or authorization space
may fail for all sorts of reasons.

Personally I think it would be perfectly OK to allow to extend
the use of gss_canonicalize_name() for arbitrary namespaces,
maybe even for authorization elements (since the app caller needs
to be explicitly aware of the OIDs anyway).  But I don't think
that this will have an impact on PORTABLE gssapi callers that
use gssapi for the purpose of **abstraction** in heterogeneous
environments.


Just take Microsoft's abuse of the Kerberos 5 protocol as an
example.  We do have several customers that use a Microsoft
W2K Active Directory for user management but run their servers
on Unix machines with a (mostly vanilla MIT Kerberos) that only
supports name based authentication.  The server side implementation
doesn't implement/understand Microsoft's proprietary extensions,
therefore the only namespace available for authentication is
that of the base Kerberos 5 protocol -- name-based authentication
of Kerberos principals.  And it is likely to remain like this
for some time, I assume.  HP-UX 11.11 seems to include an
implementation of MIT Kerberos v1.1 today.


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