Re: [OAUTH-WG] Signature crypto

["Richard L. Barnes" <[e-mail]>]

We're not talking about using the same key with multiple MACs (that's  
an issue of how the keys are managed).  Rather, we're trying to figure  
out a taxonomy of signing algorithms according to some practical  
criteria.  "Arbitrary bit-string" vs. "Algebraically meaningful" for a  
key seems to be an important distinction for this protocol (since  
there's a question as to what the protocol should use for a signing  
key), but it doesn't imply that you would use the same protocol for  
all signing algorithms of a given class -- this idea is clearly  
ridiculous for asymmetric algorithms, and has some risks, as you say,  
for symmetric algorithms.

--Richard



On Dec 8, 2009, at 10:09 PM, Breno wrote:

>
>
> On Tue, Dec 8, 2009 at 4:17 PM, Richard Barnes <[e-mail]>  
> wrote:
> This isn't quite right.  First of all, you're not constraining the  
> types of *tokens*, you're constraining the types of token *secrets*  
> (the private part, not the public part; the key, not the key label).
>
> Good security practice indicates that a key (the secret part) should  
> be used with a single algorithm. Different algorithm --> different  
> key.
>
>
> Second, there's basically only two classes of signature/secret  
> anyway, symmetric and asymmetric.  MAC algorithms generally take any  
> string of bytes as a key (possibly with a length constraint), since  
> they're just going to XOR it with data anyway.  Public-key  
> algorithms require the secret key to have an relationship to its  
> public half.  The practical implication is that you can use your  
> tokens as MAC keys if you want, but you might need to carry tokens  
> separately if you're using an asymmetric signature algorithm.
>
> While MAC algorithms take any type of key, it is not good practice  
> to use a key with two different MAC algorithms. So while technically  
> it will work, it is not advised practice.
>
>
>
> Net of all that, I'll agree with Brian's earlier claim that OAuth  
> 1.0 had this basically right by having the server advertise what  
> algorithms it supports, with  the one major change that we probably  
> should use the same base string for all algorithms.
>
> --Richard
>
>
>
> On Dec 4, 2009, at 3:35 PM, Eran Hammer-Lahav wrote:
>
>> We have been to some extent talking part each other. Breno and I  
>> spend some time talking about this off line and reached a better  
>> understanding of our positions.
>>
>> We have been approaching this from the wrong direction.
>>
>> The server should not be broadcasting what types of algorithms it  
>> supports. Instead it should be listing what kind of *tokens* it  
>> supports. Since a token secret issued for use with HMAC-SHA1 should/ 
>> may be different from that used with HMAC-SHA512, it is the token  
>> class that determines what it can be used with.
>>
>> The server should indicate the kinds of tokens supported for a  
>> given resource/realm. When obtaining such tokens, the client will  
>> be provided with a new attribute indicating the token type (which  
>> will dictate how it should use it to sign/etc. the canonicalized  
>> request.).
>>
>> The server should indicate in the WWW-Authenticate header which  
>> canonicalizations it supports (with bearer token being a special  
>> case).
>>
>> The authentication scheme should specify how to take the raw  
>> signature and encode it into the Authentication header.
>>
>> This means *are* going to pick a few token types to standardize  
>> which will include the crypto used, and allow extensions by  
>> publishing an RFC + registration.
>>
>> EHL
>>
>>
>>
>>
>> From: Breno [mailto:[e-mail]]
>> Sent: Friday, December 04, 2009 11:46 AM
>> To: Eran Hammer-Lahav
>> Cc: Brian Eaton; OAuth WG ([e-mail])
>> Subject: Re: [OAUTH-WG] Signature crypto
>>
>> I am not sure I buy this. For instance, RSA-SHA1 is _not_ a  
>> signature scheme, PKCS#11 does establish a signature scheme based  
>> on RSA + SHA-1.
>>
>> So to delve beyond the level of abstraction of 'authentication  
>> mechanism name' you need to point to a separate spec for both  
>> signing and verification.
>>
>> I am not sure how much one needs to do beyond defining the byte  
>> representation of what needs to be signed.
>>
>> Some MACs require random pads in addition to keys. Those won't fit  
>> into this abstraction but I don't think we need absolute generality  
>> here.
>>
>> On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer-Lahav <[e-mail] 
>> > wrote:
>> Point where?
>>
>> I didn’t mean new spec for the algorithm, just for how it is used  
>> with the OAuth authentication scheme.
>>
>> EHL
>>
>> From: Breno [mailto:[e-mail]]
>> Sent: Friday, December 04, 2009 11:20 AM
>> To: Brian Eaton
>> Cc: Eran Hammer-Lahav; OAuth WG ([e-mail])
>>
>> Subject: Re: [OAUTH-WG] Signature crypto
>>
>> There is no need to publish a new spec for a new MAC algorithm. MAC  
>> algorithms typically go through certification (e.g., NIST) and have  
>> detailed specs, including test vectors for interoperability.
>>
>> For OAuth, if you want to explicitly support a new MAC algorithm  
>> you will not need to change the transport and you just have to  
>> point to the particular spec that defines the MAC algorithm.
>>
>> On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton <[e-mail]>  
>> wrote:
>> On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav <[e-mail] 
>> > wrote:
>> > I am trying to avoid the need to publish a specification every  
>> time you want
>> > to add a new MAC-based algorithm.
>>
>> People are going to end up needing to write new code every time they
>> want to add a new MAC-based algorithm.
>>
>> Cheers,
>> Brian
>>
>>
>>
>> -- 
>> Breno de Medeiros
>>
>>
>>
>>
>> -- 
>> Breno de Medeiros
>>
>> _______________________________________________
>>
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> -- 
> Breno de Medeiros
>