Re: [OAUTH-WG] Mandatory signature algorithms?

[Eran Hammer-Lahav <eran at hueniverse.com>]

Either way you look at it, you are going to have some limitation. We should not force servers to support an algorithm that they deem insecure (and the final say will always go to the server, never the spec). This means defining a default will allow the client to try (and most likely succeed) using a well known method, and will allow the server to reject it with alternatives. However, this approach means that the client will be sending something that the server might consider harmful (exposing something about the credentials). Requiring making an unauthenticated request first to discover the supported algorithm will solve that but will add a roundtrip.

So either way we are going to compromise.

I think trying a default method is better than making a request for a 401 response.

EHL

> -----Original Message-----
> From: oauth-bounces at ietf.org [mailto:oauth-bounces at ietf.org] On Behalf
> Of Richard Barnes
> Sent: Tuesday, September 29, 2009 7:51 AM
> To: Blaine Cook
> Cc: oauth at ietf.org
> Subject: Re: [OAUTH-WG] Mandatory signature algorithms?
> 
> 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
> 
> 
> 
> Blaine Cook wrote:
> > 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.
> >
> > 2009/9/25 Breno <breno.demedeiros at gmail.com>:
> >> 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
> >>
> >> On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer-Lahav
> <eran at hueniverse.com>
> >> wrote:
> >>> The one method I am sure we are going to support is a plaintext
> method.
> >>>
> >>
> >> --
> >> Breno de Medeiros
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth at ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> > _______________________________________________
> > OAuth mailing list
> > OAuth at ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> OAuth at ietf.org
> https://www.ietf.org/mailman/listinfo/oauth