Subject: [kitten] Google and SASL OAuth

From: William Mills <[email-masked]>
Date: Tue, 18 Sep 2012 09:16:39 -0700 (PDT)

Google has released XOAUTH2 support which looks like it's based on -03 of the SASL OAuth draft.  Since then the user= element has been removed.  At this point user can easily be added back in as an optional KV pair.  My question is whether we should do that with a "MAY" just to explicitly make the changes to XOAUTH2 implementations be minimal (if any).  

I'm leaning toward the "working code" argument here.  Thoughts?

Thanks,

-bill

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Sep 2012 11:33:05 -0500

On Tue, Sep 18, 2012 at 11:16 AM, William Mills <[email-masked]> wrote:
> Google has released XOAUTH2 support which looks like it's based on -03 of
> the SASL OAuth draft.  Since then the user= element has been removed.  At
> this point user can easily be added back in as an optional KV pair.  My
> question is whether we should do that with a "MAY" just to explicitly make
> the changes to XOAUTH2 implementations be minimal (if any).
>

I would say that unknown KV keys MUST be ignored by the server.

Also, the maintainer of that implementation should be informed of this change.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Sep 2012 11:37:20 -0500

Also, is that a client-only implementation?  Sending an unnecessary KV
is not very harmful.  Expecting one on the server side is.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Sep 2012 20:32:20 +0300

Hi Bill,

I have only seen the info at this page 
https://developers.google.com/talk/jep_extensions/oauth and it does not 
give me enough details to judge whether there is similarity to the SASL 
OAuth draft.

