Subject: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02

From: "William J. Mills" <[email-masked]>
Date: Fri, 8 Apr 2011 00:32:13 -0700 (PDT)

All,

I have added channel binding to OAUTH mechanism draft.  I would very much appreciate someone that knows CB giving it a read to make sure I'm on the right track.  Significant changes in this draft:

-   Added channel binding
-   Updated security considerations
-   Added language specifying how to map identities in OAuth to identities in SASL.
-   Updated examples

Thanks,

-bill mills

----- Forwarded Message -----
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Cc: [email-masked]; [email-masked]
Sent: Friday, April 8, 2011 12:05 AM
Subject: New Version Notification for draft-mills-kitten-sasl-oauth-02 

A new version of I-D, draft-mills-kitten-sasl-oauth-02.txt has been successfully submitted by William Mills and posted to the IETF repository.

Filename:     draft-mills-kitten-sasl-oauth
Revision:     02
Title:         A SASL Mechanism for OAuth
Creation_date:     2011-04-08
WG ID:         Independent Submission
Number_of_pages: 22

Abstract:
Simple Authentication and Security Layer (SASL) is a framework for
providing authentication and data security services in connection-
oriented protocols via replaceable mechanisms.  OAuth is a protocol
framework for delegated HTTP authentication and thereby provides a
method for clients to access a protected resource on behalf of a
resource owner.

This document defines the use of HTTP authentication over SASL, and
additionally defines authoriation and token issuing endpoint
discovery.  Thereby, it enables schemes defined within the OAuth
framework for non-HTTP-based application protocols.  A future version
of this document will describe the integration into the Generic
Security Services Application Program Interface (GSS-APIO).

The IETF Secretariat.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 08 Apr 2011 10:26:25 +0200

"William J. Mills" <[email-masked]> writes:

> All,
>
> I have added channel binding to OAUTH mechanism draft.  I would very
> much appreciate someone that knows CB giving it a read to make sure
> I'm on the right track.  Significant changes in this draft:

This is great!

   Channel binding [RFC5056] in this mechanism is defined in order to
   allow satisfying the security requirements of the authorization
   schemes used.  This document defines the "OAUTH-SSL" mechanism to
   provide TLS channel binding [RFC5929] to the OAUTH mechanim, and
   specifically the "tls-unique" type of channel binding.

The intention is that tls-server-end-point is not permitted at all,
right?  Perhaps it is clearer to have the last sentence say

   This document defines the "OAUTH-SSL" mechanism to provide the
   "tls-unique" TLS channel binding [RFC5929] to the OAUTH mechanim.

      cbdata (REQUIRED):  Contains the base64 encoded first TLS Finished
         message sent.

Don't mention the Finished message here, people have gotten the details
wrong before and the gory details (including people's mistakes) are in
RFC 5929.  Say instead:

      cbdata (REQUIRED):  Contains the base64 encoded "tls-unique"
         channel binding data.

Otherwise it looks good.  I'm tempted to have a go at implementing this
in GNU SASL actually. :-)

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 08 Apr 2011 10:36:43 +0200

Btw, you may want to update your example with something real.  Replace

GET /?cbdata="SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=" HTTP/1.1

with

GET /?cbdata="yYPi2+ohQa/xwhJH" HTTP/1.1

Btw should the quotes really be there?  I.e., shouldn't it be:

GET /?cbdata=yYPi2+ohQa/xwhJH HTTP/1.1

Btw, have you considered the issue with URL escaping of + and /?  Maybe
you want to use the URL-safe Base64 alphabet instead to avoid that
issue?  Just reference RFC 4648 and "base64url".

Thanks,
/Simon

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Apr 2011 12:36:01 -0400

I'm confused.
Why does the oauth sasl mechanism want to restrict what channel binding
types are permitted?
Also, why the desire to require tls-unique instead of
tls-server-endpoint?
The tls-server-endpoint channel binding type is easier to implement.

---

From: "William J. Mills" <[email-masked]>
Date: Fri, 8 Apr 2011 10:31:42 -0700 (PDT)

At the moment I was going with simple.  If multiple types are supported then I have to be able to communicate what types of channel binding are accepted, which I suppose could go in the WWW-Authenticate header in the discovery information.  It's relatively easy to add a variable for the CB type.

