Re: Draft available on GSSAPI naming issues

>>>>> "Martin" == Martin Rex <[email protected]> writes:

    Martin>  (1) it fails to distinguish authentication from
    Martin> authorization.

Really?  Pointers on where I got this wrong would be appreciated; I
agree with you that this distinction is critical and I'd certainly
like to correct any errors I made in this regard.

I don't think the draft talks much about authorization; it talks a lot
about making certain authentication assertions (or parts of names)
available for authorization decisions.

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

I certainly remember GAA.  I was not really around for XGSS.

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

I actually believe I do discuss Microsoft's PAC.  You're right that I
assume the reader is roughly familiar with the contents of the PAC
already; I can certainly add a bit more background to this section of
the draft.

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

OK, then the draft is unclear.  The entire point of the draft is that
you need such representations.  The problem seems to be that there
will be multiple representations available and different applications
will require different representations.

I actually like your proposal of expanding gss_canonicalize_name to
deal with environment-specific OIDs.  I don't think it fully solves
the problem though, because it doesn't deal with composite identities
like subjectAltName extensions or like group memberships.  Let's say
we define an oid that when passed into gss_canonicalize_name gives us
a representation of all the sids associated with some name in the
Microsoft authorization model.  I don't really want to put that
representation on an ACL because the account might gain or lose group
memberships and thus gain or lose sids. Instead I somehow want to put
a representation of a single sid corresponding to some group on the
ACL.  Later, when I try and authorize some previously-authenticated
context, I want to find out if the identity corresponding to that
context has that single group sid as part of its name.

With your proposal, an application wanting to do this sort of
authorization would need to understand the representation of the
sid-based name and decompose that representation.

With name attributes it seems like you could define a multi-valued
attribute for group membership and see if the name in the context
contained the value for this attribute corresponding to SId placed on the ACL.

--Sam
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]