Subject: Re: [kitten] OAuth SASL draft -04

From: William Mills <[email-masked]>
Date: Tue, 21 Aug 2012 08:41:07 -0700 (PDT)

We have a question in play.  Does a SASL mechanism have to have guaranteed compatibility or is it OK for a mechanism to discover that there are no shared capabilities like SSL might discover no shared cipher suites?

-bill

On Aug 21, 2012, at 9:52 AM, William Mills wrote:

>> Well, what the client advertises isn't interesting right?  It's what the server advertises.
>> 
>> Is what you are saying that the only way the client can determine compatibility is via mechanism names and no other means?
>> 
>> -bill
>> 
>> From: Hannes Tschofenig <[email-masked]>
>> To: William Mills <[email-masked]> 
>> Cc: Hannes Tschofenig <[email-masked]>; Tim Showalter <[email-masked]>; Gil Yehuda <[email-masked]>; Jiangang Zhang <[email-masked]>; Ryan Troll <[email-masked]> 
>> Sent: Monday, August 20, 2012 11:46 PM
>> Subject: Re: OAuth SASL draft -04
>> 
>> I don't think that such an approach would work. 
>> 
>> If the SASL client indicates "OAUTH" in the SASL negotiation then that currently means that parts of the specification is implemented. 
>> 
>> For example: If the SASL client and the SASL server indicate "OAUTH" and the client only implements bearer and the server side only supports OAuth 1.0 MAC token then of course it will fail but the client wouldn't figure out why. I don't think that this is  particularly nice developer/user experience. 
>> 
>> On Aug 21, 2012, at 9:37 AM, William Mills wrote:
>> 
>> > Nothing is mandatory to implement.  The client may discover that it can't complete.  The error message will indicated supported schemes, as will discovery information out of band.
>> > 
>> > 
>> > From: Hannes Tschofenig <[email-masked]>
>> > To: William Mills <[email-masked]> 
>> > Cc: Hannes Tschofenig <[email-masked]>; Tim Showalter <[email-masked]>; Gil Yehuda <[email-masked]>; Jiangang Zhang <[email-masked]>; Ryan Troll <[email-masked]> 
>> > Sent: Monday, August 20, 2012 11:18 PM
>> > Subject: Re: OAuth SASL draft -04
>> > 
>> > But how are you then going to discover what functionality the two SASL endpoints provide without having to implement OAuth 1.0 and OAuth 2.0 in both the SASL client and SASL server? 
>> > 
>> > You may remember our recent discussion about this design aspect.
>> > 
>> > On Aug 20, 2012, at 8:10 PM, William Mills wrote:
>> > 
>> > > I thought about that.  It's simpler, but the way it is now requires no new SASL definitions to support a new token scheme and I really like that flexibility.
>> > > 
>> > > A thing I kind of don't like is that it's two layers of capability discovery, the SASL advertisement and then the scheme list, but in fact we need out of band discovery anyway which will for the most part replace the scheme list in the error message in mechanism.
>> > > 
>> > > 
>> > > From: Hannes Tschofenig <[email-masked]>
>> > > To: William Mills <[email-masked]> 
>> > > Cc: Hannes Tschofenig <[email-masked]>; Tim Showalter <[email-masked]>; Gil Yehuda <[email-masked]>; Jiangang Zhang <[email-masked]>; Ryan Troll <[email-masked]> 
>> > > Sent: Monday, August 20, 2012 9:55 AM
>> > > Subject: Re: OAuth SASL draft -04
>> > > 
>> > > Hi Bill, 
>> > > 
>> > > thanks for the update. 
>> > > 
>> > > When reading through the draft I noticed one aspect. Currently, you are specifying two SASL mechanisms, namely two SASL mechanisms "OAUTH" and "OAUTH-PLUS". "OAUTH-PLUS" adds channel binding. 
>> > > 
>> > > In our discussions we were, however, separating the OAuth 1.0 MAC token from the OAuth 2.0 Bearer Token approach and I was wondering one should register more SASL mechanisms to take advantage of the negotiation capabilities (since currently a client software has to implement OAuth 1.0 MAC tokens and OAuth 2.0 Bearer Tokens since there is only a single "OAUTH" SASL mechanism. 
>> > > 
>> > > I would register: 
>> > > 
>> > > * "OAUTH-1.0-MAC" (and  "OAUTH-1.0-MAC-CB") 
>> > > * "OAUTH-2.0-BEARER" (and  "OAUTH-2.0-BEARER-CB")
>> > > 
>> > > Does this make sense to you? 
>> > > 
>> > > Ciao
>> > > Hannes
>> > > 
>> > > 
>> > > 
>> > > On Aug 17, 2012, at 3:28 AM, William Mills wrote:
>> > > 
>> > > > All:
>> > > > 
>> > > > I'm getting close to the and of some significant changes (see the changelog near the end fo the doc).  I'd appreciate any time you can put on this to do a quick review before I submit another draft to the WG.  Anything from spelling errors to fatal flaws you find...
>> > > > 
>> > > > Thanks,
>> > > > 
>> > > > -bill
>> > > > 
>> > > > <draft-ietf-kitten-sasl-oauth-04.html><draft-ietf-kitten-sasl-oauth-04.xml>
>> > > 
>> > > 
>> > > 
>> > 
>> > 
>> > 
>> 
>> 
>> 
>
>
>
>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 21 Aug 2012 21:16:01 +0200

William Mills <[email-masked]> writes:

> We have a question in play.  Does a SASL mechanism have to have
> guaranteed compatibility or is it OK for a mechanism to discover that
> there are no shared capabilities like SSL might discover no shared
> cipher suites?

SASL mechanisms can fail for any reason.  RFC 4422:

   The outcome is not successful if

      -  the authentication exchange failed for any reason,

The application can retry in this situation.  However, this is not
always well supported by applications, but if mechanisms starts to fail
when attempted, those bugs will be noticed and fixed.

/Simon

---

From: William Mills <[email-masked]>
Date: Tue, 21 Aug 2012 12:30:14 -0700 (PDT)

Interesting.  In the Cyrus SASL implementation I've been working on I was thinking that the appropriate result would be one of:

#define SASL_BADSERV    -10  /* server failed mutual authentication step */
#define SASL_WRONGMECH  -11  /* mechanism doesn't support requested feature */

My preference is probably a "wrong mechanism" indication. 

>________________________________
> From: Simon Josefsson <[email-masked]>
>Cc: Hannes Tschofenig <[email-masked]>; "[email-masked]" <[email-masked]>; Tim Showalter <[email-masked]>; Jiangang Zhang <[email-masked]>; Gil Yehuda <[email-masked]> 
>Sent: Tuesday, August 21, 2012 12:16 PM

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 Aug 2012 08:36:33 +0300

There is no doubt that the protocol execution can fail for a number of reasons. 

The question I had was whether it is enough to register one SASL method, namely "OAUTH", for two different security mechanisms, namely for OAuth 1.0 MAC tokens, and for the OAuth 2.0 Bearer Token, or whether these should rather be exposed as two separate mechanisms. Using two separate SASL mechanisms allows us to use the SASL negotiation mechanism. 

In an earlier discussion we had spoken about the difference between the two mechanisms and Bill's argument was that he wanted both since neither one of them covers the deployment nor the required properties. Ultimately it boiled down to the question of how many different OAuth variants one wants to implement in the SASL client and the SASL server. 

So, Bill has this idea that we could figure out what functionality is supported by trial-and-error. To put that to the extreme one could argue that we only one SASL mechanism (without any negotiation) and then after some failed exchanges the client and the server will find a mechanism that works. 

I am, however, advocating for registering more SASL methods to distinguish the different variants. I would, for example, if we finish the work on the new OAuth security mechanism standardize that as a SASL mechanism with a new id.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Aug 2012 09:26:25 +0200

I have a preference for having at least two mechanisms, one for OAuth
1.x and one for OAuth 2.x.  The terminology and semantic differences
between OAuth 1.x and 2.x are motivation enough for me.

I believe the SASL mechanism selection is the most reliable place to
have negotiation in SASL, for better or worse.  We have tried SASL
mechanisms that contain their own negotiation, and it always seem to
become too complex.

Further, one could argue that OAuth 2.x with bearer and OAuth 2.x with
MAC are so completely different beasts that they deserve separate SASL
mechanism names, and I would not object to that.  I'd feel more
comfortable knowing that if I negotiated OAUTH2MAC I would get a keyed
authentication, whereas I would feel less confident when selecting
OAUTH2BEARER.  If both bearer and MAC are negotiated through OAUTH2 I
would have to poke into the details of that mechanism negotiation, and
that is less reliable and more difficult to write security policies
for.

>From a standards point of view, having separate SASL mechanisms seems
benefecial: the OAUTH1 mech would only normatively reference the OAuth
1.x document, and could then be reviwed in isolation.  The OAUTH2
mech(s) would only normatively reference the OAuth 2.x documents.
Currently, when both 1.x and 2.x are referenced, the terminology becomes
muddy as it is not clear what is the authorative reference for each
term.

/Simon

Hannes Tschofenig <[email-masked]> writes:

> The question I had was whether it is enough to register one SASL
> method, namely "OAUTH", for two different security mechanisms, namely
> for OAuth 1.0 MAC tokens, and for the OAuth 2.0 Bearer Token, or
> whether these should rather be exposed as two separate
> mechanisms. Using two separate SASL mechanisms allows us to use the
> SASL negotiation mechanism.
>
> In an earlier discussion we had spoken about the difference between
> the two mechanisms and Bill's argument was that he wanted both since
> neither one of them covers the deployment nor the required
> properties. Ultimately it boiled down to the question of how many
> different OAuth variants one wants to implement in the SASL client and
> the SASL server.
>
> So, Bill has this idea that we could figure out what functionality is
> supported by trial-and-error. To put that to the extreme one could
> argue that we only one SASL mechanism (without any negotiation) and
> then after some failed exchanges the client and the server will find a
> mechanism that works.
>
> I am, however, advocating for registering more SASL methods to
> distinguish the different variants. I would, for example, if we finish
> the work on the new OAuth security mechanism standardize that as a
> SASL mechanism with a new id.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 22 Aug 2012 10:52:49 +0300

That's inline with my thinking as well. 

And: I had also noticed the terminology issue; there is room for wording changes here and there. 

Ciao
Hannes

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 22 Aug 2012 14:42:54 +0000

>And: I had also noticed the terminology issue; there is room for wording

There is, naturally, a similar issue in SAML-EC with the subject
confirmation being the determinant. I did build in some degree of
negotiation already, because some of it is inherited from the HTTP use
case on which the message exchange is inherited, but it does have the
problem that you have to dig into the exchange to know which one is
involved.

-- Scott

---

From: Ryan Troll <[email-masked]>
Date: Wed, 22 Aug 2012 09:23:38 -0700

I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER,
channel-binding versions, etc.

Negotiations within a SASL mechanism, which this is leading towards,
doesn't sound good.  By letting clients know exactly which tokens are
supported up-front, clients are able to better choose, and understand the
implications of those choices.

This should also allow us to remove the error-message-in-server-challenge
and subsequent empty-client-challenge-response upon failure.

-R

On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott <[email-masked]> wrote:

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

---

From: William Mills <[email-masked]>
Date: Wed, 22 Aug 2012 11:34:19 -0700 (PDT)

Removing the error response means no richer status code for the client and no advertised scope.   I'll do that if that's what people want, but I think it is useful.

I'll make the changes to the draft:

-    we'll define OAUTHBEARER, OAUTH10A, and their -PLUS variants.  
-    adding back in the user field
-    fixing the language for the gs2 header and only sending it in the GS2 context.

New specifications compatible with the existing structure in the draft then need only define a new SASL mechanism name.

> From: Ryan Troll <[email-masked]>
>To: "[email-masked]" <[email-masked]> 
>Sent: Wednesday, August 22, 2012 9:23 AM
>Subject: Re: [kitten] OAuth SASL draft -04
> 
>
>I vote for having separate mechanisms for OAUTH2MAC, OAUTH2BEARER, channel-binding versions, etc.
>
>
>Negotiations within a SASL mechanism, which this is leading towards, doesn't sound good.  By letting clients know exactly which tokens are supported up-front, clients are able to better choose, and understand the implications of those choices.
>
>
>This should also allow us to remove the error-message-in-server-challenge and subsequent empty-client-challenge-response upon failure.
>
>
>-R
>
>
>
>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Aug 2012 20:39:19 +0200

William Mills <[email-masked]> writes:

> Removing the error response means no richer status code for the client
> and no advertised scope.   I'll do that if that's what people want,
> but I think it is useful.
>

Great!

> -    fixing the language for the gs2 header and only sending it in the

It is the other way around: the gs2 header should only be sent in the
initial client SASL response, not in the initial GSS-API context token.

> New specifications compatible with the existing structure in the draft
> then need only define a new SASL mechanism name.

Yes.

Thanks,
/Simon

>> doesn't sound good.  By letting clients know exactly which tokens
>> are supported up-front, clients are able to better choose, and
>> understand the implications of those choices.
>>
>>
>>This should also allow us to remove the
>> error-message-in-server-challenge and subsequent
>> empty-client-challenge-response upon failure.
>>
>>
>>-R
>>
>>
>>
>>

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 22 Aug 2012 18:44:18 +0000

>> -    adding back in the user field

Simon, would you suggest I do the same for SAML-EC? I don't think it's a
great idea to go all the way into specific holder of key types, but it's
not a big deal to split bearer out.

-- Scott

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Aug 2012 20:50:02 +0200

> not a big deal to split bearer out.

How many different schemes would there typically be?  My impression was
that SAML is more flexible around this, and that the flexibility is also
used in some environments, so there could potentially be a lot of
schemes.  But perhaps for Internet-wide use, there is only a handful of
schemes that are relevant?  Then it may make sense.  The downside then,
of course, is that people doing their own stuff would be left out in the
cold.

Generally, if it makes things less complex to move out sub-negotiation
from SASL mechanisms into the SASL mechanism selection process, I
believe that is a good idea.  But there can be situations where that
leads to lesser security (think downgrade attacks) so it has to be
weighted carefully.

/Simon

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 22 Aug 2012 19:02:40 +0000

Renaming the thread since we're off-topic...

On 8/22/12 2:50 PM, "Simon Josefsson" <[email-masked]> wrote:
>How many different schemes would there typically be?

The only holder of key approach likely in the near term is RSA, X.509
certs, etc. Longer term, ECDSA (and ECDH) become possibilities. I don't
see MAC approaches being used at all.

>My impression was that SAML is more flexible around this, and that the
>flexibility is also

I don't think much beyond RSA and ECDSA would be too likely, but since
most keyed tokens are probably going to have similar security properties,
it seems like combining those is an advantage.

I don't know enough to say whether splitting bearer at all is worth doing,
but if it's worth it for OAuth, the same logic would apply. SAML bearer
tokens can still do channel binding, but any session keying is not going
to be secure, obviously, unless it's pulled from TLS.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 22 Aug 2012 19:05:47 +0000

>it seems like combining those is an advantage.

One advantage is that it's tied one-to-one to the SAML subject
confirmation method. If somebody wanted semantics more precise than those
connoted by "holder of key", that could be spun into a separate mechanism
relatively painlessly, and chances are they would have to be touching lots
of deployed pieces anyway.

-- Scott

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Aug 2012 10:12:16 +0200

> it seems like combining those is an advantage.

Yes, splitting the mechanism names on the RSA vs ECDSA level seems
excessive.  Presumably, servers will typically implement both anyway?

> but if it's worth it for OAuth, the same logic would apply.

It is not completely comparable -- for OAuth there is 1.x and 2.x which
are different protocols even if there is similarity.  It makes sense to
separate.  Compare if we wanted to support SAML 1.x here, then it might
make sense to have separate mechanism names.

> SAML bearer tokens can still do channel binding, but any session
> keying is not going to be secure, obviously, unless it's pulled from
> TLS.

Maybe that is still useful... I dunno.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 23 Aug 2012 10:20:31 +0100

> channel-binding versions, etc.
Just to clarify: I hope you are not recommending to have a separate 
OAUTH SASL mechanism for each channel binding type. That would make the 
list of SASL mechanisms unmanageable.
(Having separate mechanisms for MAC and BEARER seem to make sense, IMHO. 
But no strong preferences.)
> supported up-front, clients are able to better choose, and understand 
> the implications of those choices.
>
> On Wed, Aug 22, 2012 at 7:42 AM, Cantor, Scott <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 8/22/12 3:52 AM, "Hannes Tschofenig" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     >And: I had also noticed the terminology issue; there is room for
>     wording
>     >changes here and there.
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 23 Aug 2012 14:13:47 +0000

>excessive.  Presumably, servers will typically implement both anyway?

Depends more on their crypto support. EC for example is turned off in Red
Hat 6.

>make sense to have separate mechanism names.

Agree, but I don't think that was the whole motivation to split them. The
point specifically raised was the lack of keying from the bearer mechanism
and that would be true with SAML also.

I'll leave it for the moment pending more review.

-- Scott

---

From: Ryan Troll <[email-masked]>
Date: Thu, 23 Aug 2012 09:38:59 -0700

No, I was alluding to a channel-binding enabled version of each previous
token.  For example "OAUTH2MAC", "OAUTH2MAC-PLUS", "OAUTH2BEARER", and
"OAUTH2BEARER-PLUS", as draft -05 outlines.

-R

On Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov
<[email-masked]>wrote:

> Just to clarify: I hope you are not recommending to have a separate OAUTH
> SASL mechanism for each channel binding type. That would make the list of
> SASL mechanisms unmanageable.
> Kitten mailing [email-masked]://www.ietf.org/mailman/listinfo/kitten
>
>
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 Aug 2012 20:04:08 +0300

I think it is useful to have this list (CB and non-CB-based variants) to
avoid the trial-and-error approach.

On 8/23/12 7:38 PM, "ext Ryan Troll" <[email-masked]> wrote:

> On Thu, Aug 23, 2012 at 2:20 AM, Alexey Melnikov <[email-masked]>
> wrote:
>>     
>>  
>>  (Having separate mechanisms for MAC and BEARER seem to make sense, IMHO. But
>> no strong preferences.)
>> 
>>  
>>>  
>>> Negotiations within a SASL mechanism, which this is leading towards, doesn't
>>> sound good.  By letting clients know exactly which tokens are supported
>>> up-front, clients are able to better choose, and understand the implications
>>> of those choices.
>>>  
>>> 
>>>  
>>>

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 24 Aug 2012 09:11:55 +0200

> I'll leave it for the moment pending more review.

That sounds good to me.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 24 Aug 2012 09:23:59 +0200

I have a mild preference for trying this approach too.  However, doesn't
this suggest that there should be a separate OID for the GSS-API
mechanism side of each SASL mechanism?  I think so.

Further, the -05 document just specify OAUTHBEARER, OAUTH10A, and
OAUTH10A-PLUS right now.

/Simon

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 Aug 2012 10:34:22 +0300

> Further, the -05 document just specify OAUTHBEARER, OAUTH10A, and

True. Depending on the group consensus the draft will change. 

Ciao
Hannes

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 Aug 2012 10:47:55 +0100

Yes.

---

From: William Mills <[email-masked]>
Date: Fri, 24 Aug 2012 10:29:45 -0700 (PDT)

Updated to 3 OID's required, thank you.  Is there a specific registry process, or does the RFC editor take care of that?

>To: Hannes Tschofenig <[email-masked]> 
>Cc: [email-masked] 
>Sent: Friday, August 24, 2012 12:23 AM
>>>>>>>  >That's inline with my thinking as well.
>>>>>>>  >
>>>>>>>  >And: I had also noticed the terminology issue; there is room for wording
>>>>>>>  >changes here and there.
>>>>>>  
>>>>>>

---

From: William Mills <[email-masked]>
Date: Fri, 24 Aug 2012 10:48:57 -0700 (PDT)

A new question in play, should the kv separator be converted from %x01 to "," which makes it more compatible with the GS2 parsers out there?

I am not in favor of this, because one of the data elements to be carried is the HTTP authentication header payload in which comma might apprear, but control characters are not allowed.  I picked a control character specifically for this reason.

Regards,

-bill

---

From: Luke Howard <[email-masked]>
Date: Sat, 25 Aug 2012 18:19:59 +1000

You shouldn't need a different OID for the -PLUS variant, this is handled at the SASL layer.

-- Luke

--
Luke Howard / [email-masked]
www.padl.com / www.lukehoward.com

---

From: William Mills <[email-masked]>
Date: Sat, 25 Aug 2012 13:29:23 -0700 (PDT)

OK, thank you.  Corrected.

> From: Luke Howard <[email-masked]>
>Cc: Simon Josefsson <[email-masked]>; Hannes Tschofenig <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Saturday, August 25, 2012 1:19 AM

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 26 Aug 2012 18:32:51 +0200

William Mills <[email-masked]> writes:

> A new question in play, should the kv separator be converted from %x01
> to "," which makes it more compatible with the GS2 parsers out there?
>
> I am not in favor of this, because one of the data elements to be
> carried is the HTTP authentication header payload in which comma might
> apprear, but control characters are not allowed.  I picked a control
> character specifically for this reason.

If using "," would make a large percentage of typical exchanges contain
an escaped "," (i.e., "=2C") then I share your concern with ",".

However, if it is just occasional that the payload contains "," I think
using "," is simpler -- remember that you need to implement the ","
escaping stuff anyway due to the gs2-header.  So you will have the code
present in your application anyway.

/Simon

---

From: William Mills <[email-masked]>
Date: Sun, 26 Aug 2012 10:31:38 -0700 (PDT)

The way it is now I don't think we need comma escaping unless it's actually GS2 enabled and you're in the gs2-header.  I can scan past the gs2-header looking for the first %x01 and I'm off to the SASL processing.  If I have to define comma escaping that is a significant change.

>Cc: "[email-masked]" <[email-masked]> 
>Sent: Sunday, August 26, 2012 9:32 AM
>Subject: Re: Comma vs. %x01  Re:  OAuth SASL draft -05
>

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 26 Aug 2012 23:40:05 +0200

William Mills <[email-masked]> writes:

> The way it is now I don't think we need comma escaping unless it's
> actually GS2 enabled and you're in the gs2-header.

The SASL mechanism side should always be "GS2 enabled" (if you mean use
the gs2-header).

>   I can scan past the gs2-header looking for the first %x01 and I'm
> off to the SASL processing.  If I have to define comma escaping that
> is a significant change.

You need to parse the gs2-header to find the channel binding type and
authorization identity, so I believe a gs2-header parser is needed if
you want compatibility with GS2 and a GSS-API mechanism.  I don't
believe it is difficult to implement.  There is plenty of code around
that you can look at and use.

/Simon

---

From: William Mills <[email-masked]>
Date: Sun, 26 Aug 2012 16:03:02 -0700 (PDT)

Why should I implement a gs2 syntax and parser for the rest of the message when the parser and grammar as it stands is extremely simple?  I much prefer not to have to deal with an escaping mechanism.  Sure there are extant ones, but why use one whne a simpler model is available?

At the moment the way this is set up you only need the channel binding flag, the identity in the gs2-header appears to be extraneous.

>Sent: Sunday, August 26, 2012 2:40 PM

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Aug 2012 09:53:23 +0200

William Mills <[email-masked]> writes:

> Why should I implement a gs2 syntax and parser for the rest of the
> message when the parser and grammar as it stands is extremely simple? 
> I much prefer not to have to deal with an escaping mechanism.  Sure
> there are extant ones, but why use one whne a simpler model is
> available?
>
> At the moment the way this is set up you only need the channel binding
> flag, the identity in the gs2-header appears to be extraneous.

I believe you need a parser for the gs2-header syntax if you want the
GSS-API OAuth mechanism to be wire compatible with the SASL OAuth
mechanism via GS2.

The gs2 header carries the authorization header which presumably servers
will need.  Of course, if your implementation never looks at the
authorization identity, you don't need to parse it, however users may be
surprised to request authorization as "joe" but find themselves logged
in as "eve".  The mechanism should allow a SASL authorization identity,
see RFC 4422.

Hopefully support for the channel binding variant will be common, and
then you need to implement the parsing and channel binding logic too.

/Simon

---

From: Luke Howard <[email-masked]>
Date: Mon, 27 Aug 2012 18:02:12 +1000

> GSS-API OAuth mechanism to be wire compatible with the SASL OAuth

And, please, I can't imagine why one would want this to be not the case. :-)

-- Luke

---

From: William Mills <[email-masked]>
Date: Mon, 27 Aug 2012 08:50:11 -0700 (PDT)

See section 3.2.1 for the definition of how SASL authorization and authentication indentities are mapped.  The "user" field and value in the gs2-header are not authoritative in this spec, the values used must be derived from the OAuth exchange and credentials.

>Sent: Monday, August 27, 2012 12:53 AM

---

From: William Mills <[email-masked]>
Date: Mon, 27 Aug 2012 08:52:37 -0700 (PDT)

Answered in a different message, the only value needed from the gs2-header is the channel binding flag.

>To: Simon Josefsson <[email-masked]> 
>Cc: William Mills <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Monday, August 27, 2012 1:02 AM
>Subject: Re: [kitten] Comma vs. %x01  Re:  OAuth SASL draft -05
> 
>
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 27 Aug 2012 15:54:22 +0000

On 8/27/12 11:50 AM, "William Mills" <[email-masked]> wrote:

>See section 3.2.1 for the definition of how SASL authorization and
>authentication indentities are mapped.  The "user" field and value in the
>gs2-header are not authoritative in this spec, the values used must be
>derived from the OAuth exchange and
> credentials.

I don't think a federated system can dictate local identifiers based on
non-local ones, which sounds like what you're claiming here.

-- Scott

---

From: William Mills <[email-masked]>
Date: Mon, 27 Aug 2012 09:21:06 -0700 (PDT)

The value has to be derived from the credential.  If the local system has a mapping that's fine it can map to an internal ID, but that's not asserted by the client it's asserted by the credential (and the authorization server).

> From: "Cantor, Scott" <[email-masked]>
>Sent: Monday, August 27, 2012 8:54 AM

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 27 Aug 2012 16:29:56 +0000

On 8/27/12 12:21 PM, "William Mills" <[email-masked]> wrote:
>
>The value has to be derived from the credential.

*A* value does, yes, not *the* value necessarily.

>If the local system has a mapping that's fine it can map to an internal
>ID, but that's not asserted by the client it's asserted by the credential
>(and the authorization server).

The credential is asserting its own notion of identity. I disagree that
the client does not (or at least cannot) assert one. Then there's an
evaluation as to whether the locally-asserted value is appropriate given
the federated credential.

You sound as though you want to dictate how the application works or how
SASL works, when all you're doing is defining a mechanism. I think the
mechanism needs to accept the model its plugging into.

If I've misunderstood that model, I'll need to adjust some things myself.

-- Scott

---

From: William Mills <[email-masked]>
Date: Mon, 27 Aug 2012 10:17:14 -0700 (PDT)

I think what you are arguing for is a model that supports a credential that allows access to N mailboxes in the IMAP case and the ID sent by the client selects the mailbox to access.   The problem I think is we don't have a way in OAuth to deal with understanding that the same credential can be used with N different identities.  Custom clients certainly could do this, an example from work life would be Yahoo Small Businees where a single account is the master for N Small Business setups, but we don't have a general case I think.

If it's a single identity per credential then trusting the client is wrong, you have to trust the credential.  You could tie the authentication to an extra piece of information, but that kind of breaks OAuth.

OAuth can be tied to a specific URI, and it could work that way, but that would require defining a URI for every type of endpoint which we don't have.

>Sent: Monday, August 27, 2012 9:29 AM

---

From: William Mills <[email-masked]>
Date: Mon, 27 Aug 2012 10:21:16 -0700 (PDT)

Actually, the "user" field selecting a value from a list in the credential would be valid under the current language.  The assertion of identity still is carried in the credential.

> From: William Mills <[email-masked]>
>To: "Cantor, Scott" <[email-masked]> 
>Sent: Monday, August 27, 2012 10:17 AM

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 27 Aug 2012 17:41:27 +0000

On 8/27/12 1:17 PM, "William Mills" <[email-masked]> wrote:
>
>I think what you are arguing for is a model that supports a credential
>that allows access to N mailboxes in the IMAP case and the ID sent by the
>client selects the mailbox to access.

No, I'm arguing only that federated systems cannot dictate local
identification based on remote identification. That linkage is often local
to the app.

>   The problem I think is we don't have a way in OAuth to deal with
>understanding
> that the same credential can be used with N different identities.
>Custom clients certainly could do this, an example from work life would
>be Yahoo Small Businees where a single account is the master for N Small
>Business setups, but we don't have a general
> case I think.

It's not up to OAuth or the client, it's up to the service/app.

>If it's a single identity per credential then trusting the client is
>wrong, you have to trust the credential.  You could tie the
>authentication to an extra piece of information, but that kind of breaks
>OAuth.

I'm not saying you trust the client, I'm saying that the question of local
identification based on the credential is a local (to an app) matter.

This is so intrinsic to federation that I have to wonder if this is a
terminology problem.

-- Scott

---

From: William Mills <[email-masked]>
Date: Mon, 27 Aug 2012 11:52:00 -0700 (PDT)

> This is so intrinsic to federation that I have to wonder if this is a

I think so, yes.  The members of the federation have to already have agreed how to map identities.

>Sent: Monday, August 27, 2012 10:41 AM

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 27 Aug 2012 19:00:59 +0000

>agreed how to map identities.

Map, yes. Your mapping seems to be an identity mapping, and that¹s not
sufficient. Neither can you assume that the IdP end has done the mapping
and is providing the locally correct value.

That may be your deployment model, but it's not the general one.

-- Scott

---

From: William Mills <[email-masked]>
Date: Mon, 27 Aug 2012 12:16:06 -0700 (PDT)

No, I'm not assuming the IDP has the mapping, I'm assuming the local server knows how to map from an asserted federati0on ID to a local one.

>Sent: Monday, August 27, 2012 12:00 PM

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 27 Aug 2012 19:42:30 +0000

On 8/27/12 3:16 PM, "William Mills" <[email-masked]> wrote:

>No, I'm not assuming the IDP has the mapping, I'm assuming the local
>server knows how to map from an asserted federati0on ID to a local one.

The point, though, is that (if I'm not misunderstanding), existing SASL
servers do this in part via the authz id. Your mechanism is inside that
code as a plugin, it's not meant to be driving the application-level
behavior.

I'm sure I'll be corrected if I'm wrong.

-- Scott

---

From: William Mills <[email-masked]>
Date: Mon, 27 Aug 2012 13:38:35 -0700 (PDT)

In my own implementation of this the mechanism asserts the authz and authn IDs, it's not changing that behavior.

>Sent: Monday, August 27, 2012 12:42 PM

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Aug 2012 00:08:04 -0500

On Aug 27, 2012 3:38 PM, "William Mills" <[email-masked]> wrote:
>
> In my own implementation of this the mechanism asserts the authz and
authn IDs, it's not changing that behavior.

That's fine.  Provided that the server/acceptor can substitute a different
authz ID(s), which, of course, it must be free to do anyways given that
what the server chooses to do is a local matter.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 28 Aug 2012 15:16:51 +0200

William Mills <[email-masked]> writes:

> that allows access to N mailboxes in the IMAP case and the ID sent by
> the client selects the mailbox to access.

Not quite -- the credential doesn't have to support the model.  It is
the authentication mechanism that should support the model, by being
able to transfer the authorization identity.

> The problem I think is we
> don't have a way in OAuth to deal with understanding that the same
> credential can be used with N different identities.

It is the same for Kerberos and other mechanisms.  That is why SASL
provide for an authorization identity that is transfered from the client
to the server by the mechanism.

> authentication to an extra piece of information, but that kind of
> breaks OAuth.
>
> OAuth can be tied to a specific URI, and it could work that way, but
> that would require defining a URI for every type of endpoint which we
> don't have.

I don't see how OAuth is different from say Kerberos here.  A Kerberos
credential is used to perform the security negotiation, and the SASL
authorization identity is used by the server to map to user to login as.
OAuth would be similar.  It may be that 90% of all implementations will
reject a claimed authorization identity, but the protocol should still
permit it.

/Simon

---

From: William Mills <[email-masked]>
Date: Tue, 28 Aug 2012 07:31:22 -0700 (PDT)

You're asking for something that is exactly what is there already unless I've written it completely wrong.  That's what section 3.2.1 is all about.

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.

This does exactly what you want.

>Cc: "Cantor, Scott" <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, August 28, 2012 6:16 AM

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Aug 2012 01:02:27 +0200

I would prefer a model where the OAuth SASL mechanism can transfer a
SASL authorization identity in addition to the OAuth credential.  The
authzid, if present and authorized by server policy, would override any
authorization identity implied from the OAuth credential.  What is the
disadvantage with that approach?  I believe this is the SASL model,
compare RFC 4422:

   The client provides its credentials (which include or imply an
   authentication identity) and, optionally, a character string
   representing the requested authorization identity as part of the SASL
   exchange.  When this character string is omitted or empty, the client
   is requesting to act as the identity associated with the credentials
   (e.g., the user is requesting to act as the authentication identity).

I don't believe what I'm asking for is covered by the document now.

Your section below is still relevant and required: it explains how a
server derives the authorization identity when the SASL authorization
identity is not present.  This is the typical and normal situation.

If you chose another path, I believe some discussion about the lack of
support for a normal SASL authorization identity is needed.  You could
say that this mechanism does not support transferring a SASL
authorization identity as described in RFC 4422, and that if the
gs2-header contains an authzid, that MUST lead to authentication
failure.

/Simon

William Mills <[email-masked]> writes:

> You're asking for something that is exactly what is there already
> unless I've written it completely wrong.  That's what section 3.2.1 is
> all about.
>
> 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.
>
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 28 Aug 2012 23:08:43 +0000

>gs2-header contains an authzid, that MUST lead to authentication

My concern was whether that was actually allowable and would work with
existing GS2 code. I was concerned that imposing a constraint like that
would actually break things. If that's not the case, then I'd say I'm of
the opinion that it's suboptimal to be different for essentially no
reason, but at least it's not fatal.

-- Scott

---

From: Luke Howard <[email-masked]>
Date: Wed, 29 Aug 2012 09:14:46 +1000

> reason, but at least it's not fatal.

A GS2 bridge such as the one included with Cyrus SASL, which knows nothing about the underlying GSS mechanism, would not know that the presence of an authorisation identity in the GS2 header should lead to authentication failure.

-- Luke

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Aug 2012 01:25:13 +0200

> A GS2 bridge such as the one included with Cyrus SASL, which knows nothing about the underlying GSS mechanism, would not know that the presence of an authorisation identity in the GS2 header should…

Exactly.  If this mechanism doesn't follow the usual SASL/GSSAPI
mechanism design pattern, it will have limitations which can cause
problems.  Not following usual design patterns is fine if there is a
reason for it, but I haven't seen one so far.

I hope and believe this is a misunderstanding that can be resolved with
more discussion, and not some fundamental disagreement.

/Simon

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Aug 2012 22:43:30 -0500

> disadvantage with that approach?  I believe this is the SASL model,

I'm confused.  As a SASL/GS2 mechanism this would be definition carry
an [optional] authz-id: it's in the gs2-header.

So, of course the OAuth SASL/GS2 mechanism supports an authz-id
assertion.  It must.

Nico
--

---

From: William Mills <[email-masked]>
Date: Tue, 28 Aug 2012 20:49:18 -0700 (PDT)

Yes, what you are asking for is something I explicitly avoided and think we should continue to avoid, because for things like OAuth 1.0a you have to define a URI that can be signed which includes the name, and deciding the correct URI format for an arbitrary resource to be authenticate with SASL isn't solved.

It also would require is to be able to present those URIs to an OAuth authorization endpoint to be explicitly approved.

I'm avoiding having to try to define a URI for POP, IMAP, and SMTP-send-mail like the plague.

>Sent: Tuesday, August 28, 2012 4:02 PM

---

From: Luke Howard <[email-masked]>
Date: Wed, 29 Aug 2012 13:50:22 +1000

> So, of course the OAuth SASL/GS2 mechanism supports an authz-id

I think the question has reframed itself as: is this a SASL mechanism that looks a bit like a GS2 mechanism but isn't; or are we just not yet on the same page in terms of understanding what a GS2 mechanism is?

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Aug 2012 22:54:23 -0500

On Tue, Aug 28, 2012 at 10:49 PM, William Mills <[email-masked]> wrote:
> Yes, what you are asking for is something I explicitly avoided and think we
> should continue to avoid, because for things like OAuth 1.0a you have to
> define a URI that can be signed which includes the name, and deciding the
> correct URI format for an arbitrary resource to be authenticate with SASL
> isn't solved.
>
> It also would require is to be able to present those URIs to an OAuth
> authorization endpoint to be explicitly approved.
>

OK, let's say that there is a GSS mechanism such that it makes no
sense to assert an authz-id when using it as a SASL/GS2 mechanism.
What's the problem?  Well, we need to say what happens if an authz-id
is asserted nonetheless.  We can say that the server "MUST fail the
authentication attempt", or that it "MUST ignore the authz-id
assertion", or perhaps something else.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Wed, 29 Aug 2012 13:58:50 +1000

I probably don't understand enough about OAuth, but in my experience with SASL, whether a given authentication identity can act as a particular authorisation identity is decided by the application, and typically the authorisation identities look like local system identifiers (e.g. "u:lukeh") or DNs (e.g. "dn:cn=Luke Howard,o=PADL"). The authentication mechanism itself does not do anything beyond securely transport the authorisation identity, and make it available to the SASL layer/application.

However I may be conflating implementation experience with a more abstract perspective.

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 29 Aug 2012 03:59:01 +0000

>sense to assert an authz-id when using it as a SASL/GS2 mechanism.

I don't think there's any obvious reason for that here.

>assertion", or perhaps something else.

As I suspected, and Simon/Luke noted, you can't mandate that without
breaking existing GS2 code.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 29 Aug 2012 04:00:52 +0000

On 8/28/12 11:49 PM, "William Mills" <[email-masked]> wrote:

>
>Yes, what you are asking for is something I explicitly avoided and think
>we should continue to avoid, because for things like OAuth 1.0a you have
>to define a URI that can be signed which includes the name, and deciding
>the correct URI format for an arbitrary
> resource to be authenticate with SASL isn't solved.

Can you explain why? That sounds like you're talking about the server's
identity, and this is about the client's claimed identity.

>SMTP-send-mail like the plague.

I don't see why that is needed here. I agree that that's bad. I almost
ended up with that problem and worked to avoid it.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Aug 2012 23:05:15 -0500

> I don't think there's any obvious reason for that here.

I don't see that either.  Just trying to think this through.

> breaking existing GS2 code.

Good point.

I think the best thing to do is to say that this is a SASL/GS2 (and
therefore GSS) mechanism and then say *noting* about the SASL
authz-id.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Wed, 29 Aug 2012 14:07:19 +1000

> therefore GSS) mechanism and then say *noting* about the SASL

Agreed.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Aug 2012 23:08:30 -0500

On Tue, Aug 28, 2012 at 10:58 PM, Luke Howard <[email-masked]> wrote:
> I probably don't understand enough about OAuth, but in my experience with
> SASL, whether a given authentication identity can act as a particular
> authorisation identity is decided by the application, and typically the
> authorisation identities look like local system identifiers (e.g. "u:lukeh")
> or DNs (e.g. "dn:cn=Luke Howard,o=PADL"). The authentication mechanism
> itself does not do anything beyond securely transport the authorisation
> identity, and make it available to the SASL layer/application.
>

No, that's exactly right.

I think William's concern may be that it may not be appropriate to use
OAuth-authenticated entities this way since doing so may lose
information about about constraints on authorization imposed by OAuth.

However, I would say that William should not be so concerned.  SASL
says nothing about a fine-grained authorization model, and certainly
does not preclude such a model.  For example, GSS now doe shave a
fine-grained authz model ("extended naming"), and a SASL/GS2 bridge
implementation could simply expose that interface to applications.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Aug 2012 23:10:41 -0500

> implementation could simply expose that interface to applications.

To complete the thought: SASL/GS2 should have said (and maybe should
be updated to say) that an implementation SHOULD expose all the naming
functionality of the GSS-API, including the GSS naming extensions.
But I don't think we need to update SASL/GS2 to say that in order to
get the OAuth mechanism specified.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Wed, 29 Aug 2012 14:18:56 +1000

> functionality of the GSS-API, including the GSS naming extensions.

Getting distracted into implementations-ville, Cyrus SASL supports this with the SASL_GSS_PEER_NAME property (this returns a gss_name_t object that you can interrogate with naming extensions).

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Aug 2012 23:23:06 -0500

> Getting distracted into implementations-ville, Cyrus SASL supports this with the SASL_GSS_PEER_NAME property (this returns a gss_name_t object that you can interrogate with naming extensions).

Right, and that's perfect.  Specification-wise it'd be nice if RFC5801
had said this, but I don't think we need it to *right now*.

Nico
--

---

From: William Mills <[email-masked]>
Date: Tue, 28 Aug 2012 21:23:28 -0700 (PDT)

Because OAuth is about granting access to a resource, and in many cases resources are represented as URIs.  The  access dance includes in some parts of the flow the URI of the resource for which access is being granted.  If we really go "there" then we need to be able to grant access to "send mail as [email-masked]", and that's completely different from mailto:[email-masked].  We'd need to define something like mailfrom:[email-masked].  This is why I'm punting by mapping everything onto a stub HTTP URI, because SASL exists in many places for which there is no defined URI.

Does that explain it?

>To: William Mills <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Tuesday, August 28, 2012 9:00 PM

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 29 Aug 2012 04:31:21 +0000

On 8/29/12 12:23 AM, "William Mills" <[email-masked]> wrote:

>Because OAuth is about granting access to a resource, and in many cases
>resources are represented as URIs. The  access dance includes in some
>parts of the flow the URI of the resource for which access is being
>granted.

Yes.

>  If we really go "there" then we
> need to be able to grant access to "send mail as [email-masked]", and
>that's completely different from mailto:[email-masked].

I don't think we do.

>We'd need to define something like mailfrom:[email-masked].  This is
>why I'm punting by mapping everything onto a stub HTTP URI, because SASL
>exists in many places for which there is no defined URI.
>Does that explain it?

No.

The OAuth layer shouldn't need to know anything about the information
we're talking about whatsoever. It's client-asserted information to the
server that is then evaluated by the server upon completion of the
exchange. In most protocols it's going to be an ordinary, vanilla username.

You are making the mistake of trying to tie the asserted identity into the
OAuth token exchange so that it's backed by that mechanism, but you don't
have to do that.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 29 Aug 2012 04:33:08 +0000

>therefore GSS) mechanism and then say *noting* about the SASL

