Subject: Thoughts on the key strength issue

From: Sam Hartman <[email-masked]>
Date: Fri, 18 Mar 2005 14:43:13 -0500

Hi.  larry and I have been discussing the key strength issue and I've
revised my position somewhat.

First, Larry points out we do not discuss key sizes for signing or
encrypting.  Especially for encrypting we need to discuss the size of
the RSA key.  I think signing probably requires a discussion too.

Second, Larry has convinced me that it is not strictly required that
the DH group size match the size of the symmetric reply key.  It's
important that it match the needs of the application.  I believe that
presumptively matching the size of the reply key counts as matching
the needs of the application.

If the working group does something else then it needs to document
what it is trying to match and why that's a reasonable thing to match.
In effect you'll be deciding what strength is required for Kerberos
applications.

We can then evaluate whether we think that is reasonable.

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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 Mar 2005 15:31:45 -0500

> and would be an easy solution to the problem.

It is worth noting that at present, we mandate DH but not RSA, and the only 
DH group we mandate is group 2, which is a 1024-bit MODP group.  So, if we 
are going to try to meet the approach of matching the reply key size, we 
may need to mandate a larger group.

-- Jeff

---

From: Chaskiel M Grundman <[email-masked]>
Date: Fri, 18 Mar 2005 16:26:51 -0500

> and would be an easy solution to the problem.

What would it mean to 'mandate AES128'? Is the client going to be required 
to not send AES256 in the AS-REQ when using pkinit? Is the server going to 
be required to ignore requests for AES256 if the client does send them? Do 
either of those things make sense?

kerberos already has mismatched crypto strengths (even ignoring passwords): 
if my user key is 3des only, but the TGS has an AES256 key, I'm going to 
get a tgt where the ticket is protected with AES256 and where the key is 
protected with 3des in the AS-REP. How is the pkinit situation different?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 Mar 2005 16:59:43 -0500

On Friday, March 18, 2005 04:26:51 PM -0500 Chaskiel M Grundman 
<[email-masked]> wrote:

> What would it mean to 'mandate AES128'? Is the client going to be
> required to not send AES256 in the AS-REQ when using pkinit? Is the
> server going to be required to ignore requests for AES256 if the client
> does send them?

No, I don't think so.  It merely means that support for 
AES128-CTS-HMAC-SHA1-96 would be REQUIRED for implementations of PKINIT.

> kerberos already has mismatched crypto strengths (even ignoring
> passwords): if my user key is 3des only, but the TGS has an AES256 key,
> I'm going to get a tgt where the ticket is protected with AES256 and
> where the key is protected with 3des in the AS-REP. How is the pkinit
> situation different?

In the case you describe, the AES256 is the TGS's long-term key, which may 
have different (stricter) security requirements than the session key.  A 
more interesting question is, what is the session key in that ticket?  If 
the session key is also AES256, while the user's long-term key is 3DES, 
then I think you have a strength mismatch analogous to what happens in 
PKINIT if the reply key is stronger than the public key.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Fri, 18 Mar 2005 17:09:58 -0500

>>>>> "Chaskiel" == Chaskiel M Grundman <[email-masked]> writes:

    Chaskiel> --On Friday, March 18, 2005 14:43:13 -0500 Sam Hartman
    Chaskiel> <[email-masked]> 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.

--Sam