Subject: Re: [kitten] Identities Re: Comma vs. %x01 Re: OAuth SASL draft -05

From: [email-masked] (Martin Rex)
Date: Thu, 20 Sep 2012 23:53:41 +0200 (CEST)

(still trying to catch up on old emails...)

I agree with Nico that a GSS-API mechanism spec is supposed
to specify the representation of native name form and of a
canonical exported (binary) name token.

But that name is really about identity and authentication,
not (fine-grained) authorization.  Microsoft conveys fine-grained
authorization information in a "PAC" inside the ticket, but none
of that is visible at the naming/identity level.  (that would also
not be compatible with the Kerberos gssapi mechanism rfc1964/rfc4121).

How the application manages authorization is up to the application.
When a gssapi mechanism works as part of the TCB (trusted computing base),
then it is possible to have the TCB perform access control for access
to system objects -- at least when the incoming autorization info
is meaningful to the local TCB (which is not necessarily the case,
and often limited to "within-organization" communication).

Creating a name by concatenating (fine-grained) authorization information
to me looks like a problem, rather than a solution to anything,
because that information is opaque for ACLs built with the exported
name token.  Any change in any of the fine-grained authorization
attributes would cause all ACL entries based on exported names to
no longer match (require them to be updated), which does not look
like the desired outcome of fine-grained ACL management.

I believe, access to fine-grained authorization data should be done
through TCB or additional GSS-API calls (gss_get_name_attribute),
but not affect the regular name (neither exported, nor display name).

-Martin

Nico Williams wrote:
> On Tue, Aug 28, 2012 at 11:34 PM, William Mills <[email-masked]> wrote:
> > Just to be clear it is possible in OAuth to have *both* a client ID which
> > would equate to an authZ ID and a ID in the token which would be an authN
> > ID.   All this info might be carried in a Bearer token, or explicitly called
> > out in OAuth 1.0a as the oauth_client.  If the client ID represents
> > something  like a desktop client it (i.e. Flickr Uploadr client and mobile
> > clients now) then that ID isn't probably really useful because it's
> > effectively a user agent.  On the other hand it might be the client ID of a
> > 3rd party in a 3 legged relationship, in which case it really is what we
> > want.  I was leaving that the to the server to determine.
> 
> If OAuth itself can carry an authz-id and its semantics are not
> *exactly* the same as the semantics of SASL authz-id, then it's best
> to not try to conflate the two.  I'm assuming that the semantics of
> the two are in fact different.
> 
> The gs2-header should carry the SASL authz-id and nothing more, and
> you should say nothing about this.
> 
> What I do think needs to be covered is the display/exported name forms
> of OAuth clients.  Because we don't want to lose fine-grained authz
> data, and because fine-grained authz data is OAuth's raison d'etre,
> you should specify a name form that preserves (encodes) all that authz
> data.  If OAuth has an internal authz-id concept then this is where
> that authz-id would show up.
> 
> When I say "display/exported name form" I'm really referring to
> GSS-API concepts.  In GSS we have names represented as opaque objects
> -- NAME in the abstract API, gss_name_t in the C bindings -- and these
> names can be queried.  For example, you would apply GSS_Display_name()
> to a NAME to find its display form, and you'd apply GSS_Export_name()
> to obtain its "exported name token" (an octet string) form.  You'd
> call GSS_Import_name() with either a string and a name-type to get a
> NAME, or with an exported name token and a special name-type
> (GSS_C_NT_EXPORTED_NAME).  SASL/GS2 says very little about this...
> 
> Now, normally a GSS mechanism would authenticate users and services to
> each other, and if there is additional fine-grained authorization data
> delivered by the mechanism, then that is to be accessed via
> GSS_Get_name_attribute() and friends.
> 
> In this case I think you could argue that because OAuth's entire
> purpose is to deliver fine-grained authz data the display and exported
> name forms of OAuth names must encode that data.
> 
> See my other reply showing some sample OAuth names.
> 
> Nico
> 
> PS: The query/display/exported name forms of a GSS mechanism are one
> of the key things to document when specifying a GSS mechanism.  Since
> OAuth would be a GSS mechanism, this is something that must be
> covered.
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten