Subject: [kitten] Freshness Security Considerations for minimum/maximum size

From: Michiko Short <[email-masked]>
Date: Thu, 1 Dec 2016 17:55:34 +0000

We have concerns about the lack of guidance about size of the freshness token.

Minimum length

Problematic due to the fact that we intentionally did not specify the format of the freshness token.  Since the structure of the freshness token is left up to the KDC, there is no good way to determine a minimum size.  However, we can add to the security considerations:

Although we don't specify the format of the freshness token, there are a few size considerations based on if the following are used:

-          Nonce: Size is determined by the birthday problem.

-          Symmetric cryptography: Size is determined by properties of the encryption types supported.

-          Asymmetric cryptography: Size is determined by properties of the encryption types supported.

Maximum length
A maximum size makes sense as a way to avoid processing messages that are clearly bad.  Is there an accepted value for a worst case CMS signature?

---

From: Greg Hudson <[email-masked]>
Date: Thu, 1 Dec 2016 14:46:56 -0500

> Minimum length

I think we should add a third paragraph to security considerations saying:

If freshness tokens sent by the KDC are too short or too predictable, an
attacker may be able to defeat the mechanism by creating signatures
using every possible token value.  To prevent this attack, the freshness
token SHOULD contain a minimum of 64 unpredictable bits.

(I am willing to accept an amendment changing 64 to 96 or 128.  It's a
SHOULD, so it doesn't really constrain the implementation.)

> Maximum length

Saying anything about maximum lengths would be out of character for
Kerberos standards, I think.  I don't think we should specify a maximum
length.

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Thu, 1 Dec 2016 13:08:21 -0800

Mildly disagree. The point is to avoid processing bogus messages. I’d suggest a security consideration noting this issue and recommending that anything too big to match any supported encryption type should be summarily thrown away.

> On Dec 1, 2016, at 11:46 AM, Greg Hudson <[email-masked]> wrote:
> 
>> Maximum length
> 

Personal email.  [email-masked]

---

From: Michiko Short <[email-masked]>
Date: Fri, 16 Dec 2016 19:32:59 +0000

That could work on the KDC side. The client cannot. It does not know what is in the token or even have support for the etype that protects it.

-----Original Message-----
From: Henry B (Hank) Hotz, CISSP [mailto:[email-masked]] 
Sent: Thursday, December 1, 2016 1:08 PM
To: Greg Hudson <[email-masked]>
Cc: Michiko Short <[email-masked]>; [email-masked]
Subject: Re: [kitten] Freshness Security Considerations for minimum/maximum size

> Kerberos standards, I think.  I don't think we should specify a 
> maximum length.