Just so it's clear from me, that was all I was expecting.

-- Scott

---

From: William Mills <[email-masked]>
Date: Tue, 28 Aug 2012 21:34:52 -0700 (PDT)

Just to be clear it is possible in OAuth to have *both* a client ID which would equate to an authZ ID and a ID in the token which would be an authN ID.   All this info might be carried in a Bearer token, or explicitly called out in OAuth 1.0a as the oauth_client.  If the client ID represents something  like a desktop client it (i.e. Flickr Uploadr client and mobile clients now) then that ID isn't probably really useful because it's effectively a user agent.  On the other hand it might be the client ID of a 3rd party in a 3 legged relationship, in which case it really is what we want.  I was leaving that the to the server to determine.

> From: Nico Williams <[email-masked]>
>Sent: Tuesday, August 28, 2012 9:05 PM

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Aug 2012 23:36:00 -0500

On Tue, Aug 28, 2012 at 11:23 PM, William Mills <[email-masked]> wrote:
> resources are represented as URIs.  The  access dance includes in some parts
> of the flow the URI of the resource for which access is being granted.  If
> we really go "there" then we need to be able to grant access to "send mail
> as [email-masked]", and that's completely different from
> mailto:[email-masked].  We'd need to define something like
> mailfrom:[email-masked].  This is why I'm punting by mapping everything
> onto a stub HTTP URI, because SASL exists in many places for which there is
> no defined URI.
>
> Does that explain it?