Ryan, who is on CC, seems to be the lead developer (as I can understand 
from 
http://googledevelopers.blogspot.nl/2012/09/adding-oauth-20-support-for-imapsmtp.html). 
Ryan, can you shed some light on the relationship to OAuth SASL.

Of course it would be good to see that work had been re-used and is 
deployed in Google. I would also be interested to hear the motivation 
for omitting the user element.

Ciao
Hannes

On 09/18/2012 07:16 PM, William Mills wrote:
>
> Google has released XOAUTH2 support which looks like it's based on -03
> of the SASL OAuth draft.  Since then the user= element has been
> removed.  At this point user can easily be added back in as an optional
> KV pair.  My question is whether we should do that with a "MAY" just to
> explicitly make the changes to XOAUTH2 implementations be minimal (if any).
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Ryan Troll <[email-masked]>
Date: Tue, 18 Sep 2012 10:47:03 -0700

Sure.  A little history:

- The XMPP implementation has been around for quite a while, and used as
part of a larger product.  When I started looking at SASL/OAuth, this was
already available, documentation ready, and about to be announced publicly.
 Rather than have separate announcements, we merged their announcement with
the IMAP/SMTP announcement.

- The IMAP/SMTP implementation was started more recently, and is based on
version -03 of the spec.

In both cases, the mechanism name does not match the spec.  This approach
allowed us to launch without waiting for the draft, and provides us a
simple way to introduce RFC compliance later without breaking any work
previously done.

Once the draft moves to RFC status, I'm planning on working with the teams
to add support for the RFC-defined mechanism.  Now that our systems support
dealing with the OAuth 2.0 credential, the work should be minimal.

As for omitting the user information, your basically looking at why I had
originally asked to add this field as Optional -- not all services benefit
from it.  I'm not familiar enough with our XMPP service to explain why,
while our IMAP and SMTP implementations do use it.

Bill:

Thanks for considering adding the user= field in order to make the move
from XOAUTH2 to this standard easier, but I'm not sure it's worth it.  If
the GS2 header is required, the data is already there, and clients that
wish to add OAUTH support to their XOAUTH2 client will simple reformat the
request a bit.

-R

On Tue, Sep 18, 2012 at 10:32 AM, Hannes Tschofenig <
[email-masked]> wrote:

> Hi Bill,
>
> I have only seen the info at this page https://developers.google.com/**
> talk/jep_extensions/oauth<https://developers.google.com/talk/jep_extensions/oauth>and it does not give me enough details to judge whether there is similarity
> to the SASL OAuth draft.
>
> from http://googledevelopers.**blogspot.nl/2012/09/adding-**
> oauth-20-support-for-imapsmtp.**html<http://googledevelopers.blogspot.nl/2012/09/adding-oauth-20-support-for-imapsmtp.html>).
> deployed in Google. I would also be interested to hear the motivation for
> omitting the user element.
>
> Ciao
> Hannes
>
>
>> ______________________________**_________________
>> Kitten mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/kitten<https://www.ietf.org/mailman/listinfo/kitten>
>>
>>
>

---

From: William Mills <[email-masked]>
Date: Tue, 18 Sep 2012 11:41:04 -0700 (PDT)

Unfortunately the authz-id in the gs2-header is not mandatory according to the spec, and I'm not allowed to make it mandatory in the mechanism.  I think you will end up needing to document that it is required for integrating with Google.

-bill

>________________________________
> From: Ryan Troll <[email-masked]>
>To: Hannes Tschofenig <[email-masked]> 
>Cc: William Mills <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, September 18, 2012 10:47 AM
>Subject: Re: [kitten] Google and SASL OAuth
> 
>
>Sure.  A little history:
>
>
>- The XMPP implementation has been around for quite a while, and used as part of a larger product.  When I started looking at SASL/OAuth, this was already available, documentation ready, and about to be announced publicly.  Rather than have separate announcements, we merged their announcement with the IMAP/SMTP announcement.
>
>
>- The IMAP/SMTP implementation was started more recently, and is based on version -03 of the spec.
>
>
>In both cases, the mechanism name does not match the spec.  This approach allowed us to launch without waiting for the draft, and provides us a simple way to introduce RFC compliance later without breaking any work previously done.
>
>
>Once the draft moves to RFC status, I'm planning on working with the teams to add support for the RFC-defined mechanism.  Now that our systems support dealing with the OAuth 2.0 credential, the work should be minimal.
>
>
>
>
>As for omitting the user information, your basically looking at why I had originally asked to add this field as Optional -- not all services benefit from it.  I'm not familiar enough with our XMPP service to explain why, while our IMAP and SMTP implementations do use it. 
>
>
>Bill:
>
>
>Thanks for considering adding the user= field in order to make the move from XOAUTH2 to this standard easier, but I'm not sure it's worth it.  If the GS2 header is required, the data is already there, and clients that wish to add OAUTH support to their XOAUTH2 client will simple reformat the request a bit.
>
>
>-R
>
>
>
>
>On Tue, Sep 18, 2012 at 10:32 AM, Hannes Tschofenig <[email-masked]> wrote:
>
>Hi Bill,
>>
>>I have only seen the info at this page https://developers.google.com/talk/jep_extensions/oauth and it does not give me enough details to judge whether there is similarity to the SASL OAuth draft.
>>
>>Ryan, who is on CC, seems to be the lead developer (as I can understand from http://googledevelopers.blogspot.nl/2012/09/adding-oauth-20-support-for-imapsmtp.html). Ryan, can you shed some light on the relationship to OAuth SASL.
>>
>>Of course it would be good to see that work had been re-used and is deployed in Google. I would also be interested to hear the motivation for omitting the user element.
>>
>>Ciao
>>Hannes
>>
>>

---

From: William Mills <[email-masked]>
Date: Tue, 18 Sep 2012 11:43:10 -0700 (PDT)

Hannes, 

Are you asking about omitting the user element from the draft?  That was done because it's duplicating the data that may be carried in the gs2-header authz-id and we don't want to have the same data element in two places because if they disagree it's a problem (among other things).

-bill

> From: Hannes Tschofenig <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: Ryan Troll <[email-masked]>; "[email-masked]" <[email-masked]>; [email-masked] 
>Sent: Tuesday, September 18, 2012 10:32 AM

---

From: William Mills <[email-masked]>
Date: Tue, 18 Sep 2012 11:48:09 -0700 (PDT)

So leave "user" unregistered and make sure it won't cause conflict?

I've added "Unknown key/value pairs MUST be ignored by the server." to section 3.1.

> From: Nico Williams <[email-masked]>
>Cc: Ryan Troll <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, September 18, 2012 9:33 AM

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Sep 2012 13:57:11 -0500

On Tue, Sep 18, 2012 at 12:32 PM, Hannes Tschofenig
<[email-masked]> wrote:
> [...] I would also be interested to hear the motivation for omitting
> the user element.

See the KITTEN WG list archives.  Short version: the user element was
there as a result of a misunderstanding about SASL, SASL/GS2, and
GSS-API semantics.

Nico
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Sep 2012 22:05:20 +0300

Hi Bill,

On 09/18/2012 09:43 PM, William Mills wrote:
> Hannes,
>
> Are you asking about omitting the user element from the draft?

Sorry, I should have phrased the sentence better. I was mainly 
interested to hear more from Ryan about his design.

Ideally, it would be good to get the two specs in sync but sending 
duplicate data isn't so useful. Maybe Ryan can change the code at some 
point in time.

Ciao
Hannes

>
> -bill
>
>
>     ------------------------------------------------------------------------
>     *From:* Hannes Tschofenig <[email-masked]>
>     *To:* William Mills <[email-masked]>
>     *Cc:* Ryan Troll <[email-masked]>; "[email-masked]"
>     <[email-masked]>; [email-masked]
>     *Sent:* Tuesday, September 18, 2012 10:32 AM
>     *Subject:* Re: [kitten] Google and SASL OAuth
>
>     Hi Bill,
>
>     https://developers.google.com/talk/jep_extensions/oauth and it does
>     not give me enough details to judge whether there is similarity to
>     the SASL OAuth draft.
>
>     Ryan, who is on CC, seems to be the lead developer (as I can
>     understand from
>     deployed in Google. I would also be interested to hear the
>     motivation for omitting the user element.
>
>     Ciao
>     Hannes
>
>      > [email-masked] <mailto:[email-masked]>

---

From: William Mills <[email-masked]>
Date: Tue, 18 Sep 2012 12:27:58 -0700 (PDT)

Yeah, they intentionally used the mech name XOAUTH2 so they can move to a spec compliant implementation on the names from the spec.  Their work, form my quick read is compliant with -03 of the spec, and the only significant change between that and -07 is that the gs2-header authz-id replaces the "user" kv pair.

>Cc: Hannes Tschofenig <[email-masked]>; Ryan Troll <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, September 18, 2012 12:05 PM
>>      >
>>      > Google has released XOAUTH2 support which looks like it's based
>>     on -03
>>      > of the SASL OAuth draft.  Since then the user= element has been
>>      > removed.  At this point user can easily be added back in as an
>>     optional
>>      > KV pair.  My question is whether we should do that with a "MAY"
>>     just to
>>      > explicitly make the changes to XOAUTH2 implementations be minimal
>>     (if any).
>>      >
>>      > I'm leaning toward the "working code" argument here.  Thoughts?
>>      >
>>      > Thanks,
>>      >
>>      > -bill
>>      >
>>      >
>>      > _______________________________________________
>>      > Kitten mailing list
>>      > [email-masked] <mailto:[email-masked]>
>>      > https://www.ietf.org/mailman/listinfo/kitten
>>      >
>>
>>
>>
>
>
>
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Sep 2012 14:33:28 -0500

On Tue, Sep 18, 2012 at 2:27 PM, William Mills <[email-masked]> wrote:
> Yeah, they intentionally used the mech name XOAUTH2 so they can move to a
> spec compliant implementation on the names from the spec.  Their work, form
> my quick read is compliant with -03 of the spec, and the only significant
> change between that and -07 is that the gs2-header authz-id replaces the
> "user" kv pair.

OK, given that they used a non-standard mechanism name I think I don't
care.  We should, however, state what should be done about unknown
key/value pairs; I have no opinion on what would be best to say about
that.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Sep 2012 22:01:42 +0200

> wish to add OAUTH support to their XOAUTH2 client will simple reformat the

I'm puzzled -- could you expand on what use you make of the user field?
Like Nico, I believe it was only ever there because of a
misunderstanding.  If you make use of it, and really requires it, I
wonder if something is missing.  What do clients put in the user field,
and how do servers use that information?

/Simon

---

From: Ryan Troll <[email-masked]>
Date: Tue, 18 Sep 2012 13:37:17 -0700

Our IMAP implementation requires the user, such as "[email-masked]",
along with the OAuth credential.  This allows us to route the request to
the appropriate backend, without the need to perform operations on the
opaque OAuth credential.  When the request reaches the backend identified
by the username, the credential is validated to ensure that the client has
been granted permission to access the user's content.  If the request
reaches "[email-masked]"'s backend, but the credential is for "
[email-masked]", the request will fail with an authentication failure.

Simon:  Does this answer your question?

Hannes: Yes, once this draft is standardized we will add support for
the conformant SASL mechanism.

Bill: Agreed.  When this draft becomes the law, we'll advertise that we
require the documented GS2 header.

-R

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Sep 2012 23:09:43 +0200

> [email-masked]", the request will fail with an authentication failure.

Thanks for explaining.  To be sure I understand completely: you COULD
have found out the [email-masked] identity by looking into the OAuth
credential (possibly using some database that eventually map the OAuth
credential to the particular user), couldn't you?  So this is just a
convenience hint for front-ends, and the internal server double-checks
whether the supplied hint was indeed the right one.  Right?

Finally: The backend makes no use of the routing hint except for
comparing it with the identity implied by the OAuth credential?  What
I'm looking for to confirm is that there is never any doubt to the
internal server which user identity the OAuth credential belongs to.

> Simon:  Does this answer your question?

Yes.  If your use-case is important, there could be a field inside the
OAuth mechanism to convey this information so that servers doesn't have
to look into the OAuth credential.

This routing hint field has nothing whatsoever to do with the SASL
authcid or authzid though.

But if you are able to implement your system without this routing hint,
it is indicative that others will be in the same situation, so I would
prefer to drop the field since it adds no information but just require
more text in the document to describe.

/Simon

---

From: Ryan Troll <[email-masked]>
Date: Tue, 18 Sep 2012 14:32:32 -0700

> credential to the particular user), couldn't you?

Yes, this COULD have been done.

>  So this is just a

Yes.  Supplying an incorrect fails.

> internal server which user identity the OAuth credential belongs to.

This is my understanding.  However, it could be that the backend totally
ignores the hint, and only uses the data in the OAuth credential.  This
would lead to a user having access to his data even if the hint was wrong,
if (and only if) the hint mapped to the same backend as the user.

Regardless, the identity used for data access is the OAuth credential.  The
backend does not use the hint as authoritative for anything.

> to look into the OAuth credential.

This was considered and ruled out.  We're keeping our OAuth credentials
opaque, which means that frontends would need to perform additional work to
break it apart.

> more text in the document to describe.

Your recommendation is to just have Google document the user field as
something it needs outside of the spec?  In which case, the only difference
between our XOAUTH mechanism, and this draft, is the name of the mechanism
(plus our additional field)?

I was hoping to get something into this mechanism that would standardize
this scenario across service providers, but if the group's consensus is
that it doesn't make sense to do so, so be it.

-R

> > On Tue, Sep 18, 2012 at 1:01 PM, Simon Josefsson <[email-masked]
> >wrote:
> >

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Sep 2012 23:45:23 +0200

> Yes, this COULD have been done.

Good, that matches my understanding.  I understand doing so leads to
extra work that is always good to reduce.

> Yes.  Supplying an incorrect fails.

Good.

> if (and only if) the hint mapped to the same backend as the user.

Sure.  However a spec might demand that a comparison is always made.

> backend does not use the hint as authoritative for anything.

Right.  Although the specification could demand certain behaviour here,
like saying that if there is a mismatch between the routing hint and the
OAuth credential identity, authentication fails even if the OAuth
credential would otherwise be valid.

> opaque, which means that frontends would need to perform additional work to

Ok.  If everyone will have to go through additional implementation pains
due to this, that would warrant putting a routing hint back in.
However, if you are able to make it work, likely others will as well,
and then it is better to leave it out.

> (plus our additional field)?

I would recommend/hope that you implement the draft that eventually
comes out of this WG and phase out your experimental XOAUTH* stuff at
that point.

> that it doesn't make sense to do so, so be it.

Your input is part of the consensus process.  What I'm not getting now
is whether you can & will adapt to a design without a routing hint and
change your implementation, or if you'd rather publish a separate
document describing your variation of the mechanism and deploy that
under a different SASL name?  If the latter, I think we are having a WG
failure and need to reconsider what changes to the document would make
you happier.

/Simon

---

From: William Mills <[email-masked]>
Date: Tue, 18 Sep 2012 14:52:34 -0700 (PDT)

>I was hoping to get something into this mechanism that would 
standardize this scenario across service providers, but if the 
group's consensus is that it doesn't make sense to do so, so be it.

Authz-id can serve this purpose but it's not mandatory.  You can make it mandatory in your service documentation, that's as easy as making an optional field in the SASL data that you require.

>To: Simon Josefsson <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, September 18, 2012 2:32 PM
>This is my understanding.  However, it could be that the backend totally ignores the hint, and only uses the data in the OAuth credential.  This would lead to a user having access to his data even if the hint was wrong, if (and only if) the hint mapped to the same backend as the user.
>
>
>Regardless, the identity used for data access is the OAuth credential.  The backend does not use the hint as authoritative for anything.
>
>
> 
>This was considered and ruled out.  We're keeping our OAuth credentials opaque, which means that frontends would need to perform additional work to break it apart.
>
>
> 
>Your recommendation is to just have Google document the user field as something it needs outside of the spec?  In which case, the only difference between our XOAUTH mechanism, and this draft, is the name of the mechanism (plus our additional field)?
>
>
>I was hoping to get something into this mechanism that would standardize this scenario across service providers, but if the group's consensus is that it doesn't make sense to do so, so be it.
>
>
>-R
>
>
> 
>
>>/Simon
>>
>>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Sep 2012 00:09:25 +0200

William Mills <[email-masked]> writes:

> Authz-id can serve this purpose but it's not mandatory.  You can make
> it mandatory in your service documentation, that's as easy as making
> an optional field in the SASL data that you require.

No, the authzid cannot serve this purpose even if it were mandatory.
This is a misunderstanding.  Ryan wants the identity of the OAuth
credential owner as a routing hint to find a server that can verify the
OAuth credential for that user.  The authzid has nothing to do with
that.

I believe the routing hint and the SASL authentication identity will
always be the same for a successful authentication though.  However, the
authcid is implied from the OAuth credential, and since the routing hint
is not integrity protected, you couldn't say that the authentication
identity is always the routing hint.

Some mechanisms (PLAIN, SCRAM) transfer the authentication identity in
the clear and the OAuth mechanism could as well if people think it is
useful.

/Simon

>>This is my understanding.  However, it could be that the backend
>> totally ignores the hint, and only uses the data in the OAuth
>> credential.  This would lead to a user having access to his data
>> even if the hint was wrong, if (and only if) the hint mapped to the
>> same backend as the user.
>>
>>
>>Regardless, the identity used for data access is the OAuth
>> credential.  The backend does not use the hint as authoritative for
>> anything.
>>
>>
>> 
>>This was considered and ruled out.  We're keeping our OAuth
>> credentials opaque, which means that frontends would need to perform
>> additional work to break it apart.
>>
>>
>> 
>> something it needs outside of the spec?  In which case, the only
>> difference between our XOAUTH mechanism, and this draft, is the name
>> of the mechanism (plus our additional field)?
>>
>>

---

From: William Mills <[email-masked]>
Date: Tue, 18 Sep 2012 15:32:17 -0700 (PDT)

OK, so is it then reasonable to provide the user key/value as "A hint to the server that MAY be used as a routing hint for the server to find the correct credential authenticator.  The server MAY fail the authentication if the hint indicates the wrong authenticator for the credential."?

> From: Simon Josefsson <[email-masked]>
>Sent: Tuesday, September 18, 2012 3:09 PM

---

From: Ryan Troll <[email-masked]>
Date: Tue, 18 Sep 2012 15:36:19 -0700

> difference

I've already been telling folks here that we should implement this draft
once finalized.  Never had pushback, so I expect it will happen.

Removing the experimental stuff will depend on how many folks actually use
it.  If there's significant usage, there's no compelling reason for us to
work to move folks off of it, to something that is essentially a
re-ordering of the bits in the request.  We don't want to put developers
through busy-work.

> failure and need to reconsider what changes to the document would make

This came up back when I was describing this scenario to Nico.

No, we will not be changing to a design without a routing hint.  The Google
IMAP and SMTP services will continue to require it.  Making the routing
hint a cleartext part of the OAuth token is something we've considered and
ruled out -- we're endeavoring to keep the token 100% opaque, removing the
ability for abusers to glean any information about an account from a token.
 And we don't want to have a special token just for IMAP/SMTP.

I'm not plannong on publishing another SASL mechanism with this single
addition - that would not be beneficial to anybody.  If there is no place
to store this information in what's in the SASL/OAuth RFC, when we publish
a mechanism that is compliant with it, we'll document the additional item
we require (routing hint) in our developer documentation.  And endeavor to
have the failure error message enable developers to quickly identify this
difference.

I'd love to see a hint of sorts be part of the SASL/OAuth negotiation, as
we are likely not the only service provider with this requirement.  The
list has been great at listening and helping try to solve how to do this;
if it turns out this doesn't wind up in the standard, it's certainly not
for lack of trying.

-R

> >> >> > As for omitting the user information, your basically looking at
> why I
> >> had
> >> >> > from XOAUTH2 to this standard easier, but I'm not sure it's worth
> it.
> >>  If
> >> >> > wish to add OAUTH support to their XOAUTH2 client will simple
> reformat
> >> >> the
> >> >> > request a bit.
> >> >>

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 18 Sep 2012 23:05:34 +0000

>OAuth credential for that user.  The authzid has nothing to do with

I thought from the earlier description that the purpose of the hint was to
identify the server hosting the mailbox of the "effective" identity
involved, which to me seemed an awful lot like authzid.

For my own SASL understanding, how is it different? And where would
authzid or the routing hint here come from if not from the username
entered by the user into the client? And if so, how can they not be one
and the same?

-- Scott

---

From: Luke Howard <[email-masked]>
Date: Wed, 19 Sep 2012 11:28:45 +1000

> involved, which to me seemed an awful lot like authzid.

I am with Scott here in this understanding.

-- Luke

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Sep 2012 09:11:03 +0200

> involved, which to me seemed an awful lot like authzid.

That's not what I understand from the latest explanation: as I
understand Ryan, the routing hint is there to identify the server that
is able to validate the OAuth credential.  That makes the routing hint
effectively the authentication identity, although the routing hint
cannot be relied on as the authentication identity until the credential
has been validated to belonging to the claimed user.

Ryan could you clarify for us again, please?

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Sep 2012 09:47:48 +0200

William Mills <[email-masked]> writes:

> OK, so is it then reasonable to provide the user key/value as "A hint
> to the server that MAY be used as a routing hint for the server to
> find the correct credential authenticator.  The server MAY fail the
> authentication if the hint indicates the wrong authenticator for the
> credential."?

Yes, although let's first see if I understood Ryan correctly this time
around...

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Sep 2012 09:52:57 +0200

> re-ordering of the bits in the request.  We don't want to put developers

Sure. "phase out" can take a while.  If we do everything right,
implementations will migrate to the proper RFC variant and not the
X-variant eventually.

> have the failure error message enable developers to quickly identify this

To me this sounds as if you'd rather fork the spec than live without a
routing hint -- having a document describing something additional
outside the RFCs is essentially the same as forking it.

However, it seems there is still not agreement on what you are using the
routing hint for, so please reply to the other post whether it is to
find the server with the intended mailbox (authzid) or to find the
server that is able to verify the OAuth credential (authcid).

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Sep 2012 10:01:04 +0200

> I am with Scott here in this understanding.

The reason I interpreted this differently was that Ryan confirmed that
he could have gotten the routing hint information from the OAuth
credential but he preferred to treat the OAuth credential as opaque and
thus needed to get it from somewhere else.  I don't see how you could
ever hope to get the SASL authzid out of an OAuth credential?  The
authzid is asserted by the SASL client and is unrelated to the
credential...

...unless the application is assumed to acquire a new OAuth credential
for every unique SASL authzid it wish to use...?

/Simon

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Sep 2012 11:50:08 -0300

As near as I can make out the authzid should be usable for routing to the backend server that can validate the access token.
Is there a problem with it being in the GSS-API header?

One catch is that the value of the authzid needs to be the email/xmpp address you are trying to connect to.
Not something the client tries to interpret from the user authentication to the authorization server.

I was thinking this over and people seem to want to believe that there are one to one mappings between these identifiers.

There may be multiple email addresses associated with a IMAP box.
A account might have more than one Box (Not common but not impossible)
The account may itself be authenticated by a a federated login that accesses multiple services each with a IMAP mailbox.

I personally have a google apps email that is saml authenticated from a corporate SSO where there is no connection between my login name and my email.  

The client will do a OAuth authorization flow and get back a token that authorizes it for one (or more mailboxes) as nothing requires the client to send the target email to the authorization server that I can see.

The access token and the authzid may both be required to connect to the correct box. 

Especially where you are doing SAS hosing and the tokens might be encrypted to the RS I can see the value in having the external address for routing to get it to the correct backend server.

John B.

---

From: William Mills <[email-masked]>
Date: Wed, 19 Sep 2012 09:06:00 -0700 (PDT)

The hint is the user name being authenticated (as I've said multiple times previously).  The server is responsible for mapping the user name to the server (cluster) handling that user.

>To: "Cantor, Scott" <[email-masked]> 
>Sent: Wednesday, September 19, 2012 12:11 AM

---

From: William Mills <[email-masked]>
Date: Wed, 19 Sep 2012 09:14:22 -0700 (PDT)

I should be more general, the routing hint is the resource being accessed in the context of the connection.  The client needs to know this.  For the use cases I'm focused on that will be a user name.

> From: William Mills <[email-masked]>
>To: Simon Josefsson <[email-masked]>; "Cantor, Scott" <[email-masked]> 
>Sent: Wednesday, September 19, 2012 9:06 AM

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Sep 2012 13:52:18 -0300

It isn't necessarily a user name it is or should be an identifier for the resource being accessed.   

There may be more than one possible resource authorized by the access token as the authorization request is not for a specific resource as far as I can tell.   Generally if you ask for an email token the authorization server  will find that unambiguous and grant you something that gives you IMAP and SMTP access rights that may cover multiple IMAP resources if they exist.

There is no one to one mapping from the resource identifier to the user name.   There is a possible many to many situation.  

I might use a hotmail account to login to a gmail account.   

I recognize that traditionally the resource identifier and the user name are the same, but the world is now much more complicated.   I think you need both the resource identifier and grant unless the specific resource is passed to the authorization server in the request.

John B.

---

From: Ryan Troll <[email-masked]>
Date: Wed, 19 Sep 2012 09:52:51 -0700

> Ryan could you clarify for us again, please?

Generically, we want the hint to identify who the request is coming from.
 This allows a service to route the request to a backend capable of
servicing the request.  Other backends will not be able to successfully
access the requested data.

-R

---

From: Ryan Troll <[email-masked]>
Date: Wed, 19 Sep 2012 09:54:40 -0700

> outside the RFCs is essentially the same as forking it.

I hadn't considered this "forking the spec", but you have a valid point -
in which case: Yes, we'd fork the spec rather than live without this.

-R

---

From: Ryan Troll <[email-masked]>
Date: Wed, 19 Sep 2012 10:46:58 -0700

Good point re: OpenID.  I had to walk through this a few times to get
everything worked out right.  Here's the example I came up with:

Let's say I'm setting up "[email-masked]".  Going through the
web setup for "nifty-cool-email.org", I log in with my "
[email-masked]" address.  The end result of this setup is the
creation of "[email-masked]", which I can read through their
web interface.  Logging into the web interface involves me using the "log
in with your identity-provider.com account" functionality (button, etc.)

When setting up a desktop IMAP client to talk to nifty-cool-email.org, I
provide the client with the name of the email account I'm setting up (
[email-masked]).  The client will (eventually) be able to
take this, find the OAuth URLs associated with the service, and bring up a
browser allowing me to walk through the OAuth flow for nifty-cool-email.org.
 The first step of this flow is to log in, and logging in via
identity-provider.com is supported.

The end result of this OAuth flow is an OAuth credential, asserting my
nifty-cool-email.org identity and the fact I'm allowed to access the IMAP
service.  This OAuth credential, along with the name of the resource being
accessed ("[email-masked]") are sent via IMAP, and the IMAP
service use these to authenticate and authorize access.  It's up to the
service provider to confirm that the [Identity asserted by the OAuth
credential] has [granted the client access to this service] and [has
granted the client access to this data].

In this scenario, the Client has no idea what my
identity-provider.comidentity is, and has no need to.  It does know
what resource I'm attempting
to access.

As a result, I believe you're right - and my previous statement was
incorrect - the hint should identify what the request is trying to access.
 (This has been doubly confusing, as in my immediate use case, these two
values are the same.)

I hope the scenario example helps.
-R

On Wed, Sep 19, 2012 at 9:52 AM, John Bradley <[email-masked]> wrote:

> There may be more than one possible resource authorized by the access
> token as the authorization request is not for a specific resource as far as
> I can tell.   Generally if you ask for an email token the authorization
> server  will find that unambiguous and grant you something that gives you
> IMAP and SMTP access rights that may cover multiple IMAP resources if they
> exist.
>
> There is no one to one mapping from the resource identifier to the user
> name.   There is a possible many to many situation.
>
> I recognize that traditionally the resource identifier and the user name
> are the same, but the world is now much more complicated.   I think you
> need both the resource identifier and grant unless the specific resource is
> passed to the authorization server in the request.
>
> John B.
>
>
>
> I should be more general, the routing hint is the resource being accessed
> in the context of the connection.  The client needs to know this.  For the
> use cases I'm focused on that will be a user name.
>
>   ------------------------------
> *From:* William Mills <[email-masked]>
> *To:* Simon Josefsson <[email-masked]>; "Cantor, Scott" <
> [email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Wednesday, September 19, 2012 9:06 AM
> The hint is the user name being authenticated (as I've said multiple times
> previously).  The server is responsible for mapping the user name to the
> server (cluster) handling that user.
>
>
>   ------------------------------
> *From:* Simon Josefsson <[email-masked]>
> *To:* "Cantor, Scott" <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Wednesday, September 19, 2012 12:11 AM

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 13:02:24 -0500

> I am with Scott here in this understanding.

Me too.

I'm very confused by the turn this thread is taking.

Can we step back and state requirements clearly?

I thought the requirements were:

a) communicate the ID of the credential owner;
b) communicate what Ryan calls a "routing hint" but which we Scott,
Luke, Simon, and I believe is rightly the SASL authz-id;
c) communicate some other ID?  like the ID of the proxy using the credential?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 13:08:29 -0500