If tls-server-end-point is easier to implement I'm happy to pick that one, subject to limiting to a single CB type.  

My thought was that if the service is offered over another secure channel then OAUTH-SSH could be defined for channel binding to SSH.

-bill

________________________________
From: Sam Hartman <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: William J. Mills <[email-masked]>; "[email-masked]" <[email-masked]>; Tim Showalter <[email-masked]>
Sent: Friday, April 8, 2011 9:36 AM
Subject: Re: [kitten] Fw: New Version Notification for  draft-mills-kitten-sasl-oauth-02

I'm confused.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Apr 2011 13:36:16 -0400

>>>>> "William" == William J Mills <[email-masked]> writes:

    William> At the moment I was going with simple.  If multiple types
    William> are supported then I have to be able to communicate what
    William> types of channel binding are accepted, which I suppose
    William> could go in the WWW-Authenticate header in the discovery
    William> information.  It's relatively easy to add a variable for
    William> the CB type.

I don't think this is true if you're a SASL mechanism.
I think that's the application's problem.
I think all you have to do is communicate  the channel binding type you
support.

Also, the abstract interface between the application and SASL assumes
that all SASL mechanisms supporting any CB types support all CB types.
This is even more true if you happen to be running through a GS2 bridge
which may not be applicable to your mechanism.

I promised Hannes at the meeting that near end of April I'd be happy to
get up to speed on this and work with the draft authors on all this.

I'm sorry I don't have time to do that this week or next but I'll get
there.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Fri, 8 Apr 2011 17:44:37 +0000

> I think all you have to do is communicate  the channel binding type you

I think you mean "the type you used", at least based on  my reading of GS2.

On the general subject of tls-unique vs. endpoint, I had a brief conversation with Simon about it, and I think some clarification on how server applications would be expected to use tls-endpoint would be useful.

How is it expected that servers would distinguish clients at the app layer when non-unique CB is used?

-- Scott

---

From: "William J. Mills" <[email-masked]>
Date: Fri, 8 Apr 2011 10:47:01 -0700 (PDT)

OK, I've taken a note in my working copy to switch to -PLUS.  I also need to add communicating the CB variant.

Thanks very much for your first look and I look forward to further feedback.  Would it be useful for me to make these changes now and post a new draft, or is that too much churn?

-bill

________________________________
From: Sam Hartman <[email-masked]>
To: William J. Mills <[email-masked]>
Cc: Sam Hartman <[email-masked]>; Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]>; Tim Showalter <[email-masked]>
Sent: Friday, April 8, 2011 10:36 AM
Subject: Re: [kitten] Fw: New Version Notification for  draft-mills-kitten-sasl-oauth-02

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Apr 2011 14:53:24 -0400

>>>>> "Cantor," == Cantor, Scott E <[email-masked]> writes:

    >> I think all you have to do is communicate the channel binding
    >> type you support.

    Cantor,> I think you mean "the type you used", at least based on my
    Cantor,> reading of GS2.

I do.

    Cantor,> On the general subject of tls-unique vs. endpoint, I had a
    Cantor,> brief conversation with Simon about it, and I think some
    Cantor,> clarification on how server applications would be expected
    Cantor,> to use tls-endpoint would be useful.

Probably.

    Cantor,> How is it expected that servers would distinguish clients

I'd expect that is what the SASL authentication is for.
(Note that HTTP is more complex; you need cookies or some other
distinguisher there).

In something like IMAP, at the end of SASL, we have:

1) Client did mutual auth with server. It knows that the server at the
other end of the TLS exchange with a given certificate is the party
named in the SASL exchange.
It knows that a particular TLS connection reaches that party.

2) Server knows that  the client is as named in the SASL exchange.
Server also knows that the client believes that the party identified by
the particular endpoint CB is the only party besides the client involved
in the TLS exchange.

One critical part of #2 is that if the client didn't confirm the channel
binding, the client would have given up rather than starting  the SASL
authentication.

Unless I'm missing something (wouldn't be the first time) I think 1 and
2 are sufficient for a non-HTTP use case.

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Apr 2011 14:20:53 -0500

