Re: [kitten] On SASL's authzid

[Bill Mills <[e-mail]>]

Option #1 is almost where we are now.  Just need to steal your second paragraph above and explain the potential duplicate authzid if a GS2 mechanism is defined.



On Monday, March 10, 2014 6:14 PM, Nico Williams <[e-mail]> wrote:
 
On Mon, Mar 10, 2014 at 7:58 PM, Bill Mills <[e-mail]> wrote:
> Examples in
> http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14#section-4
>
> Does that answer your question?

Yes!

You have two options that are equivalent, and you need only choose
whether you want to describe a GSS mechanism that can be used as a GS2
mechanism, or a SASL mechanism from which one could derive a GSS
mechanism that interops with the SASL one when used in a GS2
framework.

In the first case all you have to say is that the tokens start with
the GS2 header, and that if there's an authzid it will appear twice,
once in the a= attribute in the GS2 header, and once in a user=
attribute past the GS2 header.

In the second case you'd say that the OAuth GSS mechanism's
GSS_Init_sec_context() outputs a token as it would look without the
GS2 header, and that if the initiator name had an authzid set then
this is sent as user=<authzid>.  Then automatically when this
mechanism is used in SASL via GS2 SASL will add the a=<authzid>, and
if the GS2 implementation knows to set the GSS authzid attribute then
it will also appear as user=<authzid>.

If you do the latter you'll need to reference:

http://tools.ietf.org/html/draft-williams-kitten-impersonation-naming-attr-00

The obvious choice is the first: it's easier on you.  It's pretty much
what we did with SCRAM, with just a smidgen of text saying GSS-related
things for anyone who wanted to implement SCRAM as a GSS mechanism
used in a SASL GS2 framework.


Nico
--