On Wed, Sep 19, 2012 at 11:14 AM, William Mills <[email-masked]> wrote:
> I should be more general, the routing hint is the resource being accessed in
> the context of the connection.  The client needs to know this.  For the use
> cases I'm focused on that will be a user name.

If the routing hint is the name of the resource then the routing hint
cannot be the username.

Just because a mailbox might have the same (fully-qualified) name as
the username does not make them the same.

This:

> >The hint is the user name being authenticated (as I've said multiple
>> times previously).  The server is responsible for mapping the user
>> name to the server (cluster) handling that user.

must therefore be wrong.

Nico
--

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Sep 2012 15:08:19 -0300

Right that is the sort of thing I was thinking of.   That will be more common especially with outsourcing enterprise email where there is still a enterprise AD doing the actual User authentication.

John B.

On 2012-09-19, at 2:46 PM, Ryan Troll <[email-masked]> wrote:

> Good point re: OpenID.  I had to walk through this a few times to get everything worked out right.  Here's the example I came up with:
> 
> 
> Let's say I'm setting up "[email-masked]".  Going through the web setup for "nifty-cool-email.org", I log in with my "[email-masked]" address.  The end result of this setup is the creation of "[email-masked]", which I can read through their web interface.  Logging into the web interface involves me using the "log in with your identity-provider.com account" functionality (button, etc.)
> 
> When setting up a desktop IMAP client to talk to nifty-cool-email.org, I provide the client with the name of the email account I'm setting up ([email-masked]).  The client will (eventually) be able to take this, find the OAuth URLs associated with the service, and bring up a browser allowing me to walk through the OAuth flow for nifty-cool-email.org.  The first step of this flow is to log in, and logging in via identity-provider.com is supported.
> 
> The end result of this OAuth flow is an OAuth credential, asserting my nifty-cool-email.org identity and the fact I'm allowed to access the IMAP service.  This OAuth credential, along with the name of the resource being accessed ("[email-masked]") are sent via IMAP, and the IMAP service use these to authenticate and authorize access.  It's up to the service provider to confirm that the [Identity asserted by the OAuth credential] has [granted the client access to this service] and [has granted the client access to this data].
> 
> In this scenario, the Client has no idea what my identity-provider.com identity is, and has no need to.  It does know what resource I'm attempting to access.
> 
> 
> As a result, I believe you're right - and my previous statement was incorrect - the hint should identify what the request is trying to access.  (This has been doubly confusing, as in my immediate use case, these two values are the same.)
> 
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 13:12:51 -0500