Yes.  I surmised that was your concern.  What we want is for the
authentication ID that is yielded on the server side to be in the form
of a GSS NAME object that the application can use to inquire about the
granted access.  Also, the display/exported name forms of an OAuth
authentication ID can actually be such that they encode the
authorizations granted.

But here's the key: you need not say anything at all about the SASL
authz-id.  It's irrelevant.  If a client asserts one then the
*application* gets to decide whether and how to use it in relation to
the OAuth authentication ID.  Given a complex/composite OAuth
authentication ID I don't think you'll have to worry about the
authz-ID at all.

So... just say nothing about authz-ids!

But, you will want to specify at least what the authentication ID
display form is, and preferably a canonicalization of it.  Here are
some possible authen IDs that I'm imagining:

 - <actual ID>: <authorization>[, ...]
    - [email-masked]: send-email-as:[email-masked]
    - anonymous: send-e-mail-as:[email-masked], send-email-as:[email-masked]

Canonicalization might require lower-casing case-insensitive
components of IDs and authorizations.  Or you might not specify a
canonicalization, just that the forms granted by the grantor are by
definition canonical (this is much easier!).

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 29 Aug 2012 04:39:09 +0000

>OAuth token exchange so that it's backed by that mechanism, but you don't

Actually, I'll caveat that. If the implementations of these SASL clients
is such that the client asserted identity is fed into the mechanism and
expected to be carried through as the client identity in the underlying
mechanism, then I would see the problem.

Since that's a fatal problem in most mechanisms, I think it would have to
get fixed anyway, and it can't be fixed by trying to legislate away the
fact that the client's view of its name and the mechanism's view just
aren't necessarily the same.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Aug 2012 23:50:02 -0500

On Tue, Aug 28, 2012 at 11:34 PM, William Mills <[email-masked]> wrote:
> Just to be clear it is possible in OAuth to have *both* a client ID which
> would equate to an authZ ID and a ID in the token which would be an authN
> ID.   All this info might be carried in a Bearer token, or explicitly called
> out in OAuth 1.0a as the oauth_client.  If the client ID represents
> something  like a desktop client it (i.e. Flickr Uploadr client and mobile
> clients now) then that ID isn't probably really useful because it's
> effectively a user agent.  On the other hand it might be the client ID of a
> 3rd party in a 3 legged relationship, in which case it really is what we
> want.  I was leaving that the to the server to determine.

If OAuth itself can carry an authz-id and its semantics are not
*exactly* the same as the semantics of SASL authz-id, then it's best
to not try to conflate the two.  I'm assuming that the semantics of
the two are in fact different.

The gs2-header should carry the SASL authz-id and nothing more, and
you should say nothing about this.

What I do think needs to be covered is the display/exported name forms
of OAuth clients.  Because we don't want to lose fine-grained authz
data, and because fine-grained authz data is OAuth's raison d'etre,
you should specify a name form that preserves (encodes) all that authz
data.  If OAuth has an internal authz-id concept then this is where
that authz-id would show up.

