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

From: Ryan Troll <[email-masked]>
Date: Thu, 9 Aug 2012 14:28:56 -0700

All,

How close does the group feel
draft-ietf-kitten-sasl-oauth-03<http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-03>is
to being submitted to the IESG?

We are preparing to launch OAuth2 support in IMAP and SMTP.  Our current
implementation conforms to this document, with one minor exception - we're
using a slightly different capability name, in order to allow us to launch
prior to this document achieving RFC status.  (Once the RFC is published,
we'll add support for it -- we're taking this approach in case there are
major changes prior to publication.)

-R

---

From: William Mills <[email-masked]>
Date: Thu, 9 Aug 2012 14:47:03 -0700 (PDT)

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'm still working on the Cyrus SASL reference implementation plugin, and it's getting close though I have some bugs to quash.  It'll be interesting to test against a production service.

-bill

>________________________________
> From: Ryan Troll <[email-masked]>
>To: [email-masked] 
>Sent: Thursday, August 9, 2012 2:28 PM
>Subject: [kitten] Status of draft-ietf-kitten-sasl-oauth?
> 
>
>All,
>
>
>How close does the group feel draft-ietf-kitten-sasl-oauth-03 is to being submitted to the IESG?
>
>
>
>We are preparing to launch OAuth2 support in IMAP and SMTP.  Our current implementation conforms to this document, with one minor exception - we're using a slightly different capability name, in order to allow us to launch prior to this document achieving RFC status.  (Once the RFC is published, we'll add support for it -- we're taking this approach in case there are major changes prior to publication.)
>
>
>-R
>_______________________________________________
>Kitten mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/kitten
>
>
>

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 10 Aug 2012 01:24:12 +0200

William Mills <[email-masked]> 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.
>

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 10 Aug 2012 01:28:34 +0200

>   I think you want something similar to section 5.2 in RFC 5802 instead,

Sorry, that should be RFC 5801.  Alternatively, see section 6.1 in RFC 5802.

/Simon

---

From: William Mills <[email-masked]>
Date: Thu, 9 Aug 2012 16:48:16 -0700 (PDT)

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 <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: Ryan Troll <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Thursday, August 9, 2012 4:24 PM
>Subject: Re: Status of draft-ietf-kitten-sasl-oauth?
>

---

From: William Mills <[email-masked]>
Date: Thu, 9 Aug 2012 17:16:54 -0700 (PDT)

So in reading http://tools.ietf.org/html/rfc5801 and teh SAML SASL spec it looks like the gs2-header must appear by itself in a message?  Since we don't have a challenge response  model here it sounds like we have to have the following logic:

1)    client sends gs2-header
2)    server sends an empty reply or fail here if auth won't be permitted because CB is required.
3)    client sends OAUTH mechanism auth request
4)    server replies

So for the non channel binding case we're forced into an empty round trip.  Correct?

-bill

----- Original Message -----
> Cc: "[email-masked]" <[email-masked]>
> Sent: Thursday, August 9, 2012 4:28 PM

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 10 Aug 2012 07:42:17 +0200

William Mills <[email-masked]> writes:

> 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?

Yes, I believe CB should only be advertised/used when it actually
provides some security.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 10 Aug 2012 07:48:51 +0200

William Mills <[email-masked]> writes:

> So in reading http://tools.ietf.org/html/rfc5801 and teh SAML SASL
> spec it looks like the gs2-header must appear by itself in a message? 
> Since we don't have a challenge response  model here it sounds like we
> have to have the following logic:
>

No, the gs2-header can be a prefix of other data, it doesn't have to be
its own message.  Look at the SCRAM/OPENID/SAML20 protocol examples.
Thus OAUTH could look like this (ABNF):

initial-client-response := gs2-header oath-data
oath-data := ...

The important part is that the wire syntax of the OAUTH SASL mechanism
starts with the gs2-header, and that it has the same semantics as GS2.

Note that the gs2-header transfers the SASL authorization identity which
is required by the SASL framework, solving that problem as well.

/Simon

---

From: William Mills <[email-masked]>
Date: Fri, 10 Aug 2012 08:28:09 -0700 (PDT)

I did look at the OPENID example and it does exactly this, and initial gs2-header, the server responds with a challenge.  In fact, looking at http://tools.ietf.org/html/rfc6595 section 5.1 it looks wrong to me in the example, I think it's missing a comma, it has 

    n,,example.org

and there should be 3 commas there?  That said, having re-read this the gs2-header is terminated by a comma so I now see how this 
would work where I did not before.
I specifically did not want to put the authz id outside the OAuth information, because I think that strays too far from the web based OAuth model.  Do you think section 3.2.1 is insufficient?

-bill

>Sent: Thursday, August 9, 2012 10:48 PM

---