> (This has been doubly confusing, as in my immediate use case, these two

Right, that's the source of the confusion.

The right thing to do is to say that the IMAP server uses the authz-id
*if provided* as the resource name, else it *derives* one from the
authcid.

So I believe we're back to *not* needing the user KV.  Correct?

Nico
--

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Sep 2012 15:22:55 -0300

The ID of the client using the credential is mostly for OAuth 1 compatibility.  
The signature mechanism probably should use it as there is no guarantee that the keyid is globally unique to the authorization server or scoped to the client.

It has no relevance to the Oauth 2 RS, one of the reasons I suspect it is not mentioned in XOAuth2.

I think the notion of a ID of the credential owner is confusing and not relevant to a OAuth RS.

The resource owner makes a grant that wis translated into a access token.

The RS needs to know the resource being accessed and then determine if the token allows the access.

In some cases people overload the access token with additional state information about he context of the request. 
That is a implementation decision and outside of the OAuth 2 spec.

If you want to keep it clean fully specify the resource in the request separate from the access token.
The token may be encrypted and only inspect-able in the context of the resource by the RS.

John B.

---

From: Ryan Troll <[email-masked]>
Date: Wed, 19 Sep 2012 11:27:47 -0700

Sorry to keep this moving in circles; but I think with the OpenID example,
things were (at least for me) easier to visualize.

Nico:

> *if provided* as the resource name, else it *derives* one from the
This makes sense, and is what we came up with around 9/4.

> So I believe we're back to *not* needing the user KV.  Correct?

Correct.  I believe this discussion came up because we launched our OAuth2
support, which was based on version -03 of the draft, and Bill asked if
including it would make migration simpler. Nice to ask, but not necessary.

One thing that would make this really helpful would be an example of a
successful SASL/OAuth transaction, with the authc-id and authz-id included.

-R

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 19 Sep 2012 18:30:25 +0000

>So I believe we're back to *not* needing the user KV.  Correct?

I think the problem is that if they need the hint to route the request *up
front* to the right back end before the OAuth credential is even delivered
and evaluated, then you end up needing to require authzid or adding
something. I think that's the source of the problem.

If the client decides whether to supply an authzid independent of SASL
mech, then obviously it's not workable to say "when using OAuth, client
must supply authzid".

So I think it's an order of evaluation problem, when the hint is first
needed. If it's only needed after the OAuth token is received and the
authcid determined, then what you suggest sounds ok.

-- Scott

---

From: William Mills <[email-masked]>
Date: Wed, 19 Sep 2012 11:48:13 -0700 (PDT)

>authcid determined, then what you suggest sounds ok.

Yes, and the stated goal is that the hint is provided and used before the
token is validated.

> From: "Cantor, Scott" <[email-masked]>
>To: Nico Williams <[email-masked]>; Ryan Troll <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Wednesday, September 19, 2012 11:30 AM

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 13:49:11 -0500

> mech, then obviously it's not workable to say "when using OAuth, client

No, it's workable: the service provider just has to tell the customers
how to configure their client.  The problem is that it'd be nice to
not have to do that.

> authcid determined, then what you suggest sounds ok.

Neither the authz-id nor the authcid can be had without actually
consuming the SASL authentication messages.  The only way an order of
processing issue comes up is if the server implementation isn't
following SASL strictly.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 13:51:05 -0500

> Yes, and the stated goal is that the hint is provided and used before the

SASL does not allow that.  You see bits on the wire and you think
"hey, the bits I need are right there, so let's grab them", but the
frameworks involved make these bits opaque to you.  You don't have to
use an implementation of the framework, but you must not preclude
someone who chooses to do so from implementing the same functionality.

Nico
--

---

From: William Mills <[email-masked]>
Date: Wed, 19 Sep 2012 11:55:14 -0700 (PDT)

And tokens are an opaque blob and not decrypted by the routing server.

----- Original Message -----
> To: "Cantor, Scott" <[email-masked]>; Nico Williams <[email-masked]>; Ryan Troll <[email-masked]>
> Sent: Wednesday, September 19, 2012 11:48 AM

---

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

>how to configure their client.  The problem is that it'd be nice to

Perhaps, but I think it's nicer not to have to glue in extra mechanism
fields that have weird overlapping semantics too.

-- Scott

---

From: William Mills <[email-masked]>
Date: Wed, 19 Sep 2012 12:08:40 -0700 (PDT)

So have we danced around the floor again to the point where the gs2-header authzid can be used for this purpose and some services may require the client applications to send authz-id?

----- Original Message -----
> To: Nico Williams <[email-masked]>
> Sent: Wednesday, September 19, 2012 12:00 PM

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 19 Sep 2012 19:10:31 +0000

On 9/19/12 3:08 PM, "William Mills" <[email-masked]> wrote:

>So have we danced around the floor again to the point where the
>gs2-header authzid can be used for this purpose and some services may
>require the client applications to send authz-id?

I think we're still dancing, but it's probably a judgement call by the
folks more in tune with the trade-offs. My ill-informed opinion is as you
state.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 15:18:24 -0500

> someone who chooses to do so from implementing the same functionality.

I should say that if we were willing to obsolete all non-GS2 SASL
mechanisms and declare that all future SASL mechanisms must be GS2
mechanisms, *then* it'd be fair to make use of the gs2 header before
processing the rest of the mechanism's message(s) with the caveat that
the gs2-header is not authenticated until the other messages are
processed.

However, that'd be asking a lot :/

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Sep 2012 23:03:44 +0200

> Right, that's the source of the confusion.

Thanks Ryan for explaining another time.  I'm now in agreement that the
routing hint you want is effectively the authorization identity.

> *if provided* as the resource name, else it *derives* one from the

Agreed.  Alas, I believe Ryan is saying (fairly strongly) that this
wouldn't work for him though, as he cannot derive the authzid from the
authcid since the server end point needs to be routed (authzid-vice) to
the right machine before it is able to infer anything from the authcid.

/Simon

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 16:04:11 -0500

> the gs2-header is not authenticated until the other messages are

I should further say that the idea of using an authz-id prior to its
being authenticated makes me very nervous.  It's one thing if it helps
begin slow I/Os, but you have to be very careful not to leak
existential information to clients with invalid credentials.

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 16:10:56 -0500

> the right machine before it is able to infer anything from the authcid.

Hmm.  If you only use SASL mechanisms that bear an authz-id in the
first client authentication message and where the client can extract
that immediately, then it could be done.  It'd not be strictly SASL,
but it'd work.

I'd recommend that the "router" also be the node terminating SASL,
then the authz-id can always be available before having to know where
to route the application layer messages.

Now, perhaps Ryan has *two* routing problems: a) how to route the
processing of SASL authentication messages, b) how to route
post-authentication application messages.  If we think of these as two
distinct routing tasks (even if the routing outcome is always the same
for (a) and (b)) then we can say that the routing should be done as
follows:

 - make the SASL server framework implementation used by
   the router be a proxy such that the mechanism uses
   whatever information is available/appropriate to route the
   processing of the SASL authentication messages;

 - post-authentication let the router use the authz-id (or authcid)
   to route the application messages.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Sep 2012 23:22:05 +0200

