Subject: Re: [OAUTH-WG] Questions about sections 3.2/3.3

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 8 Jun 2010 15:10:30 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yaron Goland
> Sent: Thursday, May 20, 2010 12:20 PM
> To: [email-masked]
> Subject: [OAUTH-WG] Questions about sections 3.2/3.3
> 
> I was reading through the spec and had some questions about 3.2 and 3.3
> that I list below.
>                 Thanks,
>                                 Yaron
> Section 3.2/3.3 - Handling requests without supported transport layer
> security
> 
> Although optional in section 3.2 and mandatory in section 3.3 both sections
> have a similar challenge - what happens if someone makes a request
> without the transport layer security required by the endpoint? What HTTP
> error is to be returned? 401? 403?

404 Not found. The server provides the absolute URI of the endpoint. If you ask for something else that doesn't exist, you get a 404. Note that the endpoint in 3.2 is really a web-site, not a web service. It is a browser-specific endpoint and should support the strongest protection provided by supported browsers.

> A further complication is that both sections explicitly allow for transport layer
> security solutions other than TLS/SSL. Doesn't this mean that we need to
> extend section 6.1's definition of the www-authenticate response header to
> also specify what transport layer security mechanisms are supported?

Neither section uses the header because these endpoints are not OAuth-protected. They might use something else but that's outside the scope.

In general, I think we just need to say what support is required and leave the rest for servers to decide. There is no value in saying that other methods may be used (there is no standards police and when you do that, you break interop anyway).
 
> Section 3.3 - Is TLS/SSL mandatory or optional? And if so, what version of
> TLS/SSL?

Is it ok to require TLS 1.2?

> The specification currently states:
> 
>    .the
>    authorization server MUST require the use of a transport-layer
>    mechanism such as TLS/SSL (or a secure channel with equivalent
>    protections) when sending requests to the token endpoints.
> 
> To me this text implies that an OAuth server could be conformant and not
> implement TLS/SSL but instead implement some other transport-layer
> security mechanism (say a VPN protocol). From an interoperability
> perspective that seems problematic since it means clients can't know what
> transport-layer solution the token endpoint will support. Wouldn't it be
> reasonable to put in a requirement that all OAuth endpoints MUST support
> RFC 5246 and RFC 5746?

5246 makes sense. I don't know enough to say about 5746.
 
> In other words the language could read: ".the authorization server MUST
> require the use of a transport-layer mechanism when sending requests to
> the token endpoints. Specifically, authorization servers MUST support
> version 1.2 of TLS as defined in RFC 5246 and extended in RFC 5746 and MAY
> support other equivalent secure channel mechanisms".
> 
> Section 3.3.1 - What error is returned if clients provide credentials in both
> the header and the body?

400 Bad Request.

> Section 3.3.1 explicitly prohibits submitting client credentials using multiple
> schemes but it doesn't define what error to return if this requirement is
> violated. Given the requirement in section 3.3.2.2 to include the "error" field
> wouldn't it be useful to define URIs that map to specific errors defined in the
> specification? For example, "If the client does include multiple client
> credential schemes then, per section 3.3.2.2, a 400 Bad Request response
> MUST be sent with an error code of urn:ietf:rfc:X:multiple-client-
> credentials".

Why a URI? What's wrong with simple text strings? Are you expecting collision of error messages?

> Section 3.3.1 - How exactly are client credentials passed via HTTP Basic
> authentication?

Client id -> username, client secret -> password.

> Although section 3.3.1 states that HTTP basic authentication is to be
> supported, it doesn't specify how. I realize the mapping is pretty obvious but
> standards are one area where it pays off to be pedantic. Would it be useful
> to add language such as?:
> 
> "The authorization server MUST accept the client credentials using both the
> request parameters and the HTTP Basic authentication scheme as defined in
> [RFC2617]. When using HTTP Basic the client id MUST be mapped to the HTTP
> Basic userid and the client secret MUST be mapped to the HTTP Basic
> password. The realm value can either be discovered by sending an
> unauthenticated request and examining the returned realm value in the
> www-Authenticate header or by reading the authorization service's
> documentation."