When I say "display/exported name form" I'm really referring to
GSS-API concepts.  In GSS we have names represented as opaque objects
-- NAME in the abstract API, gss_name_t in the C bindings -- and these
names can be queried.  For example, you would apply GSS_Display_name()
to a NAME to find its display form, and you'd apply GSS_Export_name()
to obtain its "exported name token" (an octet string) form.  You'd
call GSS_Import_name() with either a string and a name-type to get a
NAME, or with an exported name token and a special name-type
(GSS_C_NT_EXPORTED_NAME).  SASL/GS2 says very little about this...

Now, normally a GSS mechanism would authenticate users and services to
each other, and if there is additional fine-grained authorization data
delivered by the mechanism, then that is to be accessed via
GSS_Get_name_attribute() and friends.

In this case I think you could argue that because OAuth's entire
purpose is to deliver fine-grained authz data the display and exported
name forms of OAuth names must encode that data.

See my other reply showing some sample OAuth names.

Nico

PS: The query/display/exported name forms of a GSS mechanism are one
of the key things to document when specifying a GSS mechanism.  Since
OAuth would be a GSS mechanism, this is something that must be
covered.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Aug 2012 07:43:20 +0200

Sorry for stepping into this late, but just a question:

On 8/29/12 6:23 AM, William Mills wrote:
> Because OAuth is about granting access to a resource, and in many
> cases resources are represented as URIs.  The  access dance includes
> in some parts of the flow the URI of the resource for which access is
> being granted.  If we really go "there" then we need to be able to
> grant access to "send mail as [email-masked]", and that's completely
> different from mailto:[email-masked].  We'd need to define something
> like mailfrom:[email-masked].

We don't use a different syntax in SMTP between MAIL FROM: and RCPT TO:
(with the exception of <>).  Why would this be necessary here?

Eliot

---

From: William Mills <[email-masked]>
Date: Tue, 28 Aug 2012 22:45:29 -0700 (PDT)

OK!  Now I'm getting it I think, having read this and your other (longer) message.  I think that accepting the form provided by the grantor is right, although the server itself might have a display name that it knows independent of what's carried in the token.

So then, here's language I think does what you are saying:

...
    user (REQUIRED):
        The authentication ID. The server MAY use this as a routing or database lookup hint. The user name MUST agree with the identity asserted by the OAuth credential.

...

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.

3.2.2. Canonicalization

The identity asserted by the OAuth authorization server is canonical for display. The server MAY provide a different canonical form based on local data.

>Cc: "Cantor, Scott" <[email-masked]>; Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, August 28, 2012 9:36 PM
>Subject: Re: [kitten] URis Re: Comma vs. %x01 Re: OAuth SASL draft -05
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Aug 2012 08:47:17 +0100

> assertion", or perhaps something else.

I am very confused: the format of authorization identities is controlled by protocols using SASL and not by mechanisms. It MUST NOT be specified in a SASL mechanism.

So what kind of URI are we talking about???

---

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

While they may be the same SMTP servers for sending outbound mail from authenticated users on a domain are typically different than the mail exchangers used for sending mail to that domain.  The mailto: scheme could perhaps be overloaded for this purpose, but in this use case what we need is something that identifies for a user how they can send mail in an authenticated fashion and not how to send something to the user.

-bill

> From: Eliot Lear <[email-masked]>
>Sent: Tuesday, August 28, 2012 10:43 PM
>Because OAuth is about granting access to a resource, and in many cases resources are represented as URIs.  The  access dance includes in some parts of the flow the URI of the resource for which access is being granted.  If we really go "there" then we need to be able to grant access to "send mail as [email-masked]", and that's completely different from mailto:[email-masked].  We'd need to define something like mailfrom:[email-masked].
>>
>We don't use a different syntax in SMTP between MAIL FROM: and RCPT
    TO: (with the exception of <>).  Why would this be necessary
    here?

---

From: William Mills <[email-masked]>
Date: Wed, 29 Aug 2012 08:12:03 -0700 (PDT)

Yes, an OAuth SASL mechanism has to be able to take a credential and map it to an identity that works in the specific protocol.

> From: Alexey Melnikov <[email-masked]>
>To: Nico Williams <[email-masked]>; William Mills <[email-masked]> 
>Sent: Wednesday, August 29, 2012 12:47 AM

---

From: Luke Howard <[email-masked]>
Date: Thu, 30 Aug 2012 10:22:52 +1000

> I am very confused: the format of authorization identities is controlled by protocols using SASL and not by mechanisms. It MUST NOT be specified in a SASL mechanism.

My understanding is that we are conflating SASL and OAuth authorisation identities. SASL authorisation identities should be carried per the GS2 specification and are for the SASL implementation or application to handle, not the mechanism. OAuth authorisation semantics might be exposed via GSS naming extensions.

-- Luke

---

From: William Mills <[email-masked]>
Date: Wed, 29 Aug 2012 22:35:40 -0700 (PDT)

How is the mechanism different form the application in this case?  I really don't get why there is a problem here, in fact this wasn't a problem until the gs2-header actually got added.  

Why can't the mechanism itself be asserting the identity?

>To: Alexey Melnikov <[email-masked]> 
>Cc: Nico Williams <[email-masked]>; William Mills <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Wednesday, August 29, 2012 5:22 PM

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 30 Aug 2012 10:06:15 +0200

William Mills <[email-masked]> writes:

> How is the mechanism different form the application in this case?  I
> really don't get why there is a problem here, in fact this wasn't a
> problem until the gs2-header actually got added. 

Before the gs2-header was added, the mechanism did not support
transferring an authzid which would be a serious problem.  Adding the
gs2-header solves both the GS2 compatibility issue, and enables
transport of the authzid.

> Why can't the mechanism itself be asserting the identity?

The authzid is asserted by the SMTP/IMAP/etc client.  I agree with Luke
that we shouldn't conflate SASL and OAuth authorization identities.
SASL mechanisms should transfer a SASL authzid and that's it.  The SASL
authzid should not be involved in anything the mechanism does.

/Simon

>>Cc: Nico Williams <[email-masked]>; William Mills
>> <[email-masked]>; "[email-masked]" <[email-masked]>
>>> I am very confused: the format of authorization identities is
>>> controlled by protocols using SASL and not by mechanisms. It MUST
>>> NOT be specified in a SASL mechanism.
>>
>>My understanding is that we are conflating SASL and OAuth
>> authorisation identities. SASL authorisation identities should be
>> carried per the GS2 specification and are for the SASL
>> implementation or application to handle, not the mechanism. OAuth
>> authorisation semantics might be exposed via GSS naming extensions.
>>
>>-- Luke
>>
>>

---

From: William Mills <[email-masked]>
Date: Thu, 30 Aug 2012 08:06:23 -0700 (PDT)

Authz id has always been supported in this draft.

Given the way it's currently written is there a problem?

>Cc: Luke Howard <[email-masked]>; Alexey Melnikov <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Thursday, August 30, 2012 1:06 AM

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Aug 2012 10:07:31 -0500

On Thu, Aug 30, 2012 at 12:35 AM, William Mills <[email-masked]> wrote:
> How is the mechanism different form the application in this case?  I really

I dont'get this question :)  The mechanism and the application are
entirely different :)

> don't get why there is a problem here, in fact this wasn't a problem until
> the gs2-header actually got added.
>

Only the client application asserts an authz-id.  The mechanism is
only required to transport it.

The mechanism transports the authz-id, via the gs2-header.  Why via
the gs2-header?  Because GSS mechanisms *do not* have an authz-id
concept, so the authz-id has to be carried outside the _GSS_ mechanism
but _inside_ the SASL mechanism.  The whole point of the gs2-header is
to make it possible to use GSS mechanisms as SASL mechanisms.  So a
GSS mechanism used with the gs2-header (and a SASL mech name) *is* a
SASL mechanism.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Aug 2012 10:15:58 -0500

> Given the way it's currently written is there a problem?

I think we're talking about the text of section 3.2.1, and the 'user'
key/value described in section 3.1.

Section 3.2.1 describes an authorization ID that has very different
semantics from the SASL authz-id, or at least that is so *to my
reading*.  If my reading is wrong and the authz-id described in 3.2.1
has SASL-compatible semantics then what you should do is simply remove
the 'user' key in section 3.1.  Else if my reading is correct then you
need to distinguish the OAuth authz-id from the SASL authz-id.

Nico
--

---

From: William Mills <[email-masked]>
Date: Thu, 30 Aug 2012 08:27:00 -0700 (PDT)

User is needed in the purely SASL part of this so if the gs2 header isn't available then it has to be carried somewhere.  I can require that they be identical if that will help.

>Cc: Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Thursday, August 30, 2012 8:15 AM

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Aug 2012 11:09:28 -0500

On Thu, Aug 30, 2012 at 10:27 AM, William Mills <[email-masked]> wrote:
> User is needed in the purely SASL part of this so if the gs2 header isn't
> available then it has to be carried somewhere.  I can require that they be
> identical if that will help.

But...  the whole point is that in a SASL context the gs2-header is
always present so why would the gs2-header not be available?   It
wouldn't be available only in a pure GSS, non-SASL context -- a
context in which we don't need an authz-id anyways.

My advice: remove the 'user' key.

---

From: William Mills <[email-masked]>
Date: Thu, 30 Aug 2012 09:13:35 -0700 (PDT)

One purpose of the user key is as a routing hint.  Are you sayng that would never be needed in a GS2 environment?

