Subject: [OAUTH-WG] Next steps (draft timeline)

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 29 Sep 2010 09:20:21 -0700

(This is a draft overview of our next steps. Clearly, this can change based on working group consensus.)

Proposal discussion

The working group is still discussing the compromise proposal for moving section 5 out of the specification. So far there is general support but some have raised concerns (I have not seen any strong objections yet). I am going to ask the chairs for an official consensus call on this on Friday. I will not publish another draft until we close this matter properly. While a consensus call does not end debate, it provides a useful tool to move forward and reduce the likelihood of future arguments.

Editorial work

I have been working on -11 and have applied all the feedback received so far. I am still working on the compromise structure of reintroducing the separate profiles into the document, but that is purely an editorial change. As soon as we resolve the issue around the document structure, I will finish the work and publish it. All the normative language changes are already "published" on my github account [1].

If the proposal is approved, I plan to remove my name from the bearer token specification and hand over that section to someone else. Selecting an editor is the sole discretion of the chairs, but if you are interested in taking over that document (which will include all of section 5 of the current draft, with a new introduction), please let the chairs know soon. I will get you off to a good start by providing the first draft with all the necessary parts ready for editing. I will also help as much as needed (my dislike for this document will not prevent me for offering as much support as requested).

Signature work

Mike and Dirk have been making good progress with their proposals, and I hope that we will soon have a single unified draft to work on. Once that is ready, the working group will need to decide if it wants to promote the proposal to a working group item, and if adopted, the chairs will need to pick an editor for that work (not me).

Assuming the signature proposal is going to keep its duplication of HTTP request elements, I plan to introduce an alternative proposal based on the OAuth 1.0a HMAC-SHA-1 method, my earlier token scheme proposal, and the recent proposal from draft -05. I do not plan to ask for this draft to become a working group item (I do plan to use this list for discussions though), but will have no objections if others ask. I have absolutely no desire to engage in any more working group debate around which of the two approaches is better. I will promote my ideas elsewhere and will let the market decide.

Additional documents

We have a few proposed I-D dealing with artifact binding, SAML assertions, token revocation, and others. These seems to be in good enough state to consider making them a working group item (a process started by the chairs but which seems stuck). I suggest that the authors make an official request to the chairs and get it done. My proposal is that any document that is ready for last call alongside the main working group specifications will be directly referenced in them.

Timeline

If the proposal is approved, I believe we can move to working group last call by the end of the year. To get there, we will need to complete at least two more round of review (i.e. get to a -13). I am not expecting any new normative changes (but don't have any control over it either). This will require the completion and integration of the security consideration section in -12.

This means:

-11 - last round of normative changes, document split, reintroducing profiles (mid October)
-12 - security consideration section (early November)
-13 - last call document (early December)

To get the bearer token document ready for last call, someone will need to take over as editor as well as get the security consideration section done for that part. The two documents do not need to enter last call together, but it will probably be a useful thing to do. I do not see any other last call dependencies (such as a signature draft).

If we remain focused and move forward with the proposed compromise, we should be able to meet this timeline. Otherwise, I have seen nothing to suggest reaching last call for any document this year (but am always open to new proposals that have not been rejected or strongly opposed before).

Open Issues

With the pending publication of draft -11 I would like to ask everyone to treat it as a working group last call and raise any objections or issues they have. If anything in the document will cause you to raise objections to its publication, please share those as soon as possible. I hope to have a quick and quite review for -13, followed quickly by a working group last call.

Keep in mind that missing the these goals will mean February as the next likely timeline, given the historical lack of activity in December and January.

EHL

[1] http://github.com/theRazorBlade/draft-ietf-oauth

---

From: PRATEEK MISHRA <[email-masked]>
Date: Wed, 29 Sep 2010 19:33:18 -0400

I read through v10 from the perspective of an implementor, and it seemed 
to me that properties of generated authorization code and its treatment 
by various entities need to be called out explicitly as a 
counter-measure against various simple attacks.

I would also comment that the exchanges between the end-user, client and 
authorization endpoints, beginning with the issuance of an authorization 
code (in SAML 2.0 called a browser artifact) and terminating with the 
client obtaining an access token (in SAML 2.0 the RP obtaining a SAML 
assertion) essentially follow the SAML web browser artifact profile and 
are therefore open to all of the attacks that the SSTC considered for 
this protocol.

1) For example, given the current description it seems that perfectly 
reasonable for an end-user authorization endpoint to generate a sequence 
of increasing integers as an authorization code or always return a 
constant value for a request with a given (client_id, redirection_uri) 
pair of inputs. So this leads to the possibility of an adversary using 
some simple techniques to guess valid authorization codes and obtain an 
access token.