I changed to:

            The client MAY include the client credentials using an HTTP authentication scheme
            which supports authenticating using a username and password, instead of using the
            'client_id' and 'client_secret' request parameters. Including the client credentials using an HTTP authentication
            scheme fulfills the requirements of including the parameters as defined by the
            various flows.

Which I think does the trick.

EHL

---

From: Michael D Adams <[email-masked]>
Date: Wed, 9 Jun 2010 17:42:42 -0700

On Tue, Jun 8, 2010 at 3:10 PM, Eran Hammer-Lahav <[email-masked]> wrote:
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaron Goland

Does anyone have a list of libraries that support TLS 1.2?

OpenSSL, for example, only supports TLS 1.0 in the current stable
release.  That'd be RFC2246 (presumably plus extensions).

I don't know the difference between SSL and TLS let alone TLS 1.0 and
TLS 1.2, but a systems friend of mine says:

> I dont think it is realistic to require anything higher than TLS 1.0.
>
> OpenSSL 0.9, which is still supported and is the version in every major Linux
> distro's package manager, only supports TLS 1.0.
>
> OpenSSL 1.0 AFAIK also only supports TLS 1.0. OpenSSL 1.1.0 is going to have
> support for TLS 1.1 [1], but is "some years away" as of about a year ago [2].
>
> Debian: 0.9.8c http://packages.debian.org/etch/openssl
> Ubuntu: 0.9.8k http://packages.ubuntu.com/lucid/openssl
> RHEL5 : 0.9.8e http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/
>
> [1]: http://marc.info/?l=openssl-users&m=127531288020106&w=2
> [2]: http://www.mail-archive.com/[email-masked]/msg56601.html

--mdawaffe

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Jun 2010 19:38:14 -0600

>> I dont think it is realistic to require anything higher than TLS 1.0.

Typically, specifications do the following:

1. Require support for Transport Layer Security.

2. Point to the latest specification of that technology (RFC 5246).

3. Prohibit or strongly discourage use of some older versions of that
technology -- often SSL 2.0 but in some cases also SSL 3.0.

I can provide suggested text along those lines (see rfc3920bis for ideas).

Peter

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 9 Jun 2010 22:47:40 -0700

Please do.

EHL

> Of Peter Saint-Andre
> Sent: Wednesday, June 09, 2010 6:38 PM
> To: [email-masked]
> Subject: Re: [OAUTH-WG] Questions about sections 3.2/3.3
> 
> >>> From: [email-masked] [mailto:[email-masked]] On
> >>> Behalf Of Yaron Goland Section 3.3 - Is TLS/SSL mandatory or
> >>> optional? And if so, what version of TLS/SSL?
> >>
> >>> To me this text implies that an OAuth server could be conformant and
> >>> not implement TLS/SSL but instead implement some other
> >>> transport-layer security mechanism (say a VPN protocol). From an
> >>> interoperability perspective that seems problematic since it means
> >>> clients can't know what transport-layer solution the token endpoint
> >>> will support. Wouldn't it be reasonable to put in a requirement that
> >>> all OAuth endpoints MUST support RFC 5246 and RFC 5746?
> >>
> >>> In other words the language could read: ".the authorization server
> >>> MUST require the use of a transport-layer mechanism when sending
> >>> requests to the token endpoints. Specifically, authorization servers
> >>> MUST support version 1.2 of TLS as defined in RFC 5246 and extended
> >>> in RFC 5746 and MAY support other equivalent secure channel
> mechanisms".
> >

---

From: Yaron Goland <[email-masked]>
Date: Thu, 10 Jun 2010 17:20:50 +0000

The proposed error codes all seem reasonable but it would be good to call them out in the spec so there are common understandings of how to handle the situation.

RFC 5746 matters because the TLS renegotiation attack is particularly potent against exactly the kind of web services that would use OAuth. But I leave it to the security mavens to figure out if we can reasonably go out without requiring 5746. Is the threat of the renegotiation attack strong enough to merit 5746? I'm honestly not sure.

