Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

From: Rob Richards <[email-masked]>
Date: Thu, 01 Dec 2011 15:09:48 -0500

On 11/28/11 10:39 PM, Barry Leiba wrote:
>> The OAuth base doc refers in two places to TLS versions (with the same
>> text in both places:
>>
>> OLD
>> The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD
>> support TLS 1.2 ([RFC5246]) and its future replacements, and MAY
>> support additional transport-layer mechanisms meeting its security
>> requirements.
>>
>> In both the shepherd review and the AD review, this was called into question:
>> 1. MUST for an old version and SHOULD for the current version seems wrong.
>> 2. Having specific versions required locks us into those versions (for
>> example, all implementations will have to support TLS 1.0, even long
>> after it becomes obsolete, unless we rev the spec.
> The comments I've gotten on this show a clear consensus against the
> change I suggest, and against any attempt to require a version of TLS
> other than 1.0.  I still, though, am concerned that locking this spec
> into TLS 1.0 is limiting.  So let me propose an alternative wording,
> which again tries to make the version(s) non-normative, while making
> it clear which version(s) need to be implemented to get
> interoperability:
>
> NEW
> --------------------------------------------
> The authorization server MUST implement TLS.  Which version(s)
> ought to be implemented will vary over time, and depend on
> the widespread deployment and known security vulnerabilities at
> the time of implementation.  At the time of this writing, TLS version
> 1.2 [RFC5246] is the most recent version, but has very limited
> actual deployment, and might not be readily available in
> implementation toolkits.  TLS version 1.0 [RFC2246] is the
> most widely deployed version, and will give the broadest
> interoperability.
>
> Servers MAY also implement additional transport-layer
> mechanisms that meet their security requirements.
> --------------------------------------------
>
> Comments on this version?
>
> Barry
>

Text is neutral enough for me as it's not mandating anything that isn't 
readily available. Only comment is whether or not there is a need to 
even talk about the specific versions or if just the following is enough:

The authorization server MUST implement TLS. Which version(s) ought to 
be implemented will vary over time, and depend on the widespread 
deployment and known security vulnerabilities at the time of implementation.

Servers MAY also implement additional transport-layer mechanisms that 
meet their security requirements.

Rob

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Dec 2011 13:10:35 -0700

> meet their security requirements.

That seems fine to me.

Peter

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 01 Dec 2011 20:57:00 +0000

>> meet their security requirements.

FWIW, I think I'd prefer Barry's as Rob's would be more likely
to generate discusses and we do know that there are some security
advantages to TLS 1.2 vs. 1.0. (BTW, has anyone considered how
or if the BEAST attack might affect oauth? Be good to know if
someone's done that analysis.)

However, as AD, I could live with either, since lots of other
specs just say TLS. (But you need to point to the latest RFC as
normative or that will I bet generate discusses.)

Cheers,
S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Dec 2011 13:59:14 -0700

> normative or that will I bet generate discusses.)

Agreed.

Peter

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

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Mon, 5 Dec 2011 10:59:21 -0600

BEAST is an attack against TLS 1.0. In order to succeed, an attacker, predicting that a user will eventually make an https connection to www.example.com, lures the user to an attacker-controlled web site. From that site the user browser downloads the attacker's script (e.g., JavaScript). Then, if the user indeed establishes https connection to www.example.com using the same browser window, an attacker can analyze the traffic generated by the normal user activity and the traffic generated on the same connection by the attacker's script. This may allow the attacker to decipher a targeted part (for example a part where the user's password should be) of the user traffic. The attack requires significant time. For example, it took 103 seconds for a published attack against PayPal to decipher a cookie.

OAuth 2.0 requires (MUST) TLS protection of the connections between the user browser and authorization endpoint and between client and the token endpoint. Both connections are not likely to last long enough for the attack to succeed.
The client's connection is a less likely target, because it is more difficult to get a client engaged in the described scenario. 

In my opinion vulnerability of TLS 1.0 to the BEAST attack does not affect significantly security of OAuth 2.0.
(TLS 1.1 and 1.2 are not vulnerable to the attack.)

Zachary Zeltsan
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, December 01, 2011 3:57 PM
To: Peter Saint-Andre
Cc: Barry Leiba; oauth WG
Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

On 12/01/2011 08:10 PM, Peter Saint-Andre wrote:
>>>> The OAuth base doc refers in two places to TLS versions (with the 
>>>> same text in both places:
>>>>
>>>> OLD
>>>> 2. Having specific versions required locks us into those versions 
>>>> (for example, all implementations will have to support TLS 1.0, 
>>>> even long after it becomes obsolete, unless we rev the spec.
>>> change I suggest, and against any attempt to require a version of 
>>> TLS other than 1.0.  I still, though, am concerned that locking this 
>>> spec into TLS 1.0 is limiting.  So let me propose an alternative 
>>> wording, which again tries to make the version(s) non-normative, 
>>> while making it clear which version(s) need to be implemented to get
>>> interoperability:
>>>
>>> NEW
>>> The authorization server MUST implement TLS.  Which version(s) ought 
>>> to be implemented will vary over time, and depend on the widespread 
>>> deployment and known security vulnerabilities at the time of 
>>> implementation.  At the time of this writing, TLS version
>>> implementation toolkits.  TLS version 1.0 [RFC2246] is the most 
>>> widely deployed version, and will give the broadest 
>>> interoperability.
>>>
>>> Servers MAY also implement additional transport-layer mechanisms 
>>> that meet their security requirements.
>> Text is neutral enough for me as it's not mandating anything that 
>> isn't readily available. Only comment is whether or not there is a 
>> need to even talk about the specific versions or if just the following is enough:
>>
>> The authorization server MUST implement TLS. Which version(s) ought 
>> to be implemented will vary over time, and depend on the widespread 

FWIW, I think I'd prefer Barry's as Rob's would be more likely to generate discusses and we do know that there are some security advantages to TLS 1.2 vs. 1.0. (BTW, has anyone considered how or if the BEAST attack might affect oauth? Be good to know if someone's done that analysis.)

However, as AD, I could live with either, since lots of other specs just say TLS. (But you need to point to the latest RFC as normative or that will I bet generate discusses.)

Cheers,
S.

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

---

From: Mike Jones <[email-masked]>
Date: Fri, 9 Dec 2011 18:30:08 +0000

It looks to me like there is consensus for Barry's text (below).  Agreed?

				-- Mike

NEW
--------------------------------------------
The authorization server MUST implement TLS.  Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation.  At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits.  TLS version 1.0 [RFC2246] is the most widely deployed version, and will give the broadest interoperability.

Servers MAY also implement additional transport-layer mechanisms that meet their security requirements.
--------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, December 01, 2011 12:59 PM
To: Stephen Farrell
Cc: Barry Leiba; oauth WG
Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base

On 12/1/11 1:57 PM, Stephen Farrell wrote:
>>>>> In both the shepherd review and the AD review, this was called 
>>>>> into
>>>>> question:
>>>> TLS other than 1.0.  I still, though, am concerned that locking 
>>>> this spec into TLS 1.0 is limiting.  So let me propose an 
>>>> alternative wording, which again tries to make the version(s) 
>>>> non-normative, while making it clear which version(s) need to be 
>>>> implemented to get
>>>> interoperability:
>>>>
>>>> NEW
>>>> ought to be implemented will vary over time, and depend on the 
>>>> widespread deployment and known security vulnerabilities at the 
>>>> time of implementation.  At the time of this writing, TLS version
>>> need to even talk about the specific versions or if just the 
>>> following is
>>> enough:
>>>
>>> implementation.
> FWIW, I think I'd prefer Barry's as Rob's would be more likely to 
> generate discusses and we do know that there are some security 
> advantages to TLS 1.2 vs. 1.0. (BTW, has anyone considered how or if 
> the BEAST attack might affect oauth? Be good to know if someone's done 
> that analysis.)
> 
> However, as AD, I could live with either, since lots of other specs 
> just say TLS. (But you need to point to the latest RFC as normative or 
> that will I bet generate discusses.)

Agreed.

Peter

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 09 Dec 2011 19:43:38 +0000

All but the last bit seems ok to me FWIW. I don't know what
an "additional transport-layer mechanism" might be.

I'd say just leave that bit out. TLS is already a MUST
implement.

S

---

From: Rob Richards <[email-masked]>
Date: Sat, 10 Dec 2011 14:26:05 -0500

I am fine with it

Rob

---

From: William Mills <[email-masked]>
Date: Sun, 11 Dec 2011 09:28:13 -0800 (PST)

I think it's overkill, but I don't think it causes any problems.

________________________________
 From: Rob Richards <[email-masked]>
To: Mike Jones <[email-masked]> 
Cc: Barry Leiba <[email-masked]>; oauth WG <[email-masked]> 
Sent: Saturday, December 10, 2011 11:26 AM
Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
 
I am fine with it

Rob

---

From: Justin Richer <[email-masked]>
Date: Mon, 12 Dec 2011 10:40:44 -0500

Agreed -- I think that this text addresses the concerns of those who had 
them without getting in too deep to things that are, quite frankly, 
ancillary to OAuth. I still contend that the vast majority of 
implementors reading this will see that line and say "Oh, I need an 
https there instead of an http" and call it a day, but the proposed text 
doesn't *hurt* that case, so I'm relatively fine with it.

  -- Justin

On 12/11/2011 12:28 PM, William Mills wrote:
> ------------------------------------------------------------------------
> *From:* Rob Richards <[email-masked]>
> *To:* Mike Jones <[email-masked]>
> *Cc:* Barry Leiba <[email-masked]>; oauth WG <[email-masked]>
> *Sent:* Saturday, December 10, 2011 11:26 AM
> *Subject:* Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
>
> I am fine with it
>
> Rob
>
> implementation.  At the time of this writing, TLS version 1.2 
> [RFC5246] is the most recent version, but has very limited actual 
> deployment, and might not be readily available in implementation 
> toolkits.  TLS version 1.0 [RFC2246] is the most widely deployed 
> version, and will give the broadest interoperability.
> >
> > From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] On 
> Behalf Of Peter Saint-Andre
> > [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Barry Leiba <[email-masked]>
Date: Sun, 18 Dec 2011 13:55:31 -0500

To close out this issue:
There's disagreement about whether this proposed text is "necessary",
but no one thinks it's *bad*, and I see consensus to use it.  Eran,

> mechanisms that meet their security requirements.

Barry, as chair