On Fri, Apr 8, 2011 at 12:31 PM, William J. Mills <[email-masked]> wrote:
> At the moment I was going with simple.  If multiple types are supported then
> I have to be able to communicate what types of channel binding are accepted,
> which I suppose could go in the WWW-Authenticate header in the discovery
> information.  It's relatively easy to add a variable for the CB type.

Not caring about CB type is simple.  Checking the CB type is not
simple, particularly since the mechanism can't really know what CB
type is being used.  Yes, RFC5056 says apps should prefix the CB data
with the type name, but that's NOT something that a mechanism should
ever rely on.

> My thought was that if the service is offered over another secure channel
> then OAUTH-SSH could be defined for channel binding to SSH.

The mechanism should not care what type of CB data is being used.  The
mechanism should limit itself to ensuring that the CB data are the
same on the initiator and acceptor sides of a security context
establishment -- that's all the mech should do.

Nico
--

---

From: "Cantor, Scott E." <[email-masked]>
Date: Fri, 8 Apr 2011 19:27:45 +0000

> (Note that HTTP is more complex; you need cookies or some other

I think my confusion stems from both thinking about HTTP and also thinking about SSL session resumption across TCP connections (which is somewhat related to the HTTP thing).

> 2 are sufficient for a non-HTTP use case.

It's sufficient for a persistent connection. I think you answered the other case by mentioning cookies. Normally that has a fairly perjorative connotation, but since the client here isn't a browser (read browser as "security sinkhole"), such a cookie isn't a cookie in the "anybody can probably steal it" sense.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Apr 2011 14:28:41 -0500

> On the general subject of tls-unique vs. endpoint, I had a brief conversation with Simon about it, and I think some clarification on how server applications would be expected to use tls-endpoint wo…

Regardless of the CB type, the application asks the channel for the CB
data of the selected CB type.

Since we lack a CB type negotiation facility, the CB type needs to be
selected a priori.  For various reasons tls-server-end-point is the
most practical CB type for HTTP and various other applications.

The reason tls-server-end-point is more practical than tls-unique in
some cases has to do with TLS concentrators: try and extract
tls-unique CB data from them :(  But the TLS server certificate is
easily enough copied around, configured wherever tls-server-end-point
CB data might be needed.

> How is it expected that servers would distinguish clients at the app layer when non-unique CB is used?

Servers have never distinguished clients by CB data before, so this
question answers itself: "the same way they always have" :)

In the case of HTTPS the answer is, whether you like it or not, "cookies".

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Apr 2011 14:35:57 -0500

> It's sufficient for a persistent connection. I think you answered the other case by mentioning cookies. Normally that has a fairly perjorative connotation, but since the client here isn't a browser…

HTTP, by its nature, only really allows you to use cookies to tie all
the requests (and responses) that make up an application "session".
Ideally there'd be a little more to it.  For example, the application
could use TLS session IDs to map HTTPS requests and responses to
application sessions, but this is complicated (there could be many TLS
sessions mapping onto one application session, with new TLS sessions
added at any time) and not actually done in practice.  Or the client
and server could share an established GSS security context and place a
MIC in the request/response headers -- a MIC of the request/response
body, and maybe some security-sensitive headers.  But that's not the
HTTP that we have.  HTTP as it is and as we use it allows us only the
use of cookies for this purpose.

Fortunately we also have HTTPS, and we're talking about doing CB.  So
setting a secure-only cookie has been, is, and will continue to be a
reasonable thing to do to solve this particular problem.

Nico
--

---

From: "William J. Mills" <[email-masked]>
Date: Fri, 8 Apr 2011 13:24:45 -0700 (PDT)

Ah now see... this is exactly why to assk the experts...

> Yes, RFC5056 says apps should prefix the CB data

And my life is simpler.  I simply remove any references to being more specific and know that the cbdata is of the format "%s:%s".

Thank you.

________________________________
From: Nico Williams <[email-masked]>
To: William J. Mills <[email-masked]>
Cc: Sam Hartman <[email-masked]>; Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]>; Tim Showalter <[email-masked]>
Sent: Friday, April 8, 2011 12:20 PM
Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02

Nico
--

---

From: "William J. Mills" <[email-masked]>
Date: Fri, 8 Apr 2011 17:10:48 -0700 (PDT)