2) There is a need to articulate some of the minimum properties that an 
authorization code should possess. I understand that there is an attempt 
here to give maximum choice to implementors.

For example, the SAML 2.0 artifact format description includes the 
following language -

[quote]
The MessageHandle value is constructed from a cryptographically strong 
random or
pseudorandom number sequence [RFC1750] generated by the issuer. The 
sequence consists of
values of at least 16 bytes in size.
[\quote]

3) I am also puzzled by the discrepancy between the language used to 
describe the generation and use of an authorization code -

[quote - generation - p.18]
The authorization code
SHOULD expire shortly after it is issued. The authorization
server MUST invalidate the authorization code after a single
usage. The authorization code is bound to the client
identifier and redirection URI.
[\quote]

VS

[quote - use - p.23]
The authorization server MUST:
o Validate the client credentials (if present) and ensure they match
the authorization code.
o Verify that the authorization code and redirection URI are all
valid and match its stored association.
[\quote]

I dont understand how the authorization code is related to the client 
credentials, or what is meant by "valid" or the reference
to "stored association". Is there an assumption that authorization 
server has a stateful table of (authorization code, client id, 
redirection uri) values?
Shouldnt this test be limited to checking whether the authorization code 
is being used with the correct client identifier and redirection URI?

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 30 Sep 2010 09:15:32 +0200

Thank you for your advice. The Oauth security considerations are not finished yet. They will handle the issues you raised, too. 

Regards,
Torsten.

Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA <[email-masked]>:

> I read through v10 from the perspective of an implementor, and it seemed to me that properties of generated authorization code and its treatment by various entities need to be called out explicitly as a counter-measure against various simple attacks.
> 
> I would also comment that the exchanges between the end-user, client and authorization endpoints, beginning with the issuance of an authorization code (in SAML 2.0 called a browser artifact) and terminating with the client obtaining an access token (in SAML 2.0 the RP obtaining a SAML assertion) essentially follow the SAML web browser artifact profile and are therefore open to all of the attacks that the SSTC considered for this protocol.
> 
> 1) For example, given the current description it seems that perfectly reasonable for an end-user authorization endpoint to generate a sequence of increasing integers as an authorization code or always return a constant value for a request with a given (client_id, redirection_uri) pair of inputs. So this leads to the possibility of an adversary using some simple techniques to guess valid authorization codes and obtain an access token.
> 
> 2) There is a need to articulate some of the minimum properties that an authorization code should possess. I understand that there is an attempt here to give maximum choice to implementors.
> 
> For example, the SAML 2.0 artifact format description includes the following language -
> 
> [quote]
> The MessageHandle value is constructed from a cryptographically strong random or
> pseudorandom number sequence [RFC1750] generated by the issuer. The sequence consists of
> 3) I am also puzzled by the discrepancy between the language used to describe the generation and use of an authorization code -
> 
> I dont understand how the authorization code is related to the client credentials, or what is meant by "valid" or the reference
> to "stored association". Is there an assumption that authorization server has a stateful table of (authorization code, client id, redirection uri) values?
> Shouldnt this test be limited to checking whether the authorization code is being used with the correct client identifier and redirection URI?
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 30 Sep 2010 17:37:18 +0200

Bassically, your suggestion sounds reasonable to me.

The only thing I'm missing is discovery. As you pointed out in 
http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/ 
this is a major enabler for interoperable APIs and motivates the need 
for signatures. Shouldn't we consider discovery, too?

regards,
Torsten.

