Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter

From: Breno <[email-masked]>
Date: Tue, 1 Dec 2009 15:52:17 -0800

Eran,

The HMAC approach also requires key management. The fact that the community
has punted on it to an out-of-band channel doesn't mean that the problem has
been addressed.

Typical security recommendations for shared keys is that they should be
rotated more often than public keys. It would be quite reasonable, from a
security perspective, for a provider to want to be specify that HMAC signing
keys should be rotated weekly. For instance, the US Government profile for
OpenID requires daily rotation of HMAC signing values.

What then?

The spec should support key management, with or without PK signing
mechanisms.

On Mon, Nov 30, 2009 at 11:32 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> The issue with RSA-SHA1-like method isn't the signature or crypto. Those
> are trivial to spec out. The issue is everything else we didn't cover in 1.0
> including key management and rotation, and how to establish it.
>
> We had rough consensus about dropping the client credentials (consumer key)
> from protected resources requests. This means you may use client credentials
> to request a token, but once you have the token, you don't need to use the
> client credentials anymore. The implications of this are that any PK-based
> method will need to work at the token level, not the client level.
>
> With this approach, it will be easy to include a PK method alongside an
> HMAC method, but it is not clear how the secret portion of the token pair
> will be obtained and managed. My limited understanding suggests that issuing
> a token-secret pair isn't the same as a token-Private Key pair. Maybe I'm
> wrong and it can be made as trivial.
>
> And no, there will be nothing to prevent such an extension.
>
> EHL
>
> > -----Original Message-----
> > From: Hans Granqvist [mailto:[email-masked]]
> > Sent: Monday, November 30, 2009 9:31 AM
> > To: OAuth WG ([email-masked])
> > Cc: Eran Hammer-Lahav; Pelle Braendgaard
> > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter
> >
> > It's tricky. If you allow only MACs, you have to forgo no only RSA (and
> ECC...)
> > but also potentially traditional symmetric key schemes -- their usability
> > notwithstanding.
> >
> > On the other hand, if you try to cover all possible key schemes, it
> quickly
> > becomes unmanageable.
> >
> > Eran, is there a way to define what you want and leave it open for, say
> an
> > RSA extension, as long as it can be represented as a string, such as
> > {ALGORITHM}:{STRING}, and where any extra protocol flows are out of this
> > specification's scope?
> >
> > -Hans
> >
> >
> > On Mon, Nov 30, 2009 at 7:53 AM, Pelle Braendgaard
> > <[email-masked]> wrote:
> > > +1 for all minus dropping RSA.
> > >
> > > I think the main reason we haven't seen a lot of RSA implementations
> > > yet has been because the kind of businesses who I think would be
> > > interested in using this such as banks/payments etc are not
> > > traditionally early adopters. If we want to see OAUTH used in these
> > > areas in the future I think it would be a very good idea to leave it
> > > in.
> > >
> > > I am personally working on creating new OAuth based financial
> > > transaction standard called OpenTransact, where we are planning on
> > > standardizing on RSA in the next revision.
> > >
> > > Regards
> > > Pelle
> > >
> > >
> > > On Mon, Nov 30, 2009 at 2:34 AM, Eran Hammer-Lahav
> > <[email-masked]> wrote:
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Paul C. Bryan [mailto:[email-masked]]
> > >>> Sent: Sunday, November 29, 2009 3:08 PM
> > >>> To: Eran Hammer-Lahav
> > >>> Cc: Peter Saint-Andre ([email-masked]); Lisa Dusseault
> > >>> ([email-masked]); OAuth WG ([email-masked])
> > >>> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter
> > >>>
> > >>> To the overall approach, +1.
> > >>>
> > >>> Some follow-up questions:
> > >>>
> > >>> 1. Why drop RSA? It seems some form of public key cryptography will
> > >>> be necessary/useful to make web-based-attribute-containing tokens
> > >>> Internet- scalable.
> > >>
> > >> Mostly due to lack of implementation experience or interest within the
> > OAuth community. But also because the Plain and MAC versions are based
> > on a simple symmetric shared secret, while PK requires more. This means
> we
> > will need to support different types of tokens. While I am open to this
> if
> > needed, it seems to add a significant complexity. Also, part 2 will then
> need
> > to be able to provision both symmetric and asymmetric secrets which adds
> to
> > the complexity there.
> > >>
> > >> In other words, why put the effort in if no one is asking for this
> (based on
> > 2 years of deployment experience).
> > >>
> > >>> 2. Is it an objective to have the Token auth-scheme contain
> > >>> extension points so that new token formats can be introduced without
> > >>> need to redefine the scheme or draft a new one?
> > >>
> > >> Yes, but see above.
> > >>
> > >> EHL
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> [email-masked]
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >>
> > >
> > >
> > >
> > > --
> > > http://agree2.com - Reach Agreement!
> > > http://extraeagle.com - Solutions for the electronic Extra Legal world
> > > http://stakeventures.com - Bootstrapping blog
> > > _______________________________________________
> > > OAuth mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 1 Dec 2009 17:55:08 -0700

