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
> -----Original Message-----
> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
> Sent: Tuesday, June 08, 2010 3:11 PM
> To: Yaron Goland; oauth@ietf.org
> Subject: RE: Questions about sections 3.2/3.3
>
>
>
> > -----Original Message-----
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Yaron Goland
> > Sent: Thursday, May 20, 2010 12:20 PM
> > To: oauth@ietf.org
> > 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