Am 29.09.2010 18:20, schrieb Eran Hammer-Lahav:
> The working group is still discussing the compromise proposal for 
> moving section 5 out of the specification. So far there is general 
> support but some have raised concerns (I have not seen any strong 
> objections yet). I am going to ask the chairs for an official 
> consensus call on this on Friday. I will not publish another draft 
> until we close this matter properly. While a consensus call does not 
> end debate, it provides a useful tool to move forward and reduce the 
> likelihood of future arguments.
>
> Editorial work
>
> I have been working on -11 and have applied all the feedback received 
> so far. I am still working on the compromise structure of 
> reintroducing the separate profiles into the document, but that is 
> purely an editorial change. As soon as we resolve the issue around the 
> document structure, I will finish the work and publish it. All the 
> normative language changes are already "published" on my github 
> account [1].
>
> If the proposal is approved, I plan to remove my name from the bearer 
> token specification and hand over that section to someone else. 
> Selecting an editor is the sole discretion of the chairs, but if you 
> are interested in taking over that document (which will include all of 
> section 5 of the current draft, with a new introduction), please let 
> the chairs know soon. I will get you off to a good start by providing 
> the first draft with all the necessary parts ready for editing. I will 
> also help as much as needed (my dislike for this document will not 
> prevent me for offering as much support as requested).
>
> Signature work
>
> Mike and Dirk have been making good progress with their proposals, and 
> I hope that we will soon have a single unified draft to work on. Once 
> that is ready, the working group will need to decide if it wants to 
> promote the proposal to a working group item, and if adopted, the 
> chairs will need to pick an editor for that work (not me).
>
> Assuming the signature proposal is going to keep its duplication of 
> HTTP request elements, I plan to introduce an alternative proposal 
> based on the OAuth 1.0a HMAC-SHA-1 method, my earlier token scheme 
> proposal, and the recent proposal from draft -05. I do not plan to ask 
> for this draft to become a working group item (I do plan to use this 
> list for discussions though), but will have no objections if others 
> ask. I have absolutely no desire to engage in any more working group 
> debate around which of the two approaches is better. I will promote my 
> ideas elsewhere and will let the market decide.
>
> Additional documents
>
> We have a few proposed I-D dealing with artifact binding, SAML 
> assertions, token revocation, and others. These seems to be in good 
> enough state to consider making them a working group item (a process 
> started by the chairs but which seems stuck). I suggest that the 
> authors make an official request to the chairs and get it done. My 
> proposal is that any document that is ready for last call alongside 
> the main working group specifications will be directly referenced in them.
>
> Timeline
>
> If the proposal is approved, I believe we can move to working group 
> last call by the end of the year. To get there, we will need to 
> complete at least two more round of review (i.e. get to a -13). I am 
> not expecting any new normative changes (but don't have any control 
> over it either). This will require the completion and integration of 
> the security consideration section in -12.
>
> This means:
>
> -11 -- last round of normative changes, document split, reintroducing 
> profiles (mid October)
>
> -12 -- security consideration section (early November)
>
> -13 -- last call document (early December)
>
> To get the bearer token document ready for last call, someone will 
> need to take over as editor as well as get the security consideration 
> section done for that part. The two documents do not need to enter 
> last call together, but it will probably be a useful thing to do. I do 
> not see any other last call dependencies (such as a signature draft).
>
> If we remain focused and move forward with the proposed compromise, we 
> should be able to meet this timeline. Otherwise, I have seen nothing 
> to suggest reaching last call for any document this year (but am 
> always open to new proposals that have not been rejected or strongly 
> opposed before).
>
> Open Issues
>
> With the pending publication of draft -11 I would like to ask everyone 
> to treat it as a working group last call and raise any objections or 
> issues they have. If anything in the document will cause you to raise 
> objections to its publication, please share those as soon as possible. 
> I hope to have a quick and quite review for -13, followed quickly by a 
> working group last call.
>
> Keep in mind that missing the these goals will mean February as the 
> next likely timeline, given the historical lack of activity in 
> December and January.
>
> EHL
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 30 Sep 2010 08:56:10 -0700

The chairs sent a longer list of new items to consider. This does not replace that list but only focuses on the immediate next steps.

EHL

On Sep 30, 2010, at 8:38, "Torsten Lodderstedt" <[email-masked]<mailto:[email-masked]>> wrote:

The only thing I'm missing is discovery. As you pointed out in <http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/> http://hueniverse.com/2010/09/oauth-2-0-without-signatures-is-bad-for-the-web/ this is a major enabler for interoperable APIs and motivates the need for signatures. Shouldn't we consider discovery, too?

regards,
Torsten.

Proposal discussion

Editorial work

I have been working on -11 and have applied all the feedback received so far. I am still working on the compromise structure of reintroducing the separate profiles into the document, but that is purely an editorial change. As soon as we resolve the issue around the document structure, I will finish the work and publish it. All the normative language changes are already “published” on my github account [1].

Signature work

Additional documents

Timeline

If the proposal is approved, I believe we can move to working group last call by the end of the year. To get there, we will need to complete at least two more round of review (i.e. get to a -13). I am not expecting any new normative changes (but don’t have any control over it either). This will require the completion and integration of the security consideration section in -12.

This means:

-11 – last round of normative changes, document split, reintroducing profiles (mid October)
-12 – security consideration section (early November)
-13 – last call document (early December)

Open Issues

EHL

[1] <http://github.com/theRazorBlade/draft-ietf-oauth> http://github.com/theRazorBlade/draft-ietf-oauth

_______________________________________________
OAuth mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth