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

On 12/09/2011 06:30 PM, Mike Jones wrote:
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 protected] [mailto:[email protected]] 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:


On 12/01/2011 08:10 PM, Peter Saint-Andre wrote:
On 12/1/11 1:09 PM, Rob Richards wrote:
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.

That seems fine to me.

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/


_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to