Re: Thoughts on the key strength issue

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on the key strength issue

Jeffrey Hutzelman


On Friday, March 18, 2005 05:09:58 PM -0500 Sam Hartman <[hidden email]>
wrote:

>>>>>> "Chaskiel" == Chaskiel M Grundman <[hidden email]> writes:
>
>     Chaskiel> --On Friday, March 18, 2005 14:43:13 -0500 Sam Hartman
>     Chaskiel> <[hidden email]> wrote:
>
>     >> That said, I believe it is completely reasonable for pkinit to
>     >> mandate AES128.  As far as I can tell this would be no work for
>     >> implementers and would be an easy solution to the problem.
>
>     Chaskiel> What would it mean to 'mandate AES128'? Is the client
>     Chaskiel> going to be required to not send AES256 in the AS-REQ
>     Chaskiel> when using pkinit? Is the server going to be required to
>     Chaskiel> ignore requests for AES256 if the client does send them?
>     Chaskiel> Do either of those things make sense?
>
> Implementations of Kerberos supporting pkinit MUST implement aes128
> and SHOULD use it for the reply key in pkinit as-reqs.
>
>     Chaskiel> kerberos already has mismatched crypto strengths (even
>     Chaskiel> ignoring passwords): if my user key is 3des only, but
>     Chaskiel> the TGS has an AES256 key, I'm going to get a tgt where
>     Chaskiel> the ticket is protected with AES256 and where the key is
>     Chaskiel> protected with 3des in the AS-REP. How is the pkinit
>     Chaskiel> situation different?
>
> I don't think it is.  I think you need to describe what you are
> matching asymmetric key strength against and justify that.  I think
> matching against the reply key or the session key is going to be easy
> to justify; I think anything else is hard.



OK; we need to come to conclusion on this issue, preferably soon.  To that
end, I will propose the following strawman:

- REQUIRE support for group 14 (currently only RECOMMENDED).
- REQUIRE support for aes128-cts-hmac-sha1-96
- RECOMMEND support for RSA keys at least 2048 bits in size, if
  the implementation supports RSA at all
- Add the following paragraphs to the security considerations section:

       The symmetric reply key size and Diffie-Hellman field size or
       RSA modulus size should be chosen so as to provide sufficient
       cryptographic security [RFC3766].

       When MODP Diffie-Hellman is used, the exponents should have at
       least twice as many bits as the symmetric keys that will be
       derived from them [ODL99].

(the first is adapted from section 3.2.1 step 6; the second is copied
verbatim from the same place).


Sam, does this satisfy your concerns?
Are there any objections to this?

-- Jeff


Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on the key strength issue

Jeffrey Altman
Jeffrey Hutzelman wrote:

> OK; we need to come to conclusion on this issue, preferably soon.  To
> that end, I will propose the following strawman:
>
> - REQUIRE support for group 14 (currently only RECOMMENDED).
> - REQUIRE support for aes128-cts-hmac-sha1-96
> - RECOMMEND support for RSA keys at least 2048 bits in size, if
>  the implementation supports RSA at all
> - Add the following paragraphs to the security considerations section:
>
>       The symmetric reply key size and Diffie-Hellman field size or
>       RSA modulus size should be chosen so as to provide sufficient
>       cryptographic security [RFC3766].
>
>       When MODP Diffie-Hellman is used, the exponents should have at
>       least twice as many bits as the symmetric keys that will be
>       derived from them [ODL99].
>
> (the first is adapted from section 3.2.1 step 6; the second is copied
> verbatim from the same place).
I support these choices.

Jeffrey Altman


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on the key strength issue

Sam Hartman-5
In reply to this post by Jeffrey Hutzelman
Jeff's proposed text satisfies my concerns.



Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on the key strength issue

Jeffrey Hutzelman
In reply to this post by Jeffrey Altman


On Thursday, July 14, 2005 10:16:01 PM -0400 Jeffrey Altman
<[hidden email]> wrote:

> Jeffrey Hutzelman wrote:
>
>> OK; we need to come to conclusion on this issue, preferably soon.  To
>> that end, I will propose the following strawman:
>>
>> - REQUIRE support for group 14 (currently only RECOMMENDED).
>> - REQUIRE support for aes128-cts-hmac-sha1-96
>> - RECOMMEND support for RSA keys at least 2048 bits in size, if
>>  the implementation supports RSA at all
>> - Add the following paragraphs to the security considerations section:
>>
>>       The symmetric reply key size and Diffie-Hellman field size or
>>       RSA modulus size should be chosen so as to provide sufficient
>>       cryptographic security [RFC3766].
>>
>>       When MODP Diffie-Hellman is used, the exponents should have at
>>       least twice as many bits as the symmetric keys that will be
>>       derived from them [ODL99].
>>
>> (the first is adapted from section 3.2.1 step 6; the second is copied
>> verbatim from the same place).
>
> I support these choices.


We don't expect any of these to be controversial, so PKINIT-27 will reflect
these requirements.  However, I'd like to have comments from other members
of the working group on this, especially since it reopens the question of
the requirements level of various DH group sizes which we had previously
discussed.