> that immediately, then it could be done.  It'd not be strictly SASL,

This would essentially be achieved by having service provider specific
documents saying "you must send an authzid", right?  This could indeed
work in practice, but it feels like sacrifying part of the SASL design
and will require work for MUA implementers (few implementations expose a
authzid field to the user today), service providers (they need to
document this and explain how to configure popular clients) and for
users (read the documentation and configure their clients with an
authzid).

> to route the application layer messages.

Yes, this seems like a better model to me.

>    to route the application messages.

Yes.

/Simon

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 19 Sep 2012 21:33:20 +0000

>users (read the documentation and configure their clients with an

This was what I was really trying to ask, and I guess I didn't make it
clear. I had thought the default client behavior was in fact to populate
authz-id based on the usual "username" field in the client. If that's not
so, I'd say that's a major issue for what's being proposed. The mechanism
can't do anything about this because it's sitting inside the GS2 layer
unable to control what goes in that header, even if it wanted to.

So the two options seem to be:

- bite the bullet and add something mech-specific that also involves the
server side code not using standard SASL bits and groveling through mech
bits to find the hint

- not trying to do this and terminating the SASL at the front-end and
routing app traffic afterward

Even if semantically authzid is ok as a fit, the reality of clients is
going to trump pretty much everything else I would think.

-- Scott

---

From: Ryan Troll <[email-masked]>
Date: Wed, 19 Sep 2012 14:39:00 -0700

> users (read the documentation and configure their clients with an

This is all true, but I don't think this change is significant in the face
of the changes required to support OAuth.

An MUA that wants to incorporate OAuth support already has to rip out the
entire name/password concept, and replace it with something new.  This
something new is likely a page that says "Enter the email account you'd
like to add".  Upon entering a gmail/yahoo/hotmail/whomever account, the
client will bring up a browser window, pointing at that domain's OAuth
endpoint, allowing the user to traverse the OAuth flow, acquiring an OAuth
credential.  The browser closes, and the client connects via IMAP, sending
the OAuth credential in the SASL negotiation.

Granted, this example is a potential future (I'm assuming automatic
discovery of SMTP, IMAP, and OAuth endpoints) - but it demonstrates how
much the "Add An Account" flow will change to include OAuth.  I'm not sure
the addition of authz in the SASL negotiation has any significant impact on
the the MUA implementer, compared to getting the OAuth credential in the
first place.  And the User should not see any difference.

-R

---

From: William Mills <[email-masked]>
Date: Wed, 19 Sep 2012 14:44:16 -0700 (PDT)

+1

>Sent: Wednesday, September 19, 2012 2:39 PM
>On Wed, Sep 19, 2012 at 2:22 PM, Simon Josefsson <[email-masked]> wrote:
>
>This is all true, but I don't think this change is significant in the face of the changes required to support OAuth.
>
>
>An MUA that wants to incorporate OAuth support already has to rip out the entire name/password concept, and replace it with something new.  This something new is likely a page that says "Enter the email account you'd like to add".  Upon entering a gmail/yahoo/hotmail/whomever account, the client will bring up a browser window, pointing at that domain's OAuth endpoint, allowing the user to traverse the OAuth flow, acquiring an OAuth credential.  The browser closes, and the client connects via IMAP, sending the OAuth credential in the SASL negotiation.
>
>
>Granted, this example is a potential future (I'm assuming automatic discovery of SMTP, IMAP, and OAuth endpoints) - but it demonstrates how much the "Add An Account" flow will change to include OAuth.  I'm not sure the addition of authz in the SASL negotiation has any significant impact on the the MUA implementer, compared to getting the OAuth credential in the first place.  And the User should not see any difference.
>
>
>-R

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Sep 2012 23:46:16 +0200

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

> authz-id based on the usual "username" field in the client.

No, the authzid is typically left empty/absent by common IMAP/SMTP/XMPP
clients aimed at end-users.  Powertools for admins may have the ability
to specify an authzid, to be able to impersonate another user, although
I have rarely seen this used for anything but debugging or testing.
This is my experience at least.

I looked at Evolution, a popular MUA on GNU systems, and there is no
authzid field that I can see, just one field for "Username" which
translates to the authcid that is transfered by PLAIN/CRAM-MD5/etc.

> If that's not so, I'd say that's a major issue for what's being
> proposed. The mechanism can't do anything about this because it's
> sitting inside the GS2 layer unable to control what goes in that
> header, even if it wanted to.
>

I agree.

/Simon

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 16:49:01 -0500

> entire name/password concept, and replace it with something new.  This

Actually, this is true in general.  OAuth is hardly the only mechanism
for which a name & password in a dialog is not appropriate.  Kerberos
has the same problem, for example (e.g., if the user is using PKINIT
or OTPs).

> something new is likely a page that says "Enter the email account you'd like
> to add".  Upon entering a gmail/yahoo/hotmail/whomever account, the client
> will bring up a browser window, pointing at that domain's OAuth endpoint,
> allowing the user to traverse the OAuth flow, acquiring an OAuth credential.

Well, whether it's a browser or something else, the point is that what
happens here is mechanism-specific.  (Though I am of the mind that all
user interaction for acquiring "cooked" credentials should be done via
a "trusted"captive/embedded browser using XHR to talk to the
mechanisms via trusted channels.  In that case all interaction would
be via a browser indeed.)

Back to the routing problem though, does thinking of it as being two
routing problems help?  (see earlier post)

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 19 Sep 2012 23:52:09 +0200

> first place.  And the User should not see any difference.

I don't dispute any of this.  However, I think you are ignoring the
non-MUA world that may also want to use OAuth, and they are typically
running generic GSS-API or SASL libraries that are modelled after the
GSS-API and SASL designs.  So by requiring the OAuth SASL mechanism to
be treated specially, you are losing the advantages of using a plugin
architecture where you can rely on some things behave the same
regardless of mechanism used.  Having a stable overall architecture is
an advantage even to the MUA world in the long run.

/Simon

---

From: Ryan Troll <[email-masked]>
Date: Wed, 19 Sep 2012 15:12:07 -0700

> an advantage even to the MUA world in the long run.

Very fair; you are right, I was focusing on MUAs.

-R

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Sep 2012 00:13:23 +0200

Let's see if we can take a step back and (re-)analyze another variant.

One way to resolve this issue without affecting the SASL design wrt
authzid would be to add another key-value field (for example) "resource
identity" that transfers the identity that Ryan could route on and that
clients would have to supply.  Then Ryan's implementation would simply
be unable to support a non-empty authzid, since the routing has already
happened and cannot be re-routed at that point, but that is okay --
failing on non-empty authzid is the typical response if nothing else has
been negotiated out-of-band between user and service provider.  The
"resource identity" would be a new concept introduced by the OAuth
mechanism, which is also fine.  The document would have to be careful in
explaining this concept so there is no confusion with the authzid.

I think I would prefer this, if the other alternative is to always
require that the authzid is non-empty.

I know we have been over this a few times, but what is the disadvantage
with this approach?  Is it worse than requiring a non-empty authzid?

/Simon

---

From: Ryan Troll <[email-masked]>
Date: Wed, 19 Sep 2012 15:16:38 -0700

>    to route the application messages.

I believe this is a reasonable way of looking at the problem.

-R

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 17:16:58 -0500

On Wed, Sep 19, 2012 at 5:13 PM, Simon Josefsson <[email-masked]> wrote:
> clients would have to supply.  [...]

The problem with this is that it's a change to SASL that existing
implementations can't take advantage of.  It's like adding an authz-id
to the GSS-API: it's a big deal.

Before we do anything of the sort I'd like to see if the
two-routing-problems approach solves Ryan's problem.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 17:18:23 -0500

On Wed, Sep 19, 2012 at 5:16 PM, Ryan Troll <[email-masked]> wrote:
>> Now, perhaps Ryan has *two* routing problems:
>

Great!  Is it also sufficient for your purposes, that is, does it
address your problem?

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Sep 2012 00:24:57 +0200

Nico Williams <[email-masked]> writes:

> implementations can't take advantage of.

I don't follow.  What implementations, OAuth or SASL implementations?

Adding another data field from the client to the server seems
straightforward to me.  Presumably, the OAuth mechanism will require
some data from the client.  If this is only a OAuth bearer token or both
an OAuth bearer token and resource identity does not seems significant.
The client needs to get the data from his provider somehow.  All of this
is strictly the mechanism's own business, and the SASL design is not
involved.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Sep 2012 00:26:50 +0200

> two-routing-problems approach solves Ryan's problem.

I should have replied to this as well...  I would prefer if the
two-routing way of looking at it resolves Ryan's concern, since that
seems the simplest to me.  However as an alternative compromise idea the
"resource identity" could be hashed out further.

/Simon

---

From: William Mills <[email-masked]>
Date: Wed, 19 Sep 2012 15:29:52 -0700 (PDT)

The resource identity field being a renaming of the current "user" field?

>Sent: Wednesday, September 19, 2012 3:26 PM

---

From: Ryan Troll <[email-masked]>
Date: Wed, 19 Sep 2012 15:33:08 -0700

I'm sorry, you've lost me.

The two routing decisions being made are:

Problem #1 -- have the router's SASL implementation use what information's
available to route the authentication
Problem #2 -- have the router route all subsequent requests appropriately

Our current approach uses the routing decision for Problem #1 as the answer
to Problem #2, so I'm not quite sure how this rephrasing helps alleviate
the issue at hand.

-R

---

From: Ryan Troll <[email-masked]>
Date: Wed, 19 Sep 2012 15:35:27 -0700

Hm - let me see if I can articulate that better.

Within the SASL implementation, without cracking open the OAuth credential,
how would you propose identifying the authz_id?

-R

On Wed, Sep 19, 2012 at 3:33 PM, Ryan Troll <[email-masked]> wrote:

> Our current approach uses the routing decision for Problem #1 as the
> answer to Problem #2, so I'm not quite sure how this rephrasing helps
> alleviate the issue at hand.
>
> -R
>
>
>
>
>

---

From: William Mills <[email-masked]>
Date: Wed, 19 Sep 2012 15:39:55 -0700 (PDT)

I've hit this wall before...  authz-id will be wrong here.  I think the question you need to ask is, "Without using the credential in any way how can I get a hint of what resource is being accessed?".

>To: Ryan Troll <[email-masked]> 
>Sent: Wednesday, September 19, 2012 3:35 PM
>Within the SASL implementation, without cracking open the OAuth credential, how would you propose identifying the authz_id?
>
>
>-R
>
>
>>Problem #1 -- have the router's SASL implementation use what information's available to route the authentication
>>Our current approach uses the routing decision for Problem #1 as the answer to Problem #2, so I'm not quite sure how this rephrasing helps alleviate the issue at hand.
>>
>>-R
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Sep 2012 20:18:50 -0300

In some ways trying to fit OAuth 1 is twisting the semantics.

Looking at it from a OAuth 2 bearer perspective. 

The email/xmpp address is the authentication identifier in the context of the RS API .

The bearer token is just a long password in most respects.

Sending the email/resource identifier for the user as the authcid and the token as another parameter may have the benefit of simplicity for OAuth 2.

Trying to map the abstract concept of the user identity at the authorization server in just adds complexity.

John B.

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 18:19:14 -0500

> available to route the authentication

If the router can terminate the SASL exchange then there's nothing
else to debate here: just use the authz-id, if one was provided, or
map the authcid to a resource name otherwise.

I was positing that perhaps you didn't want to terminate the SASL
exchange at the router, that you wanted to have the resource server
also be the terminator for the SASL exchange.  In *that* case I'd
propose that you have two routing problems, but since that appears not
to be the case let's just forget it.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 18:22:07 -0500

> straightforward to me.  Presumably, the OAuth mechanism will require

Adding a field is.  Making it so SASL implementations know to output
it is another.

As long as anything new of this sort is done like GSS naming
extensions then it can work backwards-compatibly.  What I would object
to is anything that would require adding variants of
sasl_server_step() and similar functions in Cyrus SASL.

---

From: William Mills <[email-masked]>
Date: Wed, 19 Sep 2012 16:29:58 -0700 (PDT)

OAuth 1 vs. 2 in the current discussion is irrelevant, we have the same functionality requesth in either case.  

> From: John Bradley <[email-masked]>
>Sent: Wednesday, September 19, 2012 4:18 PM

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 20 Sep 2012 00:31:47 +0000

On 9/19/12 6:35 PM, "Ryan Troll" <[email-masked]> wrote:
>Within the SASL implementation, without cracking open the OAuth
>credential, how would you propose identifying the authz_id?

I probably wouldn't, because I don't think it's appropriate to expect the
SASL outer layer (that knows nothing about the mechanism) to go digging
into the mechanism bits to find out where to pass along those bits for
processing. It's a layer violation.

>From the outside, it seems better to me to take a field with fairly out of
band semantics already (the authzid) and simply profile it for this
purpose than to break that layering.

-- Scott

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Sep 2012 21:47:33 -0300

The difference is that because we are starting with OAuth 1 the  oauth_token is being treated as if it is the Authentication identifier.   

Token    A unique identifier issued by the server and used by the client
         to associate authenticated requests with the resource owner
         whose authorization is requested or has been obtained by the
         client.  Tokens have a matching shared-secret that is used by
         the client to establish its ownership of the token, and its
         authority to represent the resource owner.

It is the client and not the RS that uses the unique identifier to associate it's requests with the delegated authority. 

The token may not identify the resource owner or carry any specific information about the resource. 

It is proof that the possessor of the token and the token secret have a grant to access some set of resources.

While there may be an inferred identity of the resource owner (granter of permission) attached to the token in some cases, I would not always assume that semantic.

To be safe the resource should be fully specified and the oauth_token used as a verifier of the grant.

I think you retrying to hard to make the oauth_token/access_token fit the definition of authcid.

John B.

---

From: William Mills <[email-masked]>
Date: Wed, 19 Sep 2012 18:23:56 -0700 (PDT)

You are mistaken.  The draft asserts that the token must carry or allow the server to derive an appropriate identity to be used as authcid.

>Cc: Simon Josefsson <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Wednesday, September 19, 2012 5:47 PM
>Token    A unique identifier issued by the server and used by the client to associate authenticated requests with the resource owner whose authorization is requested or has been obtained by the client.  Tokens have a matching shared-secret that is used by the client to establish its ownership of the token, and its authority to represent the resource owner. 
>
>
>>>> Let's see if we can take a
 step back and (re-)analyze another variant.
>>>> I think I would prefer
 this, if the other alternative is to always

---

From: John Bradley <[email-masked]>
Date: Wed, 19 Sep 2012 22:47:46 -0300

That is a requirement you are adding and not something in OAuth.

It may be easier to send an explicit authcid and use the access_token as intended to convey the authorization and not the identity.

It will probably require less retooling of the OAuth Authorization server.  

It is effectively what Google is doing with XAUTH2.

I am not a SASL expert in any way, just observing you seem to be fighting tying to fit the OAuth semantics into a box they might not precisely fit.

John B.

---

From: William Mills <[email-masked]>
Date: Wed, 19 Sep 2012 21:40:19 -0700 (PDT)

Now see, I think it's you that's trying to add something to OAuth in a different way that isn't there.  OAuth, especially with the password grant has *no* guaranteed concept of a resource identifier.  In the initial stages there might be a signed request, a client ID, or a registered callback, but that's not guaranteed.

Yes, I'm requiring that OAuth implementations that wish to support SASL will need the additional feature of being able to provide an authcid.  I did not think that was unreasonable.

>Sent: Wednesday, September 19, 2012 6:47 PM

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Sep 2012 23:55:36 -0500

On Wed, Sep 19, 2012 at 11:40 PM, William Mills <[email-masked]> wrote:
> Now see, I think it's you that's trying to add something to OAuth in a
> different way that isn't there.  OAuth, especially with the password grant
> has *no* guaranteed concept of a resource identifier.  In the initial stages
> there might be a signed request, a client ID, or a registered callback, but
> that's not guaranteed.
>
> Yes, I'm requiring that OAuth implementations that wish to support SASL will
> need the additional feature of being able to provide an authcid.  I did not
> think that was unreasonable.

Well, an authcid has to be authenticated, unlike the authz-id which
need only be integrity protected.  A mechanism that only authenticates
an assertion of authorization (e.g., a list of group memberships, a
list of labels, a list of resource IDs and access types, etcetera) but
not an authcid cannot really authenticate an authcid because doing
so... probably defeats the point (privacy protection for the authcid)
of that mechanism.

Now, an OAuth 2.0 token for accessing a mailbox surely identifies the
mailbox or set of mailboxes that may be accessed, but for some
resource types the set of resources (perhaps even mailboxes) to which
the presenter is authorized may not be computable, and for IMAP any
set with more than one member may not be trivial to provide a unified
view of.

Q: What to do in this case?  My answer: Require an authz-id to name
the desired resource, OR make the application protocol carry the
resource names separately (e.g., like HTTP does).

Nico
--

---

From: John Bradley <[email-masked]>
Date: Thu, 20 Sep 2012 09:33:21 -0300

I think a large number of email providers have a simple one mailbox per username mapping.

As I have tried to say several times, the Authorization step of OAuth doesn't communicate what the protected resource is 
unless you do something strange like make a scope that is the email address the Authorization server can't know 
what the protected resource is unless there is only one resource of that type for that resource owner.

If the WG want to design a mechanism that is limited to a single resource of the given type(IMAP, XMPP etc) per resource owner
then other than the routing issue you are fine.

If you allow multiple resources of a given type per resource owner, I agree with Nico that you need to specify the resource name.

Authz-id was originally about identity assumption in XMPP as I understand it.    Not who is authenticating but what account they want to control.
I don't know if that is still the understanding.

In some ways that fits, though I would much rather always have the client send it rather than having to depend on the client knowing if the resource owner has multiple resources of the same type.

In a IMAP situation I may permission my secretary to act on my behalf.   That person may be able to generate a access token that can access multiple IMAP boxes, and the target resource may not be identified by the access token given it may permission the client for a number of resources.

John B.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Sep 2012 15:31:40 +0200

> Adding a field is.  Making it so SASL implementations know to output

I still don't follow...  the OAuth SASL mechanism will need the client
to be able to input (for example) an OAuth bearer token.  That is a new
field that SASL implementations needs to start understand.  Why would
adding another OAuth-specific field like a "resource identity" be more
complicated?  Almost all SASL mechanism introduce new fields that SASL
libraries needs to deal with (DIGEST-MD5 introduced qop, realm, etc).

> sasl_server_step() and similar functions in Cyrus SASL.

What I'm talking about is that the "resource identity" is a new
sasl_setprop property.

/Simon

---

From: William Mills <[email-masked]>
Date: Thu, 20 Sep 2012 07:47:59 -0700 (PDT)

I don't think anything need be done.  The credential provides either an authcid or a way for the server to get it.  If the authz-id is provided, or an equivalent is carried in the app protocol, the app uses the authcid available from the SASL authentication to determine if access is allowed.  If no other identity is provided the app uses the authcid, which is authenticated and provided by the mechanism.

>Cc: John Bradley <[email-masked]>; "[email-masked]" <[email-masked]>; Simon Josefsson <[email-masked]> 
>Sent: Wednesday, September 19, 2012 9:55 PM

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Sep 2012 10:51:59 -0500

> What I'm talking about is that the "resource identity" is a new

As long as the server can cope with not finding that property (or can
derive it from other elements) then that's OK.  If the server insists
on that property then the server will only work with the OAuth
mechanism.

What I'm trying to do here is avoid requirements that make it
impossible to build generic SASL applications.  (Generic in the sense
of supporting multiple/arbitrary mechanisms.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Sep 2012 10:55:12 -0500

On Thu, Sep 20, 2012 at 9:47 AM, William Mills <[email-masked]> wrote:
> I don't think anything need be done.  The credential provides either an
> authcid or a way for the server to get it.  If the authz-id is provided, or
> an equivalent is carried in the app protocol, the app uses the authcid
> available from the SASL authentication to determine if access is allowed.
> If no other identity is provided the app uses the authcid, which is
> authenticated and provided by the mechanism.

I'll let the OAuth experts (you, John, Ryan) deal with the authcid.

If OAuth 2.0 does not provide an authcid (or not reliably) and you
need either an authz-id or an authcid then you must either require
that clients provide an authz-id (which, really, is not a big deal,
just annoying, and for an IMAP client possible not even annoying) or
add an authcid.  I don't care which you choose.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Sep 2012 21:18:20 +0200

> on that property then the server will only work with the OAuth

The property would be set on the client side, and transferred in the
mechanism from the client to the server.  It would then be available for
the server, as another property.

> of supporting multiple/arbitrary mechanisms.)

How would you get there?  A SCRAM client will always require a username
and password (or hashed password).  A GSSAPI (i.e., krb5) client will
require a Kerberos ticket.  An OAuth client will need for example an
OAuth bearer token.  An OpenID client will need the OpenID URL from the
user, and access to a browser.  A SAML20 client will need a SAML IdP
identifier and access to a browser.  A SAML20EC client will need a SAML
stack.  And so on.  This needs to come from the something outside of the
mechanism, and the details of what is required will always be mechanism
specific.  You can shield the details from the application if your SASL
library can supply the details, but I see no reason why the SASL library
couldn't supply a resource identity the same way it would supply a SCRAM
username or OpenID URL.

I suspect I just don't follow you here...

/Simon

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Sep 2012 14:27:34 -0500

> the server, as another property.

I'm talking about the server side.  A server that demands this be
available will only work with this one mechanism.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Sep 2012 21:33:03 +0200

> available will only work with this one mechanism.

The OAuth SASL spec would require the field to always be sent by the
client, as other mechanism specific data.  Naturally the server will
require that the client sends things conforming to the protocol.  Is
your issue that you think the client cannot find out what this field
should be set to?

/Simon

---

From: William Mills <[email-masked]>
Date: Thu, 20 Sep 2012 12:35:22 -0700 (PDT)

That seems a spurious argument to me, because it argues against the way SASL works now.  Servers will absolutely select the auth mechanism(s) they want to support, but you don't have to support them all.  PLAIN has different inputs from a Kerberos based mechanism.

>Sent: Thursday, September 20, 2012 12:27 PM

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Sep 2012 14:41:38 -0500

> your issue that you think the client cannot find out what this field

The server *app*.  If it insists on something that only one mechanism
provides, then that app will only work with that one mechanism.

---

From: William Mills <[email-masked]>
Date: Thu, 20 Sep 2012 12:53:11 -0700 (PDT)

Are you arguing that the OAuth SASL mechanism is breaking new ground here and requiring a completely new data element?  I don't think that's true.

>Sent: Thursday, September 20, 2012 12:41 PM

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 20 Sep 2012 22:54:38 +0200

> provides, then that app will only work with that one mechanism.

Ah.  Now I think I understand what you are getting at.  I never intended
to propose that the server application should do anything with the
resource identity.  The server application would normally never care
about it.  It is an OAuth SASL mechanism internal field.  The fields'
only purpose is to allow deployments like Ryan's to be able to route the
connection right without having to parse other fields.  Once the
connection has been routed right, the server mechanism implementation
will verify that the resource identity is the same as the authzid if
given by the client, or the (now derived) authcid if authzid is absent.
If there is a mismatch, the mechanism must fail authentication.

If you now react that the field is strictly speaking unnecessary because
you could deploy things in a two routing scenario as you mentioned, yes
I would agree, but I think we can consider accomodating Ryan's request
here if that is the simplest way to move forward and doesn't have any
significant downside.  For deployment that can discover the right place
to route things immediately, the resource identity will just waste space
on the wire and require one unnecessary comparison at the end of the
server code.  That's not a huge disadvantage to me.

/Simon

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Sep 2012 10:41:59 -0500

> connection right without having to parse other fields.  Once the

Because the server *app* is the one doing the routing in that case,
and because it simply *must* do this routing, Ryan's server would
*insist* on this value being present, thus binding itself tightly to
this one mechanism.

But note that this value might as well be the authz-id, which all SASL
mechanisms support.

Therefore it's best if we use the authz-id for this.

Note that with the UI that Ryan has in mind the authz-id is actually
the *perfect* thing to use anyways -- in some place in the UI the name
of the mailbox will be necessary, and that's anyways what authz-id is
used for in IMAP.

> If there is a mismatch, the mechanism must fail authentication.

The authorization mechanism will be based on OAuth here, but that's a
detail we don't care about right now.  What we do care about is having
the resource (mailbox) identified so that we may then use OAuth to
perform authorization.

The way to identify that resource is exceedingly clear to me now: it's
the authz-id.

> I would agree, but I think we can consider accomodating Ryan's request

Ryan has indicated that terminating the SASL exchange at the router is
not a problem.  So there's no need to look at this as a
two-routing-problem problem.

Just use the authz-id.

> server code.  That's not a huge disadvantage to me.

I'm not sure which request of Ryan's you're talking about.

There could be protocols where the authz-id does not identify a
resource, but that's OK: something else in those protocols will, and
then authorization can proceed as expected.

I believe it's now been established beyond doubt (certainly mine) that
the authz-id *is* the one and only protocol element that Ryan needs
here to identify the IMAP mailbox that the client is trying to access.

Nico
--

---

From: John Bradley <[email-masked]>
Date: Fri, 21 Sep 2012 13:23:09 -0300

Agreed.

For Imap and XMPP authz looks like email address and that fits.
For other protocols (perhaps calendaring or something) the authzid may be different but that should not be a problem.

I think the authzid should always be sent to avoid interoperability issues.

John B.

---

From: William Mills <[email-masked]>
Date: Fri, 21 Sep 2012 09:35:11 -0700 (PDT)

So do we have consensus?  (I think so)

The only edit I have now for -09 would be specifying that unknown fields are ignored, which is almost a grace note, but easily done.

Can w now proceed to WGLC?

Thanks,

-bill

>Sent: Friday, September 21, 2012 9:23 AM

---

From: Ryan Troll <[email-masked]>
Date: Fri, 21 Sep 2012 11:01:39 -0700

I've been reading this thread, and following most of it.  It's been
especially interesting to see the discussion about what's done [within
SASL] vs in an app that uses SASL.  Excellent points by all.

It's also great to see that we've arrived at consensus on the authzid being
required.  I believe this makes a lot of sense when using OAuth, and fully
support it.

Thank you all for taking the time to work through this.  The overall
attitude of the discussion - "Let's figure out how to solve Ryan's problem"
- was fantastic.  This is what makes standards bodies work.  And if a final
proposal was made that didn't enable me to solve my problem, it certainly
wouldn't have been for lack of honest discussion and trying.

-R

On Fri, Sep 21, 2012 at 9:23 AM, John Bradley <[email-masked]> wrote:

> For other protocols (perhaps calendaring or something) the authzid may be
> different but that should not be a problem.
>

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 22 Sep 2012 09:48:11 +0200

> Therefore it's best if we use the authz-id for this.

This is okay by me -- the problem I see with this is that 1) some
non-standard documentation is needed on how to setup clients, and 2) if
the OAuth mechanism ends up being used through the GSS-API no
authorization identity may be available.  I think we can live with these
issues.  The second I believe we can solve with naming attributes if it
becomes important to solve it.

/Simon