>Sent: Thursday, August 30, 2012 9:09 AM

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Aug 2012 11:20:34 -0500

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Aug 2012 11:26:02 -0500

> never be needed in a GS2 environment?

Can you add some detail regarding routing?  Routing of what?  How does
an authz-id help with routing?  (The I-D doesn't go into any more
detail; a search for 'rout', 'database', 'lookup', or 'hint' did not
turn up anything more than the one sentence in section 3.1 about
this.)

Not knowing what the routing thing is about I can't tell you if that
would be needed in a GSS/non-SASL context.  However, since pure OAuth
on the web clearly doesn't need this routing hint (otherwise you'd not
be adding it here, right?), I don't think we should need it in a pure
GSS (GSS, not GS2) environment.

Nico
--

---

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

The problem the routing hint solves is large installations that have "shards" an you want to be able to send proxied traffic on to the correct internal endpoint.

>Sent: Thursday, August 30, 2012 9:26 AM

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Aug 2012 14:21:22 -0500

On Thu, Aug 30, 2012 at 11:42 AM, William Mills <[email-masked]> wrote:
> The problem the routing hint solves is large installations that have
> "shards" an you want to be able to send proxied traffic on to the correct
> internal endpoint.

I must be missing a lot of context.  What's that got to do with
authz-ids??  Can't the authenticated ID be used for this?  How does
OAuth, natively, outside SASL, deal with this?

---

From: Ryan Troll <[email-masked]>
Date: Thu, 30 Aug 2012 12:52:19 -0700

I asked for this to be included, so let me give my use case.

Our resource servers are fronted with proxies, which take care of routing
requests to a back-end capable of servicing the entire request.  The proxy
needs to be able to determine which back-end to talk to.  This applies to
multiple classes of resource servers -- being accessed via IMAP, SMTP,
XMPP, etc.

The proxy makes its back-end determination based on "a hint" sent by the
client.  We believe the proxy should be able to determine the hint without
the need to actually verify the OAuth Token -- especially important when
the tokens are Opaque, and possibly require additional round trips to
unpack.

Prior to this discussion, back around draft -03, we introduced the User
header in order to pass the User header.

After reading through this discussion - and I admit, I'm still confused
about when the gs2 header is and isn't present - I believe the "hint"
should be the SASL Authorization Identity.  Here's my rationale, comments
welcome:

Looking at "SASL PLAIN", one of the simplest mechanisms, I believe this is
how things should work:

  AUTH PLAIN bob \0 jane \0 jane-password

should successfully allow Jane, to perform actions on Bob's behalf,
assuming jane-password is correct *and* the server knows Jane's been given
access to access Bob's account.  The proxy described above would be able to
route based on "bob".

Likewise:

  AUTH PLAIN jane \0 jane-password

would let Jane perform actions on her own behalf, and the proxy would route
on "jane".  (Authzid based on Authcid, RFC 4616, section 2, next to last
paragraph.)

It would be beneficial to do the same in the OAuth mechanism.  Even if the
Authzid equivalent field is defined the same way PLAIN does (optional, if
missing server bases authzid on authcid), services that require this hint
may leverage it.

-R

---

From: William Mills <[email-masked]>
Date: Thu, 30 Aug 2012 12:56:20 -0700 (PDT)

OAuth doesn't deal with it.  Some applications do.  

Here are the requirements, I DO NOT CARE how this gets solved but I really want to stop going around and around on this.  We went from user field in the spec, to gs2-header, to gs2-header and user field, now we're back to gs2-header only.  Requirements:

-    user name available to the mechanism outside the credential.  I am presuming this needs to be true even when the gs2-header is stripped.

-    authZ 
and authN IDs have to be based on the credential but are not part of the actual credential validation.    

-    Mismatch between the user name above and the actual identity from the credential causes a fail. 

Gimme a solution an I'll write it that way.  I am assuming the current text I sent to the list isn't acceptable.

-bill

>Sent: Thursday, August 30, 2012 12:21 PM

---

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

On Thu, Aug 30, 2012 at 2:52 PM, Ryan Troll <[email-masked]> wrote:
> multiple classes of resource servers -- being accessed via IMAP, SMTP, XMPP,
> etc.
>
> the need to actually verify the OAuth Token -- especially important when the
> tokens are Opaque, and possibly require additional round trips to unpack.

OK, but why should the 'user' be the hint for this?  Why not something else?

> about when the gs2 header is and isn't present - I believe the "hint" should
> be the SASL Authorization Identity.  Here's my rationale, comments welcome:

The gs2-header will be present in all SASL contexts -- that is, in SASL apps:

 - IMAP
 - LDAP
 - POP3
 - SUBMIT (SMTP)
 - ...

The gs2-header will be absent in all pure GSS contexts:

 - NFS (v3 and v4)
 - SSHv2 (yes, SSHv2 can use GSS)
 - FTP
 - DNS updates with GSS-TSIG
 - ...

> Looking at "SASL PLAIN", one of the simplest mechanisms, I believe this is

SASL PLAIN is not a GS2 mechanism.

We should probably explain what GS2 is again :)

GS2 is a "bridge" that allows GSS-API mechanisms to be used as SASL mechanisms.

Alternative phrasing: GS2 is a pattern for constructing SASL
mechanisms such that they can also be used as GSS-API mechanisms.

Here we're building a SASL mechanism based on OAuth such that it can
also be used as a GSS mechanism.

The main requirement for this is the gs2-header: it must be prepended
to the first message from the client, and it must be prepended to the
channel binding data.

There exist implementations of SASL/GS2 that use GSS-API to implement
the GS2 mechanisms for arbitrary GSS-API mechanisms.  These
implementations could never use the authz-id as a routing hint: the
GSS-API layer wouldn't receive it.

Duplicating the authz-id beyond the gs2-header is *fine*, but only if
it's OPTIONAL, and in pure GSS-API contexts it would always be absent,
which includes SASL/GS2 client implementations that use the GSS-API.

> should successfully allow Jane, to perform actions on Bob's behalf, assuming
> jane-password is correct *and* the server knows Jane's been given access to
> access Bob's account.  The proxy described above would be able to route
> based on "bob".
>
> Likewise:
>

But basing the authzid on the authcid is a completely local thing.
You can't have the OAuth SASL mechanism specification depend on it.

My first reaction to the routing hint idea is that basing it on the
authz-id is very much the wrogn thing to do.  You should use only the
authcid, if that.  My second reaction is the same :)  but maybe I'm
missing something?

> missing server bases authzid on authcid), services that require this hint

This says that you're prepared to have the routing hint be missing.
Good.  See above.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Aug 2012 15:19:49 -0500

Regarding your frustration, I think it'd be a good idea ot have a
conference call.  I'd be happy to have such a call with you -perhaps a
video call?- and I'd be happy to have a conference call with more
people.  Right now it seems that having a conference call with at
least you and Ryan plus one or more of the SASL and GSS-API usual
suspects would be good, but I can do a 1-1 call on short notice this
week, right now.

Note that part of the frustration here is that the "routing hint" was
not described in any detail, thus it was very easy for anyone
reviewing the I-D to miss completely.  Thus we've been unable to
understand each other.  Now that the routing hint is becoming clearer
we will probably communicate better.

On Thu, Aug 30, 2012 at 2:56 PM, William Mills <[email-masked]> wrote:
> Here are the requirements, I DO NOT CARE how this gets solved but I really
> want to stop going around and around on this.  We went from user field in
> the spec, to gs2-header, to gs2-header and user field, now we're back to
> gs2-header only.  Requirements:
>
> -    user name available to the mechanism outside the credential.  I am
> presuming this needs to be true even when the gs2-header is stripped.

It would never be present in a pure GSS-API context since there's no
such concept in GSS_Init_sec_context().

You say you "presume" that this must be present -- how can you know
that this is a requirement if you're only presuming it?

Meanwhile Ryan has explained why he asked for this and it seems (to my
reading of what Ryan said) that it is not really required.  Certainly
it's not required by OAuth itself since otherwise you'd not be
*adding* this key/value in the first place.

So is this a requirement?  To me it seems that the answer is "no".

Moreover, this requirement, if it really is a requirement, basically
makes it impossible to use this as a GSS-API mechanism.  But I have
very strong doubts about this being an actual requirement.

> -    authZ and authN IDs have to be based on the credential but are not part
> of the actual credential validation.

In SASL authz-ids are NOT to be used by the mechanism in any way.
SASL authz-ids are application-specific, and it's up to the client
whether to assert one or not.

This means you can't possibly rely on the authz-id to setup a
required-to-be-present 'user' key/value.  You could use the authz-id
when one is given, but what would you do when one is not?

> I sent to the list isn't acceptable.

We should hear from Ryan a response to my response to him about this.
I suspect the routing hint is either not strictly necessary or else
that we'll decide that we don't want it at all, which in either case
would make this issue go away.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Aug 2012 15:30:27 -0500

Also, I think that the semantics of the SASL authz-id really preclude
using it as a way of representing
impersonation/delegation/delegation-of-authorization in the OAuth
sense.  I see that it might be tempting to do so, but I don't think
it's appropriate.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 30 Aug 2012 14:39:15 -0600

On 8/30/12 2:30 PM, Nico Williams wrote:
> Also, I think that the semantics of the SASL authz-id really
> preclude using it as a way of representing 
> sense.  I see that it might be tempting to do so, but I don't
> think it's appropriate.

I tend to agree, and I think it would be good to explain why
(somewhere; it doesn't necessarily belong in this I-D). That would
help avoid similar confusion in the future.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ryan Troll <[email-masked]>
Date: Thu, 30 Aug 2012 13:44:42 -0700

> the

The quick, service specific answer: because I want to route your IMAP
request to the systems that house your IMAP data.  As a resource server, I
know where "[email-masked]"'s mail is housed, and want to connect you to
it, for the quickest, best data access possible.

Why not something else?  I'm open to suggestions - my guess is that it's
really service specific.

> SASL PLAIN is not a GS2 mechanism.

True, but for the purpose of demonstrating my use case, not using a GS2
mechanism was preferred.  I opted for using the simplest scenario to
explain it, and that got us to some good discussion points about authz-id
vs authc-id.

<Cutting out excellent, clear description of when and why GS2 is present --
thanks for the clarification!>

> You can't have the OAuth SASL mechanism specification depend on it.

I'm sorry, I don't understand.

We have existing SASL mechanisms that state just this - PLAIN being an
example.  Are they incorrect?

> authcid, if that.  My second reaction is the same :)  but maybe I'm

Using authc-id sounds reasonable.

I phrased things as authz-id, rather than authc-id, as the first definition
I found for the two indicated authz-id was "identity to act as", and I was
trying to come up with a use case that demonstrated this need.  My example
was a bit of a stretch, and using authc-id instead works for me.

> This says that you're prepared to have the routing hint be missing.

Yes, but that support is likely to be "fail the request, and in the error
response return a link to the faq".  Our faq / developer documentation
would cover what needs to be done, on top of this work, in order to get
clients to interoperate with us.

I originally brought this idea to the list because we have/will require
this "hint", and I'd prefer to see use a well defined, potentially optional
field.  This has the benefit of working for more than just us -- if another
resource server of significant size wanted to do the same thing, they can
use the same data, and clients won't need to do something "unique" for each
service provider.

Authc-id will work, as long as it's available without the need to unpack
the OAuth credential.

-R

---

From: Ryan Troll <[email-masked]>
Date: Thu, 30 Aug 2012 13:48:35 -0700

