Re: [kitten] Status of draft-ietf-kitten-sasl-oauth?

[William Mills <[e-mail]>]

Simon,

Thanks for the review!

Re: SASL entities: That's covered in 3.2.1 I hope.

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 authorization identity in the OAuth 1.0a case is carried in the token (per the requirement above), which SHOULD be validated independently. The server MAY use a consumer key, a value derived from it, or other comparable identity in the OAuth authorization scheme as the SASL authentication identity.  If an appropriate authentication identity is not available the server MUST use the authorization identity as the authentication identity.


Re: GS2 header:   I'll go read up on this, I hope it's easy :)



Re: Channel Binding:  


Quite frankly I'd like to rip it out, but I was told originally it was required.  I think the stance in the group on this has changed, but I'm not sure.  It is certainly vulnerable to MITM in the Bearer case.  An option would be to limit CB to usage when we have an auth profile that supports signing.  Does it need to stay at this point?

Regards,

-bill

>________________________________
> From: Simon Josefsson <[e-mail]>
>To: William Mills <[e-mail]> 
>Cc: Ryan Troll <[e-mail]>; "[e-mail]" <[e-mail]> 
>Sent: Thursday, August 9, 2012 4:24 PM
>Subject: Re: Status of draft-ietf-kitten-sasl-oauth?
> 
>William Mills <[e-mail]> writes:
>
>> There hasn't been a lot of action in any substantive way on the list
>> on this draft, and I think it's pretty well baked.  A working
>> implementation is going to go a long way to nailing this down.
>>
>> Anyone out there with any significant objections or proposed should
>> speak up "real soon now". 
>
>I have reviewed the -03 document, and I believe there are some major
>issues with it.
>
>MAJOR:
>
>* The protocol does not appear to be compatible with the GS2 framing,
>  thus the GSS-API mechanism the document defines would not be
>  wire-compatible with the SASL mechanism.  The SASL packets needs to
>  use the GS2 header to be compatible.  The examples reinforces my
>  readings, they don't begin with the GS2 header.  Compare the SCRAM,
>  OPENID and SAML20 mechanism to see how this should be done.
>
>* I don't see where the mechanism transfers the SASL authorization
>  identity, which is required.  This would be done by the GS2 header.
>
>* I don't follow how the channel binding data is integrity protected.
>  Unless I'm missing some keying, this seems to open up for a MITM to
>  fake channel binding.  Section 3.2:
>
>    In the OAUTH-PLUS mechanism the server examines the channel binding
>    data, extracts the channel binding unique prefix, and extracts the
>    raw channel biding data based on the channel binding type used.  It
>    then computes it's own copy of the channel binding payload and
>    compares that to the payload sent by the client in the cbdata key/
>    value.  Those two must be equal for channel binding to succeed.
>
>  Presumably the client is not authenticated when this is sent, so the
>  server might as well be talking to an attacker, which sends its own
>  channel binding data.
>
>  I'm not sure I see how OAuth with bearer tokens could support channel
>  bindings at all?
>
>* Section 3.4 seems confusing.  Quoting:
>
>    If the specification for the underlying authorization scheme requires
>    a security layer, such as TLS [RFC5246], the server SHOULD only offer
>    a mechanism where channel binding can be enabled.
>
>  Should "authorization scheme" be "application protocol"?
>
>  Quoting further:
>
>    The channel binding data is computed by the client based on it's
>    choice of preferred channel binding type.
>
>  I think you want something similar to section 5.2 in RFC 5802 instead,
>  to leave the choise of preferred channel binding type up to the
>  application protocol profile (or resume back to a default).
>
>    If the raw channel binding data is 500
>    bytes or larger then a SHA-1 [RFC3174] hash of the raw channel
>    binding data is computed.
>
>  SHA-1?  This opens up for hash agility concerns.
>
>    If the client is using tls-unique for a channel binding then the raw
>    channel binding data equals the first TLS finished message.
>
>  There is subtlety with renegotiation here, I suggest to quote RFC 5929
>  instead.
>
>/Simon
>
>
>