From: William Mills <[email-masked]>
Date: Fri, 10 Aug 2012 16:25:17 -0700 (PDT)

In re your comment on 3.4  "Should "authorization scheme" be "application protocol"?", authorization scheme is intended here.  Bearer for example has a SHOULD for TLS so I want to carry that through into this spec.

I'm going to leave off fixing the channel binding stuff until we decide whether it's staying.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 11 Aug 2012 09:26:34 +0200

William Mills <[email-masked]> writes:

> I did look at the OPENID example and it does exactly this, and initial
> gs2-header, the server responds with a challenge.  In fact, looking at
> http://tools.ietf.org/html/rfc6595 section 5.1 it looks wrong to me in
> the example, I think it's missing a comma, it has
>
>     n,,example.org
>
> and there should be 3 commas there?

No, see ABNF from RFC 5801:

    gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
                        ;; The GS2 header is gs2-header.

> That said, having re-read this the gs2-header is terminated by a comma
> so I now see how this would work where I did not before.  I
> specifically did not want to put the authz id outside the OAuth
> information, because I think that strays too far from the web based
> OAuth model.  Do you think section 3.2.1 is insufficient?

SASL requires that the mechanism transfer an opaque authorization
identity without modification from the application protocol to the
server.  The mechanism shouldn't modify it.  See RFC 4422.  If you add a
gs2-header to your initial client response, you are fine and don't have
to think about this any more.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 11 Aug 2012 09:28:32 +0200

William Mills <[email-masked]> writes:

> In re your comment on 3.4  "Should "authorization scheme" be
> "application protocol"?", authorization scheme is intended here. 
> Bearer for example has a SHOULD for TLS so I want to carry that
> through into this spec.

Ah, now I think I understand better the meaning of that paragraph.  I
think this should be a MUST.  There is no sense in using an insecure
over non-TLS transports.  It is like using PLAIN without TLS.

/Simon

---

From: William Mills <[email-masked]>
Date: Sat, 11 Aug 2012 09:10:17 -0700 (PDT)

While I agree with the MUST in principal, I think in various libraries like Cyrus SASL channel binding to TLS isn't solved.  I'm reluctant to make it MUST knowing we're forcing people to make the choice to be non-compliant.

>Sent: Saturday, August 11, 2012 12:28 AM

---

From: William Mills <[email-masked]>
Date: Thu, 16 Aug 2012 09:01:39 -0700 (PDT)

Simon,

On the channel binding stuff I changed the language to refer to the definition in the channel binding spec:

    The channel binding payload is the raw data from the channel binding
    type.  For example, if the client is using tls-unique for channel binding then 
    the raw channel binding data is the TLS finished message as specified in section 

    3.1 of <xref target="RFC5056"/>

I also struck the concept entirely of hashing the channel binding payload if it's large. 

-bill

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Aug 2012 15:09:12 -0500

>     3.1 of <xref target="RFC5056"/>

It's actually RFC5929 that specifies tls-unique.

RFC5056 recommends prefixing the channel bindint type name, ':', to the CB data.

> I also struck the concept entirely of hashing the channel binding payload if

Yeah, don't do that: you end up having to provide hash agility.  The
tls-server-end-point and tls-unique CB types are already fixed-sized
and small anyways.

Nico
--

---

From: William Mills <[email-masked]>
Date: Thu, 16 Aug 2012 15:58:44 -0700 (PDT)

Fixed the RFC reference, thanks.

> From: Nico Williams <[email-masked]>
>Cc: Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Thursday, August 16, 2012 1:09 PM
>Subject: Re: [kitten] Channel binding language changes Re: Status of draft-ietf-kitten-sasl-oauth?
>

---

From: [email-masked] (Martin Rex)
Date: Fri, 17 Aug 2012 02:19:15 +0200 (CEST)

> tls-server-end-point and tls-unique CB types are already fixed-sized

Uh-oh, that latter information is incorrect.

tls-unique is _not_ fixed-size (the way I understand this term).

It's 36 octets for SSLv3, 12 octets for TLSv1.0 & TLSv1.1, and officially
ciphersuite-dependent for TLSv1.2 (with a default size of 12 octets).

-Martin

---

From: William Mills <[email-masked]>
Date: Thu, 16 Aug 2012 17:30:28 -0700 (PDT)

Good to know, but won't affect the OAUTH SASL spec I think.

> From: Martin Rex <[email-masked]>
>To: Nico Williams <[email-masked]> 
>Cc: William Mills <[email-masked]>; "[email-masked]" <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Thursday, August 16, 2012 5:19 PM

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Aug 2012 21:00:46 -0500

> ciphersuite-dependent for TLSv1.2 (with a default size of 12 octets).

Yes, I know, and tls-server-end-point too can vary in size.  But for
any one case the size is fixed and small, and what matters here is
that they're small.  You're right that one should not count on them
being fixed-sized.