> suspects would be good, but I can do a 1-1 call on short notice this

If this will help, a video call will work.  Somebody will need to walk me
through what you guys use for your VCs. :)

reading of what Ryan said) that it is not really required.

[Follow-up in the other thread.]

-R

---

From: Shawn Emery <[email-masked]>
Date: Thu, 30 Aug 2012 14:55:06 -0600

On 08/30/12 02:48 PM, Ryan Troll wrote:
> On Thu, Aug 30, 2012 at 1:19 PM, Nico Williams <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> If this will help, a video call will work.  Somebody will need to walk 
> me through what you guys use for your VCs. :)

We've used the IETF's account for audio conferencing through WebEx in 
the past.  For the folks that wish to join this call please respond to 
me individually so that we can agree upon a time.

> [Follow-up in the other thread.]
Shawn.
--

---

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

> Why not something else?  I'm open to suggestions - my guess is that it's

Oh, I thought this was a routing that OAuth needed, not the
application.  This helps a lot.

So, the IMAP server should check the authz-id that comes out of SASL
(really, the gs2-header, in the case of GS2 mechanisms) or, if there's
no authz-id, then the authcid, and use that.  You'll almost certainly
be using mailbox names or some sort of user ID as the authz-id when
it's present, and this is something that you tell your users to do, so
you have control over this.  If there's no authz-id you may need to do
some lookup based on the authcid because there's no requirement that
the two types of ID be of the same form (indeed, they'll almost never
be of the same form).

This was never something you should have asked of the OAuth SASL
mechanism :)  As an application that uses SASL your application should
use the attributes that SASL exposes -- this will make your
application able to use other SASL mechanisms.

(The whole point of SASL, and GSS-API, is to be pluggable security
framework so that SASL (or GSS) apps can be pluggable themselves.  A
pluggable layer must impose some constraints on their plugins, else
the pluggable layer is infeasible.  A constraint here is that you must
treat the mechanisms' messages as opaque, and that you must deal with
the mechanisms in ways that SASL (or GSS) specify.  So, for example,
your application should not parse mechanism messages to extract
authz-ids!  Instead you must get that out of a SASL layer.  Of course,
you could build an application that just has a switch statement and
implements some mechanisms all by itself, but your application then
won't be pluggable.  Note that SASL apps and mechanisms came first,
then the SASL specification came latter: it turned out that a certain
pattern was followed every time and developers wanted a library
instead of big switch statements in their code.  Abstraction as a
pluggable layer was possible because the pattern was repeated, and
abstraction made it easier to re-use code.)

I'm eliding the rest -though I may respond to some of it separately-
because I think the above is sufficient to get us past this problem.
I think it should be clear now that we don't need the 'user'
key/value, that the routing function that you want to perform is an
application-routing function that should use as inputs only SASL
outputs (rather than OAuth mechanism-specific items), and that this
routing function must be mindful of SASL semantics (there's always an
authcid, but it's mechanism-specific, whereas there may, but need not
be, an authz-id that is *application-specific* (and typially
application-specific means that a user types in some string as the
authz-id into a field of some UI, and the server operator tells the
user what string to type in there when the user enrolls, which means
that in a way the server operator has control over the form of
authz-ids).

I want to expand a bit more on the difference between authcid and
authz-id.  An authcid is always mechanism-specific.  For some
mechanisms the authcid is free-form (e.g., PLAIN), but for others it
has very specific forms (e.g., Kerberos, where the form will be a
principal name in the string representation given in RFC1964, usually
of the form username@REALM in the case of IMAP clients).  Whereas the
authz-id is application-specific.  An application protocol is free to
define the form of authz-ids: for example, LDAP could say that
authz-ids *must* be DNs (and IIRC it does say so, but I'm not going to
check right now).  But some application protocols don't specify the
form of the authz-id, in which case the server operator has full
control over the form of authz-ids (even in the case of LDAP the
server operator controls the DNs that clients are free to assert as
authz-ids anyways, the operator just doesn't get to specify forms
other than DNs).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Aug 2012 16:19:35 -0500

> through what you guys use for your VCs. :)

As Shawn says webex is what we typically use for IETF meetings.  For a
1-1 call I'd be happy to use Skype or Google Talk.  But any meetings
that go beyond 1-1 should generally be announced here and open to all
participants (in particular any consensus arrived at on conference
calls or physical meetings must be confirmed on the list; also the
IETF NOTE WELL rules should be announced in any conference call).  I'm
offering to do 1-1s with you and with William just to clear up
confusion over SASL semantics and GS2.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Aug 2012 16:31:39 -0500

On Thu, Aug 30, 2012 at 3:44 PM, Ryan Troll <[email-masked]> wrote:
> mechanism was preferred.  I opted for using the simplest scenario to explain
> it, and that got us to some good discussion points about authz-id vs
> authc-id.

Actually, it's a bad example because it doesn't really constrain
authcids, and so you will be tempted to think that authcid and
authz-ids share the same namespace, and to be clear, they do not.

A better example would be Kerberos, where the authcids are Kerberos
principal names written as strings of this form:

   <component1>[/<component2>[.../<componentN>@<realm>

with '/' and '@' in any components escaped with a '\'.  Typically user
principal names have one component.

> I'm sorry, I don't understand.

See my other replies.

> example.  Are they incorrect?

Does the specification of PLAIN contradict me?  It's possible, but if
so it will be an anachronism.

> Using authc-id sounds reasonable.

Just remember that the form of authcids varies by mechanism.

> was a bit of a stretch, and using authc-id instead works for me.

Yes, this is very confusing about authcid and authz-ids.  They have
different namespaces but "identity to act as" tends to imply that they
have the same namespace.  They don't.

>> > [...]
> response return a link to the faq".  Our faq / developer documentation would
> cover what needs to be done, on top of this work, in order to get clients to
> interoperate with us.

Exactly; now you understand :)  You will likely tell your users to
specify the authz-id, not in such terms but, rather, you'll tell them
what to put in in the typical GUIs (in Evolution, in Thunderbird, in
Outlook, etcetera).

> I originally brought this idea to the list because we have/will require this
> "hint", and I'd prefer to see use a well defined, potentially optional
> Authc-id will work, as long as it's available without the need to unpack the
> OAuth credential.

And of course it absolutely should be.  If you look at Cyrus SASL, for
one example, you'll find that the authcid is exposed to the server
application.  The application also gets the mechanism name, so that it
can interpret the authcid if necessary (though typically you'll just
use the authcid as a DB lookup key, though you should really be using
{<mechanism>, <authcid>} as a compound lookup key...).

Nico
--

---

From: Ryan Troll <[email-masked]>
Date: Thu, 30 Aug 2012 14:40:31 -0700

> And of course it absolutely should be.

Perhaps this is the root of the problem - I was unable to see how, in any
of the pre-GS2 based OAUTH/SASL specs, I was going to determine the
authc-id without mucking with the OAuth2 token.

Now that we're all in agreement that GS2 must be present in the SASL
request, and that folks such as myself should use the
{<mechanism>,<authcid>} for shard hinting, I could really use an example
that shows where the authcid is within the OAUTH/SASL protocol.

Your example of Thunderbird is a great one.  What do we tell the Mozilla
developers - assuming they have a UI that allows a user to enter a name (
[email-masked]) and an oauth token (nicos-refresh-token), and Mozilla
supports all of the appropriate OAuth magic, where does Thunderbird put the
name ([email-masked]) in the "AUTHENTICATE OAUTH" command?

-R

---

From: Luke Howard <[email-masked]>
Date: Fri, 31 Aug 2012 09:21:31 +1000

> check right now).  But some application protocols don't specify the

RFC 4513 5.2.1.8:

      authzId = dnAuthzId / uAuthzId

      ; distinguished-name-based authz id
      dnAuthzId =  "dn:" distinguishedName

      ; unspecified authorization id, UTF-8 encoded
      uAuthzId = "u:" userid
      userid = *UTF8 ; syntax unspecified

-- Luke

---

From: William Mills <[email-masked]>
Date: Thu, 30 Aug 2012 18:45:09 -0700 (PDT)

A conference call can happen, and I'd be happy to do that, but I don't know if it's really needed.  The problem statement is pretty clear I think at this point.

Whether or not it is "according to spec" there will be implementations that will be making decisions like which storage node to talk to based on the ID we get from the SASL mechanism.

All that remains is to determine how the ID of the user/entity is being conveyed.

-bill

>To: Ryan Troll <[email-masked]> 
>Cc: William Mills <[email-masked]>; "[email-masked]" <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Thursday, August 30, 2012 2:19 PM
>Subject: Re: [kitten] requirements/context/frustration Re: Comma vs. %x01 Re: OAuth SASL draft -05
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Aug 2012 23:47:25 -0500

On Thu, Aug 30, 2012 at 8:45 PM, William Mills <[email-masked]> wrote:
> A conference call can happen, and I'd be happy to do that, but I don't know
> if it's really needed.  The problem statement is pretty clear I think at
> this point.
>
> Whether or not it is "according to spec" there will be implementations that
> will be making decisions like which storage node to talk to based on the ID
> we get from the SASL mechanism.
>

If you ask Ryan I think he'll tell you that it's settled: remove the
'user' key/value (and section 3.1.2).

Nico
--

---

From: William Mills <[email-masked]>
Date: Thu, 30 Aug 2012 23:00:32 -0700 (PDT)

Where does that username come from in a GS2 mechanism? 

>Cc: Ryan Troll <[email-masked]>; "[email-masked]" <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Thursday, August 30, 2012 9:47 PM

---

From: Luke Howard <[email-masked]>
Date: Fri, 31 Aug 2012 16:10:31 +1000

It can be sent in the authorisation ID field of the GS2 header.

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Aug 2012 01:21:32 -0500

> Where does that username come from in a GS2 mechanism?

We should speak of authcid and authz-id.  The authcid comes from the
SASL mechanism.  The authz-id is provided by the client application
and transported by the SASL mechanism. SASL/GS2 mechanisms transport
the authz-id in the gs2-header.

(GSS-API mechanisms have no concept of authz-id.  GSS-API applications
that want an authz-id, like SSHv2, have to find some other way to
transport it.  SASL/GS2 *is* a GSS-API application of sorts, and it
uses the gs2-header (integrity protected by being prefixed to the CB
data) to transport the authz-id.)

Nico
--

---

From: William Mills <[email-masked]>
Date: Fri, 31 Aug 2012 07:35:16 -0700 (PDT)

So even though the gs2-header is stripped off before being passed into the mechanism that information is available to the mechanism?

>Sent: Thursday, August 30, 2012 11:21 PM

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Aug 2012 09:51:35 -0500

On Aug 31, 2012 10:35 AM, "William Mills" <[email-masked]> wrote:
>
> So even though the gs2-header is stripped off before being passed into
the mechanism that information is available to the mechanism?

Not to OAuth the GSS mechanism, no, but that's ok.  It's the OAuth SASL
mech that must output the authz-id, and that's before the gs2-header gets
stripped, so all's good.

Nico
--

---

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

But then we lack the cleartext value in the GSS mechanism?

>Cc: [email-masked]; Ryan Troll <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Friday, August 31, 2012 7:51 AM
>Not to OAuth the GSS mechanism, no, but that's ok.  It's the OAuth SASL mech that must output the authz-id, and that's before the gs2-header gets stripped, so all's good.
>Nico
>-- 
>
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Aug 2012 10:25:32 -0500