There is an important difference in how 1.0 deals with the two.

HMAC secrets are token specific and expire when the token does. With the session extension you get free HMAC "key" management, but either way, you can scope the secret to a limited time via the token. Since the secret comes with the token, it is obtained the same way which is well defined.

RSA keys are negotiated out of band and are the same for all tokens used by a single client. There is nothing in the spec on how they should be obtained or cycled.

If we add an RSA option to the authentication part, it will mean we will have to start issuing private keys with each token. If people are happy with this idea (I have no clue), this can be done in the same way as the HMAC secret. I am just not sure if it is a proper way of distributing keys. Another option would be for the client to provide the server with its public key when asking for a token (and then a new public key when renewing a token).

QUESTION: Are people interested in seeing such an RSA method in the authentication spec? Since the new authentication spec exclude the use of client credentials (only token with optional secret), any key used for RSA signatures will need to be part of the token.

EHL

From: Breno [mailto:[email-masked]]
Sent: Tuesday, December 01, 2009 3:52 PM
To: Eran Hammer-Lahav
Cc: Hans Granqvist; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter

Eran,

The HMAC approach also requires key management. The fact that the community has punted on it to an out-of-band channel doesn't mean that the problem has been addressed.

Typical security recommendations for shared keys is that they should be rotated more often than public keys. It would be quite reasonable, from a security perspective, for a provider to want to be specify that HMAC signing keys should be rotated weekly. For instance, the US Government profile for OpenID requires daily rotation of HMAC signing values.

What then?

The spec should support key management, with or without PK signing mechanisms.

On Mon, Nov 30, 2009 at 11:32 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
The issue with RSA-SHA1-like method isn't the signature or crypto. Those are trivial to spec out. The issue is everything else we didn't cover in 1.0 including key management and rotation, and how to establish it.

We had rough consensus about dropping the client credentials (consumer key) from protected resources requests. This means you may use client credentials to request a token, but once you have the token, you don't need to use the client credentials anymore. The implications of this are that any PK-based method will need to work at the token level, not the client level.

With this approach, it will be easy to include a PK method alongside an HMAC method, but it is not clear how the secret portion of the token pair will be obtained and managed. My limited understanding suggests that issuing a token-secret pair isn't the same as a token-Private Key pair. Maybe I'm wrong and it can be made as trivial.

EHL

> From: Hans Granqvist [mailto:[email-masked]<mailto:[email-masked]>]
> To: OAuth WG ([email-masked]<mailto:[email-masked]>)
> It's tricky. If you allow only MACs, you have to forgo no only RSA (and ECC...)
> On the other hand, if you try to cover all possible key schemes, it quickly
> becomes unmanageable.
>
> Eran, is there a way to define what you want and leave it open for, say an
> <[email-masked]<mailto:[email-masked]>> wrote:
> <[email-masked]<mailto:[email-masked]>> wrote:
> >>
> >>
> >>> From: Paul C. Bryan [mailto:[email-masked]<mailto:[email-masked]>]
> >>> Cc: Peter Saint-Andre ([email-masked]<mailto:[email-masked]>); Lisa Dusseault
> >>> ([email-masked]<mailto:[email-masked]>); OAuth WG ([email-masked]<mailto:[email-masked]>)
> on a simple symmetric shared secret, while PK requires more. This means we
> will need to support different types of tokens. While I am open to this if
> needed, it seems to add a significant complexity. Also, part 2 will then need
> to be able to provision both symmetric and asymmetric secrets which adds to
> the complexity there.
> >>
> >> In other words, why put the effort in if no one is asking for this (based on
> >> [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
Breno de Medeiros

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 01 Dec 2009 20:35:56 -0500

Eran Hammer-Lahav wrote:
...
>
>  
>
> RSA keys are negotiated out of band and are the same for all tokens 
> used by a single client. There is nothing in the spec on how they 
> should be obtained or cycled.
>

This is right, but this is because a public key is NOT subject to 
negotiation. It is confirmed by a certificate.
>
>  
>
> If we add an RSA option to the authentication part, it will mean we 
> will have to start issuing private keys with each token. If people are 
> happy with this idea (I have no clue), this can be done in the same 
> way as the HMAC secret. I am just not sure if it is a proper way of 
> distributing keys. Another option would be for the client to provide 
> the server with its public key when asking for a token (and then a new 
> public key when renewing a token).
>

 I would never be happy with THIS idea. For one thing, if  a private key 
is escrowed it may NOT be used in signatures. This is why, to begin 
with, I assumed that some sort of PKI ought to be in place.
>
>  
>
> ..., any key used for RSA signatures will need to be part of the token.
>

It is likely that I misunderstood this statement. But if I take it 
literally, the answer is no. The key should not be (and cannot be) part 
of the token. The private key is useless for HMAC because it is not 
available to anyone and thus no one can verify the signature. Perhaps 
you meant that the certificate (or a certificate chain) needs to be 
present? This, actually, may very well be a possibility.

Igor

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 1 Dec 2009 19:42:50 -0700

> From: Igor Faynberg [mailto:[email-masked]]
> Sent: Tuesday, December 01, 2009 5:36 PM

>  I would never be happy with THIS idea. For one thing, if  a private key is
> escrowed it may NOT be used in signatures. This is why, to begin with, I
> assumed that some sort of PKI ought to be in place.

Which is why I added the flip side as an idea.

When the client requests a token, it provides the public key to the server for verifying it is the rightful owner of the token (once issued). The server then issues a token without any secrets and uses the public key provided by the client to authenticate token requests.

What kind of PKI? The current RSA-SHA1 method uses a simple private/public key pair without any dependency on other infrastructure.

> It is likely that I misunderstood this statement. But if I take it literally, the
> answer is no. The key should not be (and cannot be) part of the token. The
> private key is useless for HMAC because it is not available to anyone and thus
> no one can verify the signature. Perhaps you meant that the certificate (or a
> certificate chain) needs to be present? This, actually, may very well be a
> possibility.

It means part of the 'set of token credentials', not part of the token itself. That would never work.
 
EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 15:31:49 -0700

After plenty of healthy discussion with the chair, AD, and working group members, I think the best way to move forward is to focus on the next working group milestone:

* Submit a document as a working group item providing the functionality of the 2-legged HTTP authentication mechanism

Which the charter provides us with complete freedom:

   The Working Group will also define a generally applicable
   HTTP authentication mechanism (i.e., browser-based "2-leg"
   scenario).

Once this is complete we can consider its impact on the OAuth delegation component, and whether we want to replace the existing authentication with this new method. At that point, based on WG consensus, we might want to consider changes to the charter.

In addition, we have enough interest on this list to discuss alternative delegation flows as suggested by WRAP which will be submitted for WG consideration shortly. Discussing the new suggested flows is critical for any discussion on future charter changes (if we don't agree on which flows to include, we can't change the charter).

I plan to submit a new individual submission I-D for the milestone above for WG consideration shortly. Based on WG feedback we can decide to promote it to a WG draft.

I will leave it up to the chair to decide how he wishes to continue based on my suggestions.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Saturday, November 28, 2009 11:59 PM
> To: Peter Saint-Andre ([email-masked]); Lisa Dusseault
> ([email-masked])
> Cc: OAuth WG ([email-masked])
> Subject: [OAUTH-WG] OAuth 2.0 / Charter
> 
> With the cleanup of the 1.0 specification [1] and the publication of an
> informational RFC (pending IESG approval), I no longer see value in a
> standard closely based on the 1.0 specification, which was the original
> intention of this WG. This is also reflected by the recent interest in the WRAP
> proposal [2].
> 
> Instead, I think we should develop two specifications that while closely in line
> with the original plan, represent a significant shift. In other words, I am
> proposing we develop OAuth 2.0, not 1.1.
> 
> The new proposal is to develop two specifications:
> 
> 1. Token Authorization Method
> 
> An RFC 2617 Authorization header called 'Token' for authenticating requests
> with token-based credentials. Tokens (with optional shared-secret) are
> usually used in place of other credentials (usernames, etc.) and represent
> some combination of scope and authorization. The token method will include
> an extensible signature-based option based on the HMAC-SHA1 method,
> and a bearer token (with optional secret) option based on the PLAINTEXT
> method. The RSA option will be dropped.
> 
> 2. OAuth 2.0
> 
> A specification based on the browser-redirection flow described in OAuth 1.0
> as well as new methods defined in WRAP (I-D submission pending). OAuth
> will be redefined to cover the authorization component only, and will no
> longer be bound to a single authentication method. This will make OAuth
> immediately useful for other protocols than HTTP (while HTTP will be used to
> obtain tokens, tokens will be useful in other protocols, not just with the HTTP
> and Token method).
> 
> ---
> 
> While the current charter allows much of this work, it contradicts its spirit and
> the understanding reached when we created the working group.
> 
> I would like to ask:
> 
> - Is this approach favorable by the group?
> - Do we need to adjust the language in the charter to support?
> 
> EHL
> 
> [1] http://tools.ietf.org/html/draft-hammer-oauth
> [2] http://bit.ly/oauth-wrap
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 15:40:37 -0700

<hat type='chair'/>

Eran, your suggestions are most welcome, and consistent with my sense of:

1. discussions on this list

2. the shifting landscape of OAuth technologies (not that landscape
shifts are necessarily a bad thing, because in this case they indicate
greater and IMHO more serious interest)

3. my conversations with people in the IETF and OAuth communities (and I
might reach out directly to more WG participants to gain more input)

Once we have individual I-Ds for authentication (the token draft you're
working on) and alternative delegation flows (from the WRAP work, and
perhaps from other WG participants as well), I agree that we can have a
more fruitful discussion about next steps. I expect that to happen in
the next two weeks.

Peter

On 12/3/09 3:31 PM, Eran Hammer-Lahav wrote:
> After plenty of healthy discussion with the chair, AD, and working
> group members, I think the best way to move forward is to focus on
> the next working group milestone:
> 
> * Submit a document as a working group item providing the
> functionality of the 2-legged HTTP authentication mechanism
> 
> The Working Group will also define a generally applicable HTTP
> authentication mechanism (i.e., browser-based "2-leg" scenario).
> 
> Once this is complete we can consider its impact on the OAuth
> delegation component, and whether we want to replace the existing
> authentication with this new method. At that point, based on WG
> consensus, we might want to consider changes to the charter.
> 
> In addition, we have enough interest on this list to discuss
> alternative delegation flows as suggested by WRAP which will be
> submitted for WG consideration shortly. Discussing the new suggested
> flows is critical for any discussion on future charter changes (if we
> don't agree on which flows to include, we can't change the charter).
> 
> I plan to submit a new individual submission I-D for the milestone
> above for WG consideration shortly. Based on WG feedback we can
> decide to promote it to a WG draft.
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav 
>> Sent: Saturday, November 28, 2009 11:59 PM To: Peter Saint-Andre
>> ([email-masked]); Lisa Dusseault ([email-masked]) Cc:
>> OAuth WG ([email-masked]) Subject: [OAUTH-WG] OAuth 2.0 / Charter
>> 
>> With the cleanup of the 1.0 specification [1] and the publication
>> of an informational RFC (pending IESG approval), I no longer see
>> value in a standard closely based on the 1.0 specification, which
>> was the original intention of this WG. This is also reflected by
>> the recent interest in the WRAP proposal [2].
>> 
>> Instead, I think we should develop two specifications that while
>> closely in line with the original plan, represent a significant
>> shift. In other words, I am proposing we develop OAuth 2.0, not
>> 1.1.
>> 
>> An RFC 2617 Authorization header called 'Token' for authenticating
>> requests with token-based credentials. Tokens (with optional
>> shared-secret) are usually used in place of other credentials
>> (usernames, etc.) and represent some combination of scope and
>> authorization. The token method will include an extensible
>> signature-based option based on the HMAC-SHA1 method, and a bearer
>> token (with optional secret) option based on the PLAINTEXT method.
>> The RSA option will be dropped.
>> 
>> 2. OAuth 2.0
>> 
>> A specification based on the browser-redirection flow described in
>> OAuth 1.0 as well as new methods defined in WRAP (I-D submission
>> pending). OAuth will be redefined to cover the authorization
>> component only, and will no longer be bound to a single
>> authentication method. This will make OAuth immediately useful for
>> other protocols than HTTP (while HTTP will be used to obtain
>> tokens, tokens will be useful in other protocols, not just with the
>> HTTP and Token method).
>> 
>> ---
>> 
>> While the current charter allows much of this work, it contradicts
>> its spirit and the understanding reached when we created the
>> working group.
>> 
>> I would like to ask:
>> 
>> - Is this approach favorable by the group? - Do we need to adjust
>> the language in the charter to support?
>> 
>> EHL
>> 
>> [1] http://tools.ietf.org/html/draft-hammer-oauth [2]
>> http://bit.ly/oauth-wrap
>> 
>> _______________________________________________ OAuth mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 15:48:11 -0700

On 11/30/09 12:57 PM, Dick Hardt wrote:
> On 2009-11-30, at 9:25 AM, Eran Hammer-Lahav wrote:
> 
>> 3. I will leave it up to the security experts to figure out if a PK
>> option in the *authentication* spec is worth having, compared to
>> TLS/SSL. OAuth did not require TLS because it was designed to be
>> friendly to small sites looking to deploy an API without having to
>> deal with certificates. The performance overhead wasn't really the
>> main issue, it was practicality. For example, I would like to be
>> able to write a Wordpress plugin that exposes an address book API
>> using OAuth, without being required to enable SSL on my blog.
> 
> Are there implementations of Wordpress plugins using OAuth? ie., was
> there a real market need for this, or just a perceived need?
> 
> If you don't have SSL on your blog management endpoint, then your
> blog credentials are being transported in the clear. I don't have SSL
> on my Wordpress blogs, and I'm ok with the risk given the tradeoffs.
> It seems like many other people are as well currently.

Not I: https://stpeter.im/
           ^

> While I agree it is desirable to improve security, is there real
> demand for it?

The IESG and Security Directorate might demand it. :)

> In choosing where to put efforts, would it be "better" to drive down
> the barriers to deploying SSL?

I'm always +1 to that. But at this point I think the barriers are more
social than technical.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 15:50:40 -0700

<hat type='individual'/>

On 11/30/09 1:40 PM, Eran Hammer-Lahav wrote:

> The bottom line is that the new proposal separate the two, allowing
> people who plan to use SSL across the board to focus on the other
> stuff. If OAuth 1.0 requires SSL, it will accomplish nothing but a
> fork in the community and two competing solutions. Instead, my
> proposal makes it modular and allows everyone to play along.

Yes, that seems reasonable, with the caveat that I think we say software
 MUST implement whereas services should deploy.

Peter

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