One thing to note, since the client will never know what the KDC is using size
will not impact the error or AS-REQ processing unless we can declare a
universal min and max. It can be used by the KDC since it will know if nonce,
sym crypto or asym crypto. So the example that Russ provided was client
behavior which would not be impacted. However, the KDCs can use this
information to fail the Freshness token validation before cracking open the
From: Michiko Short [mailto:michi...@microsoft.com]
Sent: Thursday, December 1, 2016 9:33 AM
To: Jari Arkko <jari.ar...@piuha.net>; Benjamin Kaduk <ka...@mit.edu>
Cc: Paul Miller (NT) <pau...@microsoft.com>; IETF Gen-ART <firstname.lastname@example.org>;
Subject: RE: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07
Ok, since answer not obvious starting thread on Kitten.
From: Jari Arkko [mailto:jari.ar...@piuha.net]
Sent: Thursday, December 1, 2016 1:30 AM
To: Benjamin Kaduk <ka...@mit.edu>
Cc: Paul Miller (NT) <pau...@microsoft.com>; Michiko Short
<michi...@microsoft.com>; IETF Gen-ART <email@example.com>;
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07
Many thanks for your review, Russ, and for thinking about this space and what
issues there might be.
I too am concerned about the issue that Russ Housley raised: bad practices in
creating the freshness tokens creates a security issue. If this cannot be
handled in the way that Russ initially suggested (setting a minimum number of
bits) then a proper discussion of the issue and recommendations to avoid the
problems need to be included in the security considerations section.
I fully recognise the point from the authors that different styles of creating
the tokens result in different implications, and that setting a mere minimum
number of bits may not be appropriate.
Gen-art mailing list