[kitten] Freshness Security Considerations for minimum/maximum size

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

[kitten] Freshness Security Considerations for minimum/maximum size

Michiko Short

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?


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 12/01/2016 12:55 PM, Michiko Short wrote:
> 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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Henry B Hotz
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 <[hidden email]> wrote:
>
>> 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.

Personal email.  [hidden email]



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Michiko Short
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:[hidden email]]
Sent: Thursday, December 1, 2016 1:08 PM
To: Greg Hudson <[hidden email]>
Cc: Michiko Short <[hidden email]>; [hidden email]
Subject: Re: [kitten] Freshness Security Considerations for minimum/maximum size

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 <[hidden email]> wrote:
>
>> 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.

Personal email.  [hidden email]



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten