Subject: [OAUTH-WG] Mandatory signature algorithms?

From: Hubert Le Van Gong <[email-masked]>
Date: Tue, 22 Sep 2009 15:34:54 +0200

Reading the latest draft I see we do not mandate a minimum set of
signature algorithms.
I think we should mandate a few (at least one) so we get a minimum of
interoperability
out of the box.
Thoughts?

Cheers,
Hubert

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Sep 2009 08:19:28 -0700

Yes, it is right there on my list of proposed changes I am seeking feedback on. I think we need to pick one and make it required.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hubert Le Van Gong
> Sent: Tuesday, September 22, 2009 6:35 AM
> To: [email-masked]
> Subject: [OAUTH-WG] Mandatory signature algorithms?
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Breno <[email-masked]>
Date: Thu, 24 Sep 2009 09:47:54 -0700

We should follow the SSL model where the cryptographic primitives are
explicitly negotiated, or use discovery of the supported crypto primitives.
It is no burden for libraries to support multiple ciphers (even dozens of
them). If someone is rolling their own crypto to do OAuth that is VERY VERY
BAD, and OAuth libraries will just include other crypto libraries that
already support everything reasonable or not, and it is OpenSSL in many
cases anyways. The difficulty with crypto is how to normalize the string to
sign, not how to employ the crypto primitives.

The spec needs to define how a client can find which algorithms the server
support.

The spec should not mandate algorithms, and if anything is to be said about
algorithms, I would suggest that it be recommended that the existing schemes
RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N > 2, using
a grandfather clause.

OAuth should not be in the business of certifying cryptography. That is a
whole different industry.

On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> Yes, it is right there on my list of proposed changes I am seeking feedback
> on. I think we need to pick one and make it required.
>
> EHL
>

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Sep 2009 10:47:59 -0700

This goes against our goal of ensuring that any two OAuth compliant client/server can interoperate. We must declare at least one algorithm for that.

EHL

From: Breno [mailto:[email-masked]]
Sent: Thursday, September 24, 2009 9:48 AM
To: Eran Hammer-Lahav
Cc: Hubert Le Van Gong; [email-masked]
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

We should follow the SSL model where the cryptographic primitives are explicitly negotiated, or use discovery of the supported crypto primitives. It is no burden for libraries to support multiple ciphers (even dozens of them). If someone is rolling their own crypto to do OAuth that is VERY VERY BAD, and OAuth libraries will just include other crypto libraries that already support everything reasonable or not, and it is OpenSSL in many cases anyways. The difficulty with crypto is how to normalize the string to sign, not how to employ the crypto primitives.

The spec needs to define how a client can find which algorithms the server support.

The spec should not mandate algorithms, and if anything is to be said about algorithms, I would suggest that it be recommended that the existing schemes RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N > 2, using a grandfather clause.

OAuth should not be in the business of certifying cryptography. That is a whole different industry.

On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Yes, it is right there on my list of proposed changes I am seeking feedback on. I think we need to pick one and make it required.

EHL

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of Hubert Le Van Gong
> To: [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: Jorgen Thelin <[email-masked]>
Date: Thu, 24 Sep 2009 18:28:17 +0000

Which one would we choose, Eran?  This group is not set up to be crypto experts, so we should not be in the business of recommending one universal crypto algorithm - which is effectively what we would be doing if we declared any mandatory algorithm(s).

The choice of crypto algorithm will always depends on the specific scenario, and will also evolve over time (years, not necessarily months).

The goal of a wire protocol should be to support "crypto agility" - i.e. the ability to somehow specify which algorithm is being used, and drop in new ones if/when necessary, rather than baking that choice into the core protocol spec itself.

I completely agree with Breno - this question nets out to a "discovery" problem for this WG to solve, and definitely not an "algorithm choice" problem.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, September 24, 2009 10:48 AM
To: Breno
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

EHL

EHL

--
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Sep 2009 11:36:59 -0700

But the IETF is set up to provide crypto expertise. RFC 2617 had no problem providing two algorithms and allowing extensibility.

I disagree that we cannot find a reasonable crypto algorithm for normal web usage that can be made obsolete when needed. We did it with HMAC-SHA1 in 1.0 and we should be doing it again in this new effort. If we do not guarantee interoperability and provide clear guidance on security for the majority of developers who are not experts, what's the point?

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jorgen Thelin
Sent: Thursday, September 24, 2009 11:28 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

EHL

EHL

--
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Thu, 24 Sep 2009 12:54:38 -0700

SSL does not provide such guidance and yet there is wide interoperability.

The recommendation should be that clients support as many crypto suites as
they feel comfortable using, and so should servers. I have never heard that
SSL has an interoperability problem.

We could go the other way and say that SSL is too promiscuous (true) and
that we aim for higher security. However, aiming security above SSL is
really wishful thinking. What is protecting the user authentication anyway?

I am a crypto expert and I see no reason to fret about using HMAC-SHA1 in
the next 2-3 years at least. Even threat against RSA-SHA1 are probably not
going to materialize in this time-frame.

Crypto agility has been on the whole a very good thing for SSL.

On Thu, Sep 24, 2009 at 11:36 AM, Eran Hammer-Lahav <[email-masked]>wrote:

>  But the IETF is set up to provide crypto expertise. RFC 2617 had no
> problem providing two algorithms and allowing extensibility.
>
>
>
> I disagree that we cannot find a reasonable crypto algorithm for normal web
> usage that can be made obsolete when needed. We did it with HMAC-SHA1 in 1.0
> and we should be doing it again in this new effort. If we do not guarantee
> interoperability and provide clear guidance on security for the majority of
> developers who are not experts, what’s the point?
>
>
>
> EHL
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Jorgen Thelin
> *Sent:* Thursday, September 24, 2009 11:28 AM
> *To:* [email-masked]
>
> *Subject:* Re: [OAUTH-WG] Mandatory signature algorithms?
>
>
>
> Which one would we choose, Eran?  This group is not set up to be crypto
> experts, so we should not be in the business of recommending one universal
> crypto algorithm – which is effectively what we would be doing if we
> declared any mandatory algorithm(s).
>
>
>
> The choice of crypto algorithm will always depends on the specific
> scenario, and will also evolve over time (years, not necessarily months).
>
>
>
> The goal of a wire protocol should be to support “crypto agility” – i.e.
> the ability to somehow specify which algorithm is being used, and drop in
> new ones if/when necessary, rather than baking that choice into the core
> protocol spec itself.
>
>
>
> I completely agree with Breno – this question nets out to a “discovery”
> problem for this WG to solve, and definitely not an “algorithm choice”
> problem.
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Eran Hammer-Lahav
> *Sent:* Thursday, September 24, 2009 10:48 AM
> *To:* Breno
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Mandatory signature algorithms?
>
>
>
> This goes against our goal of ensuring that any two OAuth compliant
> client/server can interoperate. We must declare at least one algorithm for
> that.
>
>
>
> EHL
>
>
>
> *From:* Breno [mailto:[email-masked]]
> *Sent:* Thursday, September 24, 2009 9:48 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Hubert Le Van Gong; [email-masked]
> *Subject:* Re: [OAUTH-WG] Mandatory signature algorithms?
>
>
>

-- 
Breno de Medeiros

---

From: Hubert Le Van Gong <[email-masked]>
Date: Thu, 24 Sep 2009 23:33:06 +0200

I don't think the goal is to certify cryptography but rather ensure reasonable
security and agility. The latter point is key since OAuth is a young protocol
and crypto requirements are very likely to evolve throughout its lifetime.
SHA1 has now known weaknesses. It is not a good policy to base a
new standard on such algorithm.

I don't claim to be a security expert (maybe I do know enough to be
dangerous though) but the beauty of working at Sun Micro is that
there's a whole bunch of security maniacs that I can consult.
Their advise was unanimous: At the very least HMAC-SHA256 and
RSA-SHA256 should be supported, and we need to make sure the
protocol has algorithm (cipher-suite actually) agility so that it can
move to the winner of the SHA3 competition when it becomes
available or, why not, an elliptic curve cipher suite.

Also I'm told it is common for IETF standards to mandate at least
one cipher-suite and recommend additional ones. So SHA256
seems like a good starting point (and it is really not much more
work than SHA1).

Cheers,
Hubert

On Thu, Sep 24, 2009 at 9:54 PM, Breno <[email-masked]> wrote:
>> I disagree that we cannot find a reasonable crypto algorithm for normal
>> web usage that can be made obsolete when needed. We did it with HMAC-SHA1 in
>> 1.0 and we should be doing it again in this new effort. If we do not
>> guarantee interoperability and provide clear guidance on security for the
>> majority of developers who are not experts, what’s the point?
>>
>>
>>
>> EHL
>>
>>
>>
>> The spec should not mandate algorithms, and if anything is to be said
>> about algorithms, I would suggest that it be recommended that the existing
>> schemes RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N >
>> 2, using a grandfather clause.
>>
>> Yes, it is right there on my list of proposed changes I am seeking
>> feedback on. I think we need to pick one and make it required.
>>
>> EHL
>>

---

From: John Kemp <[email-masked]>
Date: Thu, 24 Sep 2009 17:45:00 -0400

> Reading the latest draft I see we do not mandate a minimum set of

Does the "minimum set" include PLAINTEXT (ie. unsigned)?

Regards,

- johnk

---

From: Hubert Le Van Gong <[email-masked]>
Date: Thu, 24 Sep 2009 23:50:25 +0200

For the use cases where security isn't a concern then sure
we'd need plaintext. Which would bring the bare minimum to 2 :)

Hubert

---

From: John Kemp <[email-masked]>
Date: Thu, 24 Sep 2009 18:07:36 -0400

> SSL does not provide such guidance and yet there is wide interoperability.

Indeed, see http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1

There are "default sets" of algorithms, but these are not mandated. 
Instead, if the client either a) supports more algorithms than the 
default set, or b) doesn't support the "default set" it can send an 
extension parameter describing the algorithms it does support.

> 
> The recommendation should be that clients support as many crypto suites 
> as they feel comfortable using, and so should servers. I have never 
> heard that SSL has an interoperability problem.

I too like the SSL approach, which suggests that OAuth should define 
(one or more) "default algorithm sets", without mandating it/them.

I would note further that SSL/TLS decouples hashing algorithm from 
signature algorithm in its text, and as a sidenote, I'd like to see us 
do that too.

Regards,

- johnk

> I am a crypto expert and I see no reason to fret about using HMAC-SHA1 
> in the next 2-3 years at least. Even threat against RSA-SHA1 are 
> probably not going to materialize in this time-frame.
> 
> On Thu, Sep 24, 2009 at 11:36 AM, Eran Hammer-Lahav <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     I disagree that we cannot find a reasonable crypto algorithm for
>     normal web usage that can be made obsolete when needed. We did it
>     with HMAC-SHA1 in 1.0 and we should be doing it again in this new
>     effort. If we do not guarantee interoperability and provide clear
>     guidance on security for the majority of developers who are not
>     experts, what’s the point?
> 
>      
> 
>     EHL
> 
>      
> 
>     *From:* [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On
>     Behalf Of *Jorgen Thelin
>     *To:* [email-masked] <mailto:[email-masked]>
> 
>     Which one would we choose, Eran?  This group is not set up to be
>     crypto experts, so we should not be in the business of recommending
>     one universal crypto algorithm – which is effectively what we would
>     be doing if we declared any mandatory algorithm(s).
> 
>      
> 
>     The goal of a wire protocol should be to support “crypto agility” –
>     i.e. the ability to somehow specify which algorithm is being used,
>     and drop in new ones if/when necessary, rather than baking that
>     choice into the core protocol spec itself.
> 
>      
> 
>     I completely agree with Breno – this question nets out to a
>     “discovery” problem for this WG to solve, and definitely not an
>     “algorithm choice” problem.
> 
>      
> 
>      
> 
>     *From:* [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On
>     Behalf Of *Eran Hammer-Lahav
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     client/server can interoperate. We must declare at least one
>     algorithm for that.
> 
>      
> 
>     EHL
> 
>      
> 
>     *From:* Breno [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* Hubert Le Van Gong; [email-masked] <mailto:[email-masked]>
>     We should follow the SSL model where the cryptographic primitives
>     are explicitly negotiated, or use discovery of the supported crypto
>     primitives. It is no burden for libraries to support multiple
>     ciphers (even dozens of them). If someone is rolling their own
>     crypto to do OAuth that is VERY VERY BAD, and OAuth libraries will
>     just include other crypto libraries that already support everything
>     reasonable or not, and it is OpenSSL in many cases anyways. The
>     difficulty with crypto is how to normalize the string to sign, not
>     how to employ the crypto primitives.
> 
>     The spec should not mandate algorithms, and if anything is to be
>     said about algorithms, I would suggest that it be recommended that
>     the existing schemes RSA-SHA1 and HMAC-SHA1 be supported for the
>     next N years, where N > 2, using a grandfather clause.
> 
>     On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>      > Of Hubert Le Van Gong
>      > To: [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Breno <[email-masked]>
Date: Thu, 24 Sep 2009 15:13:40 -0700

>> SSL does not provide such guidance and yet there is wide interoperability.
I think the word guidance was to strong. SSL does not _mandate_ anything as
minimum support.

> Instead, if the client either a) supports more algorithms than the default
> set, or b) doesn't support the "default set" it can send an extension
> parameter describing the algorithms it does support.
>
>
> I too like the SSL approach, which suggests that OAuth should define (one
> or more) "default algorithm sets", without mandating it/them.
>
> signature algorithm in its text, and as a sidenote, I'd like to see us do
> that too.
>
> Regards,
>
>
-- 
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Thu, 24 Sep 2009 15:15:03 -0700

> available or, why not, an elliptic curve cipher suite.
I have nothing against adding either of this protocols to a suggested cipher
suite such as SSL does. I do think that banning HMAC-SHA1 at this point is
fairly premature.

-- 
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Thu, 24 Sep 2009 15:20:53 -0700

Just to make sure that my answer is understood as endoring John's
suggestion. We should do EXACTLY what SSL/TLS does.

---------- Forwarded message ----------
From: John Kemp <[email-masked]>
Date: Thu, Sep 24, 2009 at 3:17 PM
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?
To: Breno <[email-masked]>

Hi Breno,

I was roughly agreeing with you and suggesting that we should do EXACTLY
what SSL/TLS does - create a default set, and an extension mechanism for
those which don't support the default set. See the referenced link in my
previous email.

Cheers,

- johnk

Breno wrote:

>
> On Thu, Sep 24, 2009 at 3:07 PM, John Kemp <[email-masked] <mailto:
> [email-masked]>> wrote:
>
>    Breno wrote:
>
>        The recommendation should be that clients support as many crypto
>        suites as they feel comfortable using, and so should servers. I
>        have never heard that SSL has an interoperability problem.
>
>
>    signature algorithm in its text, and as a sidenote, I'd like to see
>    us do that too.
>
>    Regards,
>
>
> --
> Breno de Medeiros
>
>

-- 
Breno de Medeiros

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Sep 2009 22:34:59 -0400

There is many years of experience doing this in the IETF.

The SSL approach is not recommended. In fact it is a PITA, ask the TLS
working group. Cipher suites are a bit better than mix and match
crypto algs. But there is huge complexity there that ONLY REDUCES
SECURITY.

Case in point is MD5, the fact that browsers must support MD5 despite
the fact that it was broken in 1995 enabled a cryptanalytic attack of
real certs 18 months back.

As it happens you have no real choice here since you can't mandate an
algorithm we already have issues with (MD2, MD4, MD5 and SHA-1 are
out) and we don't have SHA3 yet. So that leaves SHA2 and HMAC-SHA2.

On public key, your options are RSA, DSA and Eliptic Curve variations thereof.

Now I know that the weakness of SHA1 does not affect HMAC-SHA1, but
you still can't use it for the same reason that you can't use my
HTTP-DIGEST algorithm based on MD5 but not vulnerable to the MD5
compression weakness. Even if you can prove it is secure, it is just
too expensive to keep having to prove it over and over again.

On Thu, Sep 24, 2009 at 6:20 PM, Breno <[email-masked]> wrote:
>> On Thu, Sep 24, 2009 at 3:07 PM, John Kemp <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>    Breno wrote:
>>
>> I think the word guidance was to strong. SSL does not _mandate_ anything
>> as minimum support.
>>
>>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Sep 2009 19:53:40 -0700

The one method I am sure we are going to support is a plaintext method.

EHL

> Of John Kemp
> Sent: Thursday, September 24, 2009 2:45 PM
> To: Hubert Le Van Gong
> Cc: [email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Thu, 24 Sep 2009 23:15:26 -0400

Eran,

Naïve question: What advantage would that have over HTTP Basic 
authentication?  Not requiring Base64?

--Richard

---

From: <[email-masked]>
Date: Fri, 25 Sep 2009 07:47:27 +0200

Breno,

RFC 5246 does specify a mandatory-to-implement cipher suite:
http://tools.ietf.org/html/rfc5246#section-9

Best regards,
Pasi

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Breno
Sent: 25 September, 2009 01:14
To: John Kemp
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

On Thu, Sep 24, 2009 at 3:07 PM, John Kemp <[email-masked]<mailto:[email-masked]>> wrote:
Breno wrote:
SSL does not provide such guidance and yet there is wide interoperability.

I think the word guidance was to strong. SSL does not _mandate_ anything as minimum support.

There are "default sets" of algorithms, but these are not mandated. Instead, if the client either a) supports more algorithms than the default set, or b) doesn't support the "default set" it can send an extension parameter describing the algorithms it does support.

The recommendation should be that clients support as many crypto suites as they feel comfortable using, and so should servers. I have never heard that SSL has an interoperability problem.

I too like the SSL approach, which suggests that OAuth should define (one or more) "default algorithm sets", without mandating it/them.

I would note further that SSL/TLS decouples hashing algorithm from signature algorithm in its text, and as a sidenote, I'd like to see us do that too.

Regards,

--
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Sep 2009 23:13:05 -0700

At a minimum you need to send over the token credentials and client credentials. It doesn't make much sense to abuse Basic auth and force all this information into the username:password pattern. In addition, a resource may support multiple authentication methods in which both Basic auth is available using the actual username and password, as well as OAuth using a token.

It is just a completely different task (direct access vs. delegated access).

EHL

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Thursday, September 24, 2009 8:15 PM
> To: Eran Hammer-Lahav
> Cc: John Kemp; Hubert Le Van Gong; [email-masked]

---

From: Breno <[email-masked]>
Date: Thu, 24 Sep 2009 23:57:38 -0700

> crypto algs. But there is huge complexity there that ONLY REDUCES
I am not arguing that it enhances security. I am arguing that we need a way
to update clients and servers, and without negotiation or crypto agility
this is cumbersome. Recently we did witness a debacle about updating the
OAuth workflow from 1.0 to 1.0a without stepping the protocol version. It
can be easier to adopt more secure cryptography as it becomes available as
well.

> real certs 18 months back.

You mean the fact that browsers engage in a race to the bottom to work with
sites no matter how broken they are. As many of us have noticed, restricting
the set of algorithms in our browsers (must browsers allow you to do this)
still allow use of the vast majority of the sites in the Internet.

> out) and we don't have SHA3 yet. So that leaves SHA2 and HMAC-SHA2.
SHA-1 is broken in theory because it has shown to have less security than
the precise bound given by its length. Unlike attacks against MD-5, they are
impractical.

I would not recommend RSA-SHA1 which uses SHA-1 as a pure hash function, but
HMAC-SHA1 seems quite safe at this point.

> On public key, your options are RSA, DSA and Eliptic Curve variations
You mean everything :)

> too expensive to keep having to prove it over and over again.

Unlike HTTP-DIGEST algorithm, the conditions under which HMAC are secure are
quite well understood. No new proofs are needed.

-- 
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Fri, 25 Sep 2009 08:09:29 -0700

This is another argument against trying to do better than TLS, since OAuth
does not define its own encryption transport mechanism.

Insecurity concerns about TLS are quite manageable by those who care about
security. You can profile TLS at your will. For instance, to make your FF
compliant with FIPS-140-2 TLS profile, follow the instructions here:

http://support.mozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140-2?style_mode=inproduct&s=cipher%20suites

-- 
Breno de Medeiros

---

From: Blaine Cook <[email-masked]>
Date: Tue, 29 Sep 2009 13:40:37 +0100

I'm not sure what the consensus is here, but it seems that at a
minimum, we need a way to determine which algorithms are available, to
allow for negotiation of the cipher suite between a consumer and
service provider.

Ideally the following would be true:

1. A service provider must be able to specify a set of acceptable
ciphers (please correct me if "cipher" is the wrong word to use here).
2. A consumer must be able to specify a set of acceptable ciphers.
3. There must be some simple way to determine the strongest common cipher.

Any takers? Would an ordered list in the HTTP headers (e.g.,
X-OAuth-Supported-Ciphers) be sufficient?

As to the question of a minimum set of supported ciphers, what about
creating a separate RFC (or other document?) that (a) specifies
required and optional ciphers, and (b) can be deprecated and point to
a new document as needed, without needing to update the OAuth Core
RFC?

b.

---

From: Hubert Le Van Gong <[email-masked]>
Date: Tue, 29 Sep 2009 16:35:19 +0200

If a separate document is easier to maintain then let's do that,
provided that document remains normative (i.e. compatibility with the
IETF OAuth spec includes compatibility with this doc). Would that
be an RFC though?

I think having a basic cipher-suite negotiation embedded in the protocol
is great to have. If not, then at the very least additional messaging
capability to that end should be added to the problem reporting
extension (but that's kind of stretching the meaning of problem
reporting IMO).

Cheers,
Hubert

---

From: Richard Barnes <[email-masked]>
Date: Tue, 29 Sep 2009 10:50:44 -0400

Hey Blaine,

You've got the general pattern right, but I'm not sure how well it maps 
to the general use of OAuth signatures: One of the main benefits of 
OAuth vs. Digest is that it can be done in a single HTTP round-trip -- 
the server doesn't need to issue a challenge in order for the client to 
construct the signature.  That creates a problem for crypto agility 
because by the same token, the server doesn't have a chance to specify 
which cipher suites it supports.   (Here I'm using client and server in 
the HTTP sense, which I think map to your "consumer" and "service 
provider" below.)

A couple of work-arounds occur to me:

1. Allow the client to provide multiple signatures using different 
cipher suites, and let the server choose which one to validate (MUST use 
only one to prevent bid-down attacks).  If the client provides all the 
signatures it knows how to do, then this is equivalent to a full 
negotiation.

2. Allow the server to reject signatures and specify which cipher suites 
it supports, so that the client can cache for future requests.

--Richard

---

From: Hubert Le Van Gong <[email-masked]>
Date: Tue, 29 Sep 2009 17:02:16 +0200

An alternative would be to say that the OOB initiation phase that takes place
prior to the OAuth dance is the right time to perform such negotiation...
After all it is about discovering each other's capabilities.
We would then only need some simple error message in the problem reporting ext.

Just a thought.

Hubert

On Tue, Sep 29, 2009 at 4:50 PM, Richard Barnes <[email-masked]> wrote:
> Hey Blaine,
>
> You've got the general pattern right, but I'm not sure how well it maps to
> the general use of OAuth signatures: One of the main benefits of OAuth vs.
> Digest is that it can be done in a single HTTP round-trip -- the server
> doesn't need to issue a challenge in order for the client to construct the
> signature.  That creates a problem for crypto agility because by the same
> token, the server doesn't have a chance to specify which cipher suites it
> supports.   (Here I'm using client and server in the HTTP sense, which I
> think map to your "consumer" and "service provider" below.)
>
> 1. Allow the client to provide multiple signatures using different cipher
> suites, and let the server choose which one to validate (MUST use only one
> to prevent bid-down attacks).  If the client provides all the signatures it
> knows how to do, then this is equivalent to a full negotiation.
>
> 2. Allow the server to reject signatures and specify which cipher suites it
> supports, so that the client can cache for future requests.
>
> --Richard
>
>
>
> Blaine Cook wrote:
>>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 29 Sep 2009 11:20:56 -0400

That could work in the "OAuth delegation" use case, where the parties 
are going to go to the effort of provisioning.  Even in that case, 
though, you would also have to provision algorithms into the Resource 
Owner (i.e., the User), since he also needs to sign requests (to the 
Client/Consumer) as part of the dance.

I'm more worried about the general usage of OAuth signatures to sign 
HTTP requests.  Again making the analogy to Digest, there is an 
assumption there that keys are pre-provisioned (=tokens for OAuth), but 
not algorithms (See Section 3.2.1).

--Richard

---

From: Brian Eaton <[email-masked]>
Date: Tue, 29 Sep 2009 09:47:09 -0700

Wow, this is a great discussion.  I'd like to make a few comments on
the goals...

There are attacks against the kinds of protocols being discussed here
where a MITM or a malicious server can force a client to the weakest
signing algorithm supported by client.  I don't think we should worry
about a man-in-the-middle.  https is adequate prevention against MITM
attacks, and if the client isn't requiring https they probably have
bigger concerns than HMAC-SHA1 vs HMAC-SHA256.

I'm not sure whether we should worry about malicious servers.  For
example, imagine a client is tricked into sending a signed OAuth
request to a malicious server, e.g. a client is tricked into sending a
request to https://evil.com using an access token originally issued by
https://good.com.  Note that this is NOT a man-in-the-middle attack.
The client is really talking to evil.com. The client is confused and
is sending authentication credentials issued by/for good.com to
evil.com.  There are various real-world situations where this can
happen.  Imagine a client following links or redirects and trying to
authenticate with OAuth.

If we're using plaintext, this is a disaster.  The client just leaked
credentials to evil.com.

If we're using HMAC-SHA1, this is less of a big deal.  The request is
signed for evil.com, and evil.com cannot replay it anywhere else.
Both the consumer secret and the token secret provide some security.
Even if the consumer secret leaks (e.g. it's embedded in a desktop
application), evil.com gains nothing.

If we're using RSA-SHA1, the situation is better than plaintext, but
worse than HMAC-SHA1.  The token secret doesn't provide any additional
security for the RSA signatures.  evil.com would know the access
token, and if they somehow manage to steal the consumer secret, they
have everything they need to impersonate the client.

I'm making some assumptions about the problem domain here.  Is it
reasonable to think about the problem of signature method choice using
this type of analysis?

Cheers,
Brian

On Tue, Sep 29, 2009 at 8:20 AM, Richard Barnes <[email-masked]> wrote:
> That could work in the "OAuth delegation" use case, where the parties are
> going to go to the effort of provisioning.  Even in that case, though, you
> would also have to provision algorithms into the Resource Owner (i.e., the
> User), since he also needs to sign requests (to the Client/Consumer) as part
> of the dance.
>
> I'm more worried about the general usage of OAuth signatures to sign HTTP
> requests.  Again making the analogy to Digest, there is an assumption there
> that keys are pre-provisioned (=tokens for OAuth), but not algorithms (See
> Section 3.2.1).
>
> --Richard
>
>
>
>>> to
>>> it
>>>>> On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer-Lahav
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Sep 2009 13:17:45 -0400

The problem with HMAC-SHA1 is not the security of the algorithm, it is
the ongoing cost of explaining why it is safe.

Relying on SSL is no solution as the SSL negotiation algorithm will
fail completely if SHA1 is broken. There is a deployment trap,
merchants are not going to tell their customers that they have to
upgrade their browser to buy from them, CAs are not going to refuse to
sell the only certs that the merchants will buy and the browser
providers are not going to tell customers that they can't use SHA1
merchants if they upgrade.

The MD5 transition was easy because every browser supported both algorithms.

The security area reviewer is going to insist that HMAC-SHA2 is a
mandatory algorithm. There is no particular performance advantage to
SHA1. We are going to have to make SHA1 obsolete at some point, why
not now?

I see no particular difficulty in making SHA1 a MUST support algorithm
for backwards compatibility purposes and deprecate it as far as future
revisions of the spec are concerned, i.e. if we end up with a
backwards incompatible revision to the spec, clients MUST NOT offer
SHA1 with the new version of the spec.

---

From: Brian Eaton <[email-masked]>
Date: Tue, 29 Sep 2009 10:32:08 -0700

On Tue, Sep 29, 2009 at 10:17 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> fail completely if SHA1 is broken.

OAuth is not going to save us if SSL is broken.

> mandatory algorithm.

The security reviewer is going to lose that fight, because we cannot
mandate deployment decisions for consumers or service providers.

Saying that HMAC-SHA2 must be supported is equivalent to saying that
service providers must use passwords to authenticate users, or must
use https, or must support openid.  Those are not spec decisions.
They are deployment decisions.  Some service providers might choose to
only support RSA public keys, for example.  Forcing those service
providers to violate a "must" in the spec is not useful.

> There is no particular performance advantage to

This I agree with.  I think it's reasonable (even important!) for the
spec to offer a simple means of upgrading from HMAC-SHA1 to HMAC-SHA2.
 I'm just not wild about the idea of the spec saying that anyone has
to support any cryptographic scheme.

Cheers,
Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Sep 2009 13:47:54 -0400

I think you don't quite appreciate what is meant by mandatory in this
context. Mandatory is mandatory to implement, not mandatory to use.

All that making an algorithm mandatory means is that an implementation
that advertises itself as RFCxxxx compliant MUST support it. So if
someone buys a framework that advertises OATH support the algorithm
must be one of the ones in the box.

It does not mean that anyone has to use it, or for that matter that
every person who codes up an implementation for private purposes has
to implement it.

It is the same with the HTTP spec, a HTTP client MUST implement GET,
PUT and POST. But that does not mean that people have to use those
methods. And if someone was writing a single purpose bit of code they
could implement only GET if that is all their implementation needed.

Now it gets a little trickier if we are talking about advertising
algorithms in the context of negotiations as there is a policy layer
as well. If OATH is being used in an NSA context they would probably
want to require use of a Suite-A algorithm.

In that case they don't have to offer the mandatory to implement
algorithm, but they do have to implement enough to be able to
negotiate use of their secure algorithm. That does not affect OATH but
does affect IPSEC.

This is an argument that we end up going through in every security
working group. We really should just write a paper and get the IAB to
stamp it.

---

From: Brian Eaton <[email-masked]>
Date: Tue, 29 Sep 2009 10:56:25 -0700

> every person who codes up an implementation for private purposes has

Gotcha.  That makes perfect sense to me.

How about the following scheme for the negotiation piece of the protocol?

1) Client attempts a signature with the best algorithm they believe
the server supports.
2) If the server does not support that algorithm, the server returns
with an error response listing the algorithms they are willing to
accept.
3) Clients may retry with other algorithms in the list.

That seems like it would give us a smooth upgrade path from SHA1 to SHA2.

Cheers,
Brian

---

From: Blaine Cook <[email-masked]>
Date: Tue, 29 Sep 2009 19:58:35 +0100

> That seems like it would give us a smooth upgrade path from SHA1 to SHA2.

+1. This nicely supports the server being able to say "no" to
PLAINTEXT requests made over non-SSL HTTP (and probably delete the
token if the client makes such a request).

In the interests of moving this along, any opposition? Additional support?

b.

---

From: Hubert Le Van Gong <[email-masked]>
Date: Tue, 29 Sep 2009 22:22:46 +0200

+1 on the negotiation protocol.

Do we also have consensus on a must-implement list of protocols
that would list:
- plaintext
- SHA1 cipher suite
- SHA2 cipher suite

Cheers,
Hubert

---

From: John Panzer <[email-masked]>
Date: Tue, 29 Sep 2009 14:00:09 -0700

+1; note that fits perfectly into RFC2617.
(Though obviously a client that ends up sending anything secret over an
insecure connection has possibly given up the game before the server has a
chance to reject it.  But hopefully this would help discourage such clients
from even being deployed.)

--
John Panzer / Google
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer