Re: [kitten] -06 posted Re: requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05

[Simon Josefsson <[e-mail]>]

William Mills <[e-mail]> writes:

>>3.1.  Initial Client Response
>>
>>   [...] The client MUST send an authorization ID in the gs2-header.
>>
>>Is this MUST intentional?  Normally authorization identities are not
>>asserted in SASL so this would be unusual.  I would remove this
>>sentence.
>
> Yes, because we want to have the plain text username available.

The SASL framework doesn't have any concept of usernames, so if you want
to transfer a "username" from the client to the server you need a
separate field for that in the mechanism.  SCRAM does this, so that is
an acceptable route.  However, I'm not certain you actually mean
"username" here.  Maybe you really mean authorization identity?  Or do
you mean the authentication identity?  Sometimes usernames and
authentication identities are used interchangeable but I'm not certain
this is the case here.

The SASL framework says the authzid is optional and that it is asserted
by the client application.  It shouldn't be used for something mechanism
internal.

I'll see if I can re-read Ryan's motivation for the username field.  I'm
thinking that perhaps he is really after an authzid field, and if the
authzid field is not present, he has to guess which authorization
identity is intended (or fail if he cannot guess).  I believe this usage
would be in line with the SASL model, although would require some user
training because users normally doesn't specify an authzid.  That's fine
though.  This approach is consistent with the protocol syntax in -06,
but the text describing how the syntax should be used is a bit off
currently.  So I don't think you actually want a username field, just
fix some text.

>>3.2.1.  Mapping to SASL Identities
>>
>>   Some OAuth mechanisms can provide both an authorization identity and
>>   an authentication identity.  An example of this is OAuth 1.0a
>>   [RFC5849] where the consumer key (oauth_consumer_key) identifies the
>>   entity using the token which equates to the SASL authentication
>>   identity, and is authenticated using the shared secret.  The server
>>   MAY use a consumer key, a value derived from it, or other comparable
>>   identity in the OAuth authorization scheme to allow SASL an
>>   authentication identity different from the authorization identity to
>>   be set.
>>
>>The OAuth 1.0a example in the second sentence seems to be missing
>>something: it describes how OAuth 1.0a provide an authentication
>>identity, but it does not describe how OAuth 1.0a provides for an
>>authorization identity as far as I can tell?  Adding a sentence after
>>the second, that describe how OAuth 1.0a provides an authorization
>>identity would help, and may help me understand the last sentence which
>>I can't understand the meaning of right now.
> The last sentence of 3.2 above 3.2.1 is "The authorization scheme MUST 
> carry the user ID to be used as the authorization identity (identity to 
> act as). The server MUST use the ID obtained from the credential as the 
> user being authorized."
>
> Should that sentence move into 3.2.1?

I must admit that the sentence doesn't make sense to me.

The (SASL) authorization identity should be transferred from client to
server without modification (modulo character set encodings).  It is
asserted by the client and consumed by the server.  Usually it is not
related to the credential type at all.

Thus, saying that another field in the credential MUST be used as the
SASL authorization identity seems quite far from how the SASL framework
is designed.  I don't see why you would design it this way -- it seems
overly complex for no gain that I have understood so far.

Hmm.  Perhaps at this point it would be more productive if one of us
usual GSSAPI/SASL suspects modify your draft into something that makes
sense in the GSSAPI/SASL model and then you can check if it works for
you in the OAuth world?

>>5.2.  OAuth 1.0a Authorization with Channel Binding
>>...
>>   y,a=[e-mail]^A
>>...
>>
>>This uses a gs2-header cb-type of 'y' -- this seems wrong.  If channel
>>bindings are used (which is indicated by clients and servers having the
>>OAUTH10A-PLUS mechanism type available), the cb-type should be 'p' and
>>the cb type identifier should be present.  Recall the meaning of "y"
>>from RFC 5801:
>>
>
> I *KNEW* I had to have gotten something wrong in CB.  Will fix that.

Great.  I suggest to use the 'tls-unique' channel binding type, it is
what SCRAM and GS2 prefers, with a fallback to 'tls-server-end-point'.
Compare section 6.1 of RFC 5802.  You probably need a similar section in
this document.

/Simon