Related questions about channel binding data...

CB data is prefixed with the channel binding scheme name and a colon, is there BNF or a definition for what the rest of that looks like?  Do I need to base64 it to make it safe to move in an HTML context?

Also, how big will it end up?  I suppose an SSL certificate can be a few k in the extreme case.

Thanks,

-bill

________________________________
From: Nico Williams <[email-masked]>
To: "Cantor, Scott E." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; Simon Josefsson <[email-masked]>; Tim Showalter <[email-masked]>; Sam Hartman <[email-masked]>
Sent: Friday, April 8, 2011 12:35 PM
Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02

Nico
--
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: "William J. Mills" <[email-masked]>
Date: Fri, 8 Apr 2011 20:06:22 -0700 (PDT)

Ah, so it would be valid for me to specify a cryptographic hash of the channel binding data and send the hash?

________________________________
From: Nico Williams <[email-masked]>
To: William J. Mills <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Friday, April 8, 2011 5:13 PM
Subject: Re: [kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02

> CB data is prefixed with the channel binding scheme name and a colon, is there BNF or a definition for what the rest of that looks like?  Do I need to base64 it to make it safe to move in an HTML c…
No, there is no such thing.  Each channel defines its CB data.
> Also, how big will it end up?  I suppose an SSL certificate can be a few k in the extreme case.
It can get large.  Mechanisms should either MAC the CB data or mix it into key derivation.
Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Apr 2011 23:46:13 -0500

> CB data is prefixed with the channel binding scheme name and a colon, is
there BNF or a definition for what the rest of that looks like?  Do I need
to base64 it to make it safe to move in an HTML context?

> Also, how big will it end up?  I suppose an SSL certificate can be a few k
in the extreme case.

It can get large.  Mechanisms should either MAC the CB data or mix it into
key derivation.

Nico
--

---

From: "William J. Mills" <[email-masked]>
Date: Fri, 8 Apr 2011 22:23:15 -0700 (PDT)

At the moment in the IANA registry I only see the tls-* channel bindings defined.  Does that sound correct?  Does this mean the mechanism has to roll-it's-own in cases other than TLS?

Sent: Friday, April 8, 2011 9:46 PM

---

From: Nico Williams <[email-masked]>
Date: Sat, 9 Apr 2011 01:54:22 -0500

> Ah, so it would be valid for me to specify a cryptographic hash of the
channel binding data and send the hash?

Yes, very much so.  Keyed hashes (MACs) are better, if you can swing that,
but a hash will do.

---

From: Nico Williams <[email-masked]>
Date: Sat, 9 Apr 2011 01:56:38 -0500

On Apr 9, 2011 12:23 AM, "William J. Mills" <[email-masked]> wrote:
>
> At the moment in the IANA registry I only see the tls-* channel bindings
defined.  Does that sound correct?  Does this mean the mechanism has to
roll-it's-own in cases other than TLS?

No, mechanisms never get to "roll their own".  The channel is responsible
for producing its CB data.  We know how to construct CB for other channel
types...  We just haven't registered them yet :)

---

From: "William J. Mills" <[email-masked]>
Date: Sat, 9 Apr 2011 00:27:51 -0700 (PDT)

So, I think the way to go in this mechanism is to send the channel binding type identifier and a SHA-1 hash of the channel binding data.  If the CB data is short I suppose we could optimise it, but I like simple for this. 

I'll add that change to the draft.

Sent: Friday, April 8, 2011 11:54 PM

> Ah, so it would be valid for me to specify a cryptographic hash of the channel binding data and send the hash?
Yes, very much so.  Keyed hashes (MACs) are better, if you can swing that, but a hash will do.

---

From: Nico Williams <[email-masked]>
Date: Sat, 9 Apr 2011 03:04:14 -0500

On Apr 9, 2011 2:27 AM, "William J. Mills" <[email-masked]> wrote:
>
> So, I think the way to go in this mechanism is to send the channel binding
type identifier and a SHA-1 hash of the channel binding data.  If the CB
data is short I suppose we could optimise it, but I like simple for this.

Uh, so i did tell you one thing wrong earlier: CB data will generally be
small.  The TLS CB types are small...  If you assume they'll be small then
you can dispense with the hash and any hash algorithm agility issues.  Sorry
about that!

Nico
--

---

From: "William J. Mills" <[email-masked]>
Date: Sat, 9 Apr 2011 16:13:54 -0700 (PDT)

Well perhaps I'll get just fancy enough to say if the CB source data is > than 500 bytes then SHA-1 hash and pass the hash. 

I'm stuffing this in an HTML query parameter, and I don't want to end up with problems in client or servers that assume maximum lengths.

Sent: Saturday, April 9, 2011 1:04 AM

> So, I think the way to go in this mechanism is to send the channel binding type identifier and a SHA-1 hash of the channel binding data.  If the CB data is short I suppose we could optimise it, but…
Uh, so i did tell you one thing wrong earlier: CB data will generally be small.  The TLS CB types are small...  If you assume they'll be small then you can dispense with the hash and any hash algorithm agility issues.  Sorry about that!
Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 9 Apr 2011 18:18:18 -0500

On Apr 9, 2011 6:13 PM, "William J. Mills" <[email-masked]> wrote:
>
> Well perhaps I'll get just fancy enough to say if the CB source data is >
than 500 bytes then SHA-1 hash and pass the hash.
>
> I'm stuffing this in an HTML query parameter, and I don't want to end up
with problems in client or servers that assume maximum lengths.

That will do.

---

From: "William J. Mills" <[email-masked]>
Date: Mon, 11 Apr 2011 12:14:30 -0700 (PDT)

Hi,

Is a working group session needed in Quebec for this spec?  My impression is that this is getting pretty close to wrapping up.  If it is I'd like to make sure to get my travel all sorted and approved before the last minute.

Thanks,

-bill

---

From: Martin Rex <[email-masked]>
Date: Tue, 12 Apr 2011 02:33:08 +0200 (MEST)

> 
> Well perhaps I'll get just fancy enough to say if the CB source data is
> I'm stuffing this in an HTML query parameter, and I don't want to
> end up with problems in client or servers that assume maximum lengths.

The tls-unique channel bindings is usually relatively small.
It is 12 octets by default for TLSv1.0/TLSv1.1/TLSv1.2 
and it is 36 octets for SSLv3. So hashing the tls-unique channel
bindings with SHA-1 will expand the size for TLSv1.x.

AND tls-unique is pure binary and looks like random noise
-- so if you want to transfer it within URLs, you will need to
base64 encode it.

-Martin

---

From: "William J. Mills" <[email-masked]>
Date: Mon, 11 Apr 2011 17:39:05 -0700 (PDT)

That agrees with what I've heard and read so far.  The text I have at the moment is:

  The channel binding data is computed by the client based on it's choice of
  preferred channel binding type.   As specified in <xref target="RFC5056"/> the
  channel binding information must start with the channel binding unique prefix followed
  by a colon (ASCII 0x3A), this is followed by base64 encoded channel binding
  payload.  The channel binding payload is the raw data from the channel binding
  type if the raw channel binding data is less than 500 bytes, if 500 bytes or
  larger the channel binding payload is a SHA-1 <xref target="RFC3174"/> hash of
  the raw channel binding data. 

I dod not know the tls-unique sizes though.  Makes sense that they look random, they are cryptographically generated, if they did not look random there would be a big problem.

Thanks!

-bill

________________________________
From: Martin Rex <[email-masked]>
To: [email-masked]
Cc: [email-masked]; [email-masked]
Sent: Monday, April 11, 2011 5:33 PM
Subject: Re: [kitten] CB data characteristics Re: Fw: New Version

-Martin

---

From: Shawn Emery <[email-masked]>
Date: Tue, 12 Apr 2011 16:29:02 -0600

On 04/11/11 01:14 PM, William J. Mills wrote:
> Hi,
>
> Is a working group session needed in Quebec for this spec?  My 
> impression is that this is getting pretty close to wrapping up.  If it 
> is I'd like to make sure to get my travel all sorted and approved 
> before the last minute.

Thank you for working with the group on this draft.  As a result, I 
don't foresee any controversy if the WG adopts this draft.  Even if 
there is we could always set up a WebEx or Skype session during the 
conference.

Shawn.
kitten co-chair
--