Re: Draft available on GSSAPI naming issues

On Tue, Jul 13, 2004 at 11:14:33PM +0200, Martin Rex wrote:
> 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 agree with your comment -- there's nothing wrong with the GSS-API's
naming.

Name-based authorization is really problematic though, and in a way that
transcends the GSS-API.

Please read the comments I just posted.  I think some extensions to the
GSS-API can be made that will greatly improve authorization in
applications by moving beyond the use of canonical names based on
display forms that are subject to change at any time.

> I have three major problems in the above document:
> 
>  (1) it fails to distinguish authentication from authorization.

It doesn't have to.  The GSS-API handles authentication.

>  (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).

It doesn't have to.  The basic problem with name-based authorization
transcends the GSS-API and its mechanisms (see above and my other post
just now).

>  (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).

But a user may have multiple SIDs (a primary user SID, a primary group
SID and additional user and group SIDs).  The primary user SID can be
considered a canonical name, yes, and maps onto the
GSS_C_NT_MACHINE_UID_NAME name type, but the GSS-API provides no way to
get the GSS_C_NT_MACHINE_UID_NAME that corresponds to a
GSS_C_NT_USER_NAME (or vice-versa -- but the reverse might not be a
one-to-one mapping!).

We MUST at the very least have a way to convert names of one type to
another, where that is feasible.

I'm sure you'll agree that authorization by UID or SID is much better
than by name -- the former change much less frequently than the latter
and non-reuse of the former is a typical policy in many organizations.

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

But GSS_Canonicalize_name() has no nametype OID parameter.  If it had
both, a mech OID and a nametype OID, or if GSS_Display_name() had an
optional display-as-other-nametype OID parameter then name-based
authorization, using GSS_C_NT_MACHINE_UID_NAME names, would be a lot
less problematic.

I'll stop here.  I consider this nametype conversion idea an olive
branch.  I do prefer the name attribute interface that Sam's draft
describes however, as that would allow for access to principals' group
membership information, and so one, in a fairly generic manner.

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]