Re: Draft available on GSSAPI naming issues

On Tue, Jul 13, 2004 at 03:57:48PM -0400, 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.

Comments:

 - The Abstract starts with a claim that the GSS-API "uses name-based"
   authorization.  This is not so.  Authorization is outside the scope
   of the GSS-API v2u1, though the GSS-API does aim to make name-based
   authorization workable as a lowest common denominator.

   A nit?  Solaris' NFS server (and CITI's) can map GSS-API principal
   names to Unix credentials and authorize clients based on those
   credentials and ACLs that reference Unix UIDs/GIDs; and Windows does
   much the same thing -- so I don't think this is a nit.

   The abstract should point out that name-based authorization is the
   LCD for the GSS-API, that name-based authorization is highly
   problematic (see below), and that generic extensions that facilitate
   authorization based on principals' attributes *other* than their
   names are highly desirable.


 - I disagree with the fourth sentence of the Abstract.  It's always
   been the case that principal names are subject to change, and this
   has been true for all GSS-API mechanisms (including MS' NTLM and
   Sun's DH mechs), as well as for non-GSS security mechanisms.

   It is the fact that names are subject to change, combined with the
   utter lack of any generic mechanism for keeping name-based ACLs up to
   date with name changes that argues against name-based authorization.

   It's important to point out why names change too.  Marriage and
   divorce, as well as other legal name changes are typical reasons, but
   so are user dissatisfaction with their short-form usernames (initial
   misspellings are a typical reason for this), and then there's
   collisions (particularly in flat namespaces) resulting from relating
   to mergers and acquisitions, etc...

   If the GSS-API's mechanisms' canonical names were not based on human
   readable display versions of principal names, but on unique,
   unchanging identifiers intended for machine use then authorization
   based on canonical GSS principal names would not be so bad.  But this
   is not a feasible solution now.

   Another way of stating this is this: canonical names based on display
   forms of principal names, for any security mechanism, including
   non-GSS mechanisms, are of bounded utility, in time, for
   authorization purposes.  Emphasis should be placed on this not being
   a GSS-API-specific problem.


 - That last comment makes me think of possible different approaches to
   this problem, none of which, fortunately, are attractive to me, but
   which might keep existing users of name-based access controls happy,
   such as a method for converting MNs to GSS_C_NT_MACHINE_UID_NAME
   names.  Such an extension would not be fully satisfactory to me, but
   as long as there's an exported name for for GSS_C_NT_MACHINE_UID_NAME
   this might be helpful to anyone who, for whatever reason (e.g.,
   legacy), must cling to GSS-API name-based ACLs.

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]