I do not want to allow the client any flexibility in choosing the algorithm 
once a MAC key has been issued. Every other standard provide a negotiation step 
in which the client can figure out which algorithms are available, and 
therefore needs to indicate which one was used. I don't want to support that 
because it leads to complexity. I am trying my best to keep this as focused and 
limited as possible.

EHL

> -----Original Message-----
> From: Manger, James H [mailto:[email protected]]
> Sent: Sunday, February 06, 2011 5:43 AM
> To: Eran Hammer-Lahav; [email protected]
> Subject: RE: more comments on draft-hammer-oauth-v2-mac-token-02 --
> algorithm param
> 
> Eran,
> 
> >> 13. The MAC algorithm should be explicitly indicated in the request,
> >> instead of being implied by the access-token/id. I suggest including an
> "algorithm"
> >> parameter in the "Authorization" request header. I also suggest
> >> including an "algorithms" parameter in the "WWW-Authenticate"
> >> response header that is a (comma-separated?) list of MAC algorithms that
> the server supports.
> 
> > Why? The client does not get a choice which algorithm to use. There is no
> negotiation here.
> 
> Pretty much every standardised crypto message indicates the algorithm used
> to protect it in the message itself. Why be different?
> 
> Consider hashing the body. You don't need the secret key to do this, but you
> do need to know the hash algorithm. With an algorithm parameter, a front-
> end web server can use that to confirm the body-hash parameter is correct
> before passing the message to a middle tier where the secret key is available
> to verify the MAC.
> 
> An algorithm parameter offers some ability to migrate to stronger MAC
> algorithms if, say, (more) weaknesses in SHA-1 are found. Without it you
> need to issue new credentials to migrate.
> 
> If you have a environment of heterogeneous servers (legacy, new, vendor A,
> vendor B...) they might support different algorithms, but it would handy if
> clients could use a single credential.
> 
> Secret keys are generally handled separately in software than support for
> crypto algorithms. For instance, you can store a secret key in a Java Key
> Store, but I don't think there is an associated spot to specify a MAC
> algorithm.
> 
> --
> James Manger

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

Reply via email to