> But then we lack the cleartext value in the GSS mechanism?

The GSS mechanism doesn't deal in authz-ids -- authz-ids are foreign
to the GSS-API.

Nico
--

---

From: William Mills <[email-masked]>
Date: Fri, 31 Aug 2012 08:45:40 -0700 (PDT)

We want an ID in clear text (not contained in the token) to be present for use by the mechanism, how do we solve this?  Gs2-header clearly isn't it.

>Cc: "[email-masked]" <[email-masked]>; Ryan Troll <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Friday, August 31, 2012 8:25 AM

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Aug 2012 10:53:57 -0500

On Fri, Aug 31, 2012 at 10:45 AM, William Mills <[email-masked]> wrote:
> We want an ID in clear text (not contained in the token) to be present for
> use by the mechanism, how do we solve this?  Gs2-header clearly isn't it.

Now I'm the one who's frustrated.  I suspect you're not reading what I
wrote, probably because you've reached the frustration level where
you'd stop reading what we have to say.

You only need an authz-id in a SASL context.  You do not need an
authz-id in a GSS context.

gs2-header present -> SASL context.

gs2-header absent -> GSS context.

Ryan needs an authz-id, absolutely needs it.  He only needs it in SASL contexts.

Nico
--

---

From: William Mills <[email-masked]>
Date: Fri, 31 Aug 2012 09:01:41 -0700 (PDT)

I was looking for parity between the GSS and SASL contexts so that the same things can be supported in both.  

>Sent: Friday, August 31, 2012 8:53 AM

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Aug 2012 11:03:58 -0500

> things can be supported in both.

Semantically infeasible.  That's why we have GS2, to bridge the gap.
Be conformant to GS2 and you get SASL and GSS for the price of one.

---

From: Ryan Troll <[email-masked]>
Date: Fri, 31 Aug 2012 14:44:15 -0700

Sorry for the delay in responding - I just got back and read through this.

I suspect you're both right, the frustration level in this thread is high.
 One thing that was eye-opening to me is that the GS2 header winds up only
being available to the SASL mechanism.  Given the name - GS2 - when I first
read about it, I formed the opinion that it would be present when the
mechanism is being used within GSS-API, and not SASL.  Nico's clarified
that a few messages ago, which helped me.

For protocols utilizing SASL, the proposal would be that the body
communicated from the Client to the Server contains a GS2 header, and that
header would be available for use by the OAuth mechanism.  The data I'm
looking for, and originally asked to be in the User: header, is in the GS2
header.  As a result, the presence of the GS2 header lets me meet my needs.

My assumption is that, for protocols utilizing GSS-API, the information
within the GS2 header is actually communicated between the Client and the
Server via (given my lack of GSS-API knowledge) GSS-API Magic.  The OAuth
mechanism can get to this information - for example, the authz-id - by
looking at the GSS-API wrapper, rather than the data transmitted as part of
the OAuth mechanism.  In other words, the GS2 header defines a way to
transmit the data that GSS-API sends, but SASL doesn't.

*Nico:*  If this summary sounds correct, I'm declaring a small victory for
your description and helping me along.  And I agree, the GS2 header
contains the data I want, and meets my needs.

*Bill:  *If Nico says this summary is correct, I believe that your ultimate
goal -- parity between SASL and GSS such that OAuth
mechanism authors (Client and/or Server) have access to all of the same
information -- has been achieved, with the addition of the GS2 header.

Finally, if you both agree, I believe a phone call is not necessary.

-R

On Fri, Aug 31, 2012 at 9:03 AM, Nico Williams <[email-masked]>wrote:

> > I was looking for parity between the GSS and SASL contexts so that the
> same
> > things can be supported in both.
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Aug 2012 17:02:04 -0500

On Aug 31, 2012 5:44 PM, "Ryan Troll" <[email-masked]> wrote:
> I suspect you're both right, the frustration level in this thread is
high.  One thing that was eye-opening to me is that the GS2 header winds up
only being available to the SASL mechanism.  Given the name - GS2 - when I
first read about it, I formed the opinion that it would be present when the
mechanism is being used within GSS-API, and not SASL.  Nico's clarified
that a few messages ago, which helped me.

Ah, heh.  "GS2" = next generation replacement for the first SASL/GSS
bridge.  We took to calling them gs1 and gs2.

If you look at RFC2222 you'll see the original bridge.  There were some
aspects of gs1 that made us sad, useful though it had been.  So we built a
replacement.  (GS1 became RFC4752.]

Right.

Pure GSS-API apps must communicate anything like an authz-id in the app
prptocol.  Look at how SSHv2 does it -- see RFC4256.

> Nico:  If this summary sounds correct, I'm declaring a small victory for

Yes, see above for a slight correction regarding pure GSS-API apps.

> Bill:  If Nico says this summary is correct, I believe that your ultimate

Do not try to get SASL features in the pure GSS case that GSS doesn't
support.  Just usr the gs2-header in the SASL case and accept the absence
of authz-id in the GSS case.

> Finally, if you both agree, I believe a phone call is not necessary.

It'd still be good to "meet" so we can firm a better relationship such that
in the future we might avoid frustration altogether :)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 31 Aug 2012 18:28:27 -0500

I clarify: in the pure GSS case any missing features should added to the
app protocol.  Examples of that:  how SSHv2 deals with the username when
using GSS, NFS' RPCSEC_GSSv3, and if you think of GS2 as a GSS application
(which it basically is), then GS2.

---

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

Nico,

As a subtext here you keep saying "don't do that" to the use case where we need to have access to the user ID.   That's a key part of the frustration here, you're not proposing a solution that solves the problem in all cases.  Evidently there's some good reason for this.  I personally don't care about the case where the gs2-header isn't present, but intellectually I want these things to be equivalent.  

Is the miscommunication here that you do not accept the use case that we need access to the identity?  That we're solving different problems?

-bill

>Cc: [email-masked]; William Mills <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Friday, August 31, 2012 3:02 PM
>> I suspect you're both right, the frustration level in this thread is high.  One thing that was eye-opening to me is that the GS2 header winds up only being available to the SASL mechanism.  Given the name - GS2 - when I first read about it, I formed the opinion that it would be present when the mechanism is being used within GSS-API, and not SASL.  Nico's clarified that a few messages ago, which helped me.
>Ah, heh.  "GS2" = next generation replacement for the first SASL/GSS bridge.  We took to calling them gs1 and gs2.
>If you look at RFC2222 you'll see the original bridge.  There were some aspects of gs1 that made us sad, useful though it had been.  So we built a replacement.  (GS1 became RFC4752.]
>
>> For protocols utilizing SASL, the proposal would be that the body communicated from the Client to the Server contains a GS2 header, and that header would be available for use by the OAuth mechanism.  The data I'm looking for, and originally asked to be in the User: header, is in the GS2 header.  As a result, the presence of the GS2 header lets me meet my needs.
>Right.
>> My assumption is that, for protocols utilizing GSS-API, the information within the GS2 header is actually communicated between the Client and the Server via (given my lack of GSS-API knowledge) GSS-API Magic.  The OAuth mechanism can get to this information - for example, the authz-id - by looking at the GSS-API wrapper, rather than the data transmitted as part of the OAuth mechanism.  In other words, the GS2 header defines a way to transmit the data that GSS-API sends, but SASL doesn't.  
>Pure GSS-API apps must communicate anything like an authz-id in the app prptocol.  Look at how SSHv2 does it -- see RFC4256.
>> Nico:  If this summary sounds correct, I'm declaring a small victory for your description and helping me along.  And I agree, the GS2 header contains the data I want, and meets my needs.
>> Bill:  If Nico says this summary is correct, I believe that your ultimate goal -- parity between SASL and GSS such that OAuth mechanism authors (Client and/or Server) have access to all of the same information -- has been achieved, with the addition of the GS2 header. 
>Do not try to get SASL features in the pure GSS case that GSS doesn't support.  Just usr the gs2-header in the SASL case and accept the absence of authz-id in the GSS case.
>It'd still be good to "meet" so we can firm a better relationship such that in the future we might avoid frustration altogether :)
>Nico
>-- 
>
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Sat, 1 Sep 2012 00:46:17 +0000

On 8/31/12 7:41 PM, "William Mills" <[email-masked]> wrote:
>
>As a subtext here you keep saying "don't do that" to the use case where
>we need to have access to the user ID.

You CANNOT do this with GSS-API. That's why he's saying "don't do that".

>That's a key part of the frustration here, you're not proposing a
>solution that solves the problem in all cases.  Evidently there's some
>good reason for this.  I personally don't care about the case where the
>gs2-header isn't present, but intellectually I want these things to be
>equivalent.

They can't be. GSS-API does not have a concept of an authorization ID.
That's the "good reason". It's not appropriate for mechanisms to introduce
concepts that would be expected to surface at the application layer
because that would make applications non-portable to mechanisms that
didn't support that concept.

An exception to this is an example like the name attributes extension.
That was developed so that modern mechanisms like SAML that expose user
identity as more than just a simple string can expose that additional
data. But by making it an extension, applications are able to control
whether they directly depend on that extension rather than treating it as
a mechanism specific feature.

>Is the miscommunication here that you do not accept the use case that we
>need access to the identity?  That we're solving different problems?

He's not denying your use case, it's simply not one that is permitted by
the API. If you want that feature, it has to show up in the application
protocol itself, much as it shows up in SASL generically (so thus becomes
usable across protocols that support SASL).

I think you should consider that when you started this, you had a SASL
mechanism. Some of us want that mechanism to be GSS-capable. But in doing
so, we do not ask that you provide a feature (authzid) that we know cannot
in fact be part of your mechanism. So we're not asking you to provide that.

Does that help?

-- Scott

---

From: Luke Howard <[email-masked]>
Date: Sat, 1 Sep 2012 10:51:07 +1000

Bill,

> As a subtext here you keep saying "don't do that" to the use case where we need to have access to the user ID.   That's a key part of the frustration here, you're not proposing a solution that solv…

I understand your concern. I believe the answer is: in protocols that use GSS directly, the authorisation identity equivalent is transmitted in the application protocol itself (for example SSH does this).

Now, of course there may be application protocols that use GSS directly and don't have such an equivalent. It's a trade-off, because to introduce an authorisation identity directly into a GS2 mechanism would result in this information being duplicated for the majority case, and would break the abstraction (i.e. you couldn't implement OAuth as a GSS mechanism and use it [with the appropriate bridge] with SASL). Also, Ryan's requirement would only be satisfied for OAuth, rather than all GS2 mechanisms (it seems less than ideal for a load-balancer to only work with one particular security mechanism).

The alternative is to specify a SASL mechanism that doesn't fit the GS2 profile, which is fine. But then you don't get GSS support, so you're back where you started. So my advice would be to accept this trade-off and specify it as a GS2 mechanism.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Sat, 1 Sep 2012 10:52:47 +1000

I should have read Scott's message first, he explains things more clearly/absolutely than I did.

---

From: William Mills <[email-masked]>
Date: Fri, 31 Aug 2012 17:56:04 -0700 (PDT)

OK, between this and Scott's message I now understand.

Thank you.

>Cc: Nico Williams <[email-masked]>; Ryan Troll <[email-masked]>; "[email-masked]" <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Friday, August 31, 2012 5:51 PM

---

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

Draft -06 is posted.  Ir removes the user field, adds canonicalization language, and once again fixes the examples to be current.

-bill

>To: Luke Howard <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Friday, August 31, 2012 5:56 PM