For error messages I was proposing URIs only so that 3rd parties can add in their own error messages without conflicting. It would be equally fine to say something along the lines of the spec will use plain text strings and anyone else who wants to use a plain text string needs to get a RFC approved. If you want to shove in your own errors then use a URI to prevent collisions. There has to be some benefit to going through the RFC process, let it be that we get the easy to read strings. :)

Your language around basic seems fine but shouldn't we say something about realm? It is mandatory in basic.

	Thanks,

			Yaron

> From: Eran Hammer-Lahav [mailto:[email-masked]]
> Sent: Tuesday, June 08, 2010 3:11 PM
> To: Yaron Goland; [email-masked]
> Subject: RE: Questions about sections 3.2/3.3
> 
> 
> 
> > I was reading through the spec and had some questions about 3.2 and
> > 3.3 that I list below.
> >                 Thanks,
> >                                 Yaron
> > Although optional in section 3.2 and mandatory in section 3.3 both
> > sections have a similar challenge - what happens if someone makes a
> > request without the transport layer security required by the endpoint?
> > What HTTP error is to be returned? 401? 403?
> 
> 404 Not found. The server provides the absolute URI of the endpoint. If you
> ask for something else that doesn't exist, you get a 404. Note that the
> endpoint in 3.2 is really a web-site, not a web service. It is a browser-specific
> endpoint and should support the strongest protection provided by
> supported browsers.
> 
> > A further complication is that both sections explicitly allow for
> > transport layer security solutions other than TLS/SSL. Doesn't this
> > mean that we need to extend section 6.1's definition of the
> > www-authenticate response header to also specify what transport layer
> security mechanisms are supported?
> 
> Neither section uses the header because these endpoints are not OAuth-
> protected. They might use something else but that's outside the scope.
> 
> In general, I think we just need to say what support is required and leave the
> rest for servers to decide. There is no value in saying that other methods may
> be used (there is no standards police and when you do that, you break
> interop anyway).
> 
> > Section 3.3 - Is TLS/SSL mandatory or optional? And if so, what
> > version of TLS/SSL?
> 
> > not implement TLS/SSL but instead implement some other transport-layer
> > perspective that seems problematic since it means clients can't know
> > what transport-layer solution the token endpoint will support.
> > Wouldn't it be reasonable to put in a requirement that all OAuth
> > endpoints MUST support RFC 5246 and RFC 5746?
> 
> > MUST support version 1.2 of TLS as defined in RFC 5246 and extended in
> > RFC 5746 and MAY support other equivalent secure channel mechanisms".
> >
> > Section 3.3.1 - What error is returned if clients provide credentials
> > in both the header and the body?
> 
> 400 Bad Request.
> 
> > Section 3.3.1 explicitly prohibits submitting client credentials using
> > multiple schemes but it doesn't define what error to return if this
> > requirement is violated. Given the requirement in section 3.3.2.2 to
> > include the "error" field wouldn't it be useful to define URIs that
> > map to specific errors defined in the specification? For example, "If
> > the client does include multiple client credential schemes then, per
> > section 3.3.2.2, a 400 Bad Request response MUST be sent with an error
> > code of urn:ietf:rfc:X:multiple-client- credentials".
> 
> > Section 3.3.1 - How exactly are client credentials passed via HTTP
> > Basic authentication?
> 
> > supported, it doesn't specify how. I realize the mapping is pretty
> > obvious but standards are one area where it pays off to be pedantic.
> > Would it be useful to add language such as?:
> >
> > "The authorization server MUST accept the client credentials using
> > both the request parameters and the HTTP Basic authentication scheme
> > as defined in [RFC2617]. When using HTTP Basic the client id MUST be
> > mapped to the HTTP Basic userid and the client secret MUST be mapped
> > to the HTTP Basic password. The realm value can either be discovered
> > by sending an unauthenticated request and examining the returned realm
> > value in the www-Authenticate header or by reading the authorization
> > service's documentation."
> 
> I changed to:
>