Skip to main content

Last Call Review of draft-ietf-kitten-pkinit-freshness-07

Request Review of draft-ietf-kitten-pkinit-freshness
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-11-03
Requested 2016-10-20
Authors Michiko Short , Seth Moore , Paul Miller
I-D last updated 2016-12-01
Completed reviews Genart Last Call review of -07 by Russ Housley
Opsdir Last Call review of -07 by Scott O. Bradner
Assignment Reviewer Russ Housley
State Completed
Request Last Call review on draft-ietf-kitten-pkinit-freshness by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07
Result Almost ready
Completed 2016-12-01
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

Document: draft-ietf-kitten-pkinit-freshness-07
Reviewer: Russ Housley
Review Date: 2016-11-27
IETF LC End Date: 2016-11-03
IESG Telechat date: 2016-12-01

Summary: Almost Ready

Major Concerns

I understand that freshness tokens provide corroboration that the
client had access to the private key at the time that the AS-REQ
was constructed.  I also understand that the freshness tokens do not
have to be single use tokens for specific AS exchanges.  However,
some guidance on the minimum size of the freshness token seems to be
appropriate.  If the freshness token is too small, then the client
could be generate signatures using all of the possible token values
at when it does have access to the private key, offering the one that
matches the freshness token during the exchange with the KDC.  Please
specify a minimum size for the freshness token.

Please add a discussion of the minimum freshness token size to
Section 7 (Security Considerations).

Question: Is there a reson to specify a maximum size for the freshness
token?  If an implementor knows that the freshness token will be under
some maximum, then the code can incorporate that information into the
buffer management and easily discard any KRB-ERROR messages that exceed
that maximum.

Minor Concerns

In the Abstract and Section 1 (Introduction), please spell out KDC the
first time the acronym is used.

In Section 2.2 (Generation of KRB_ERROR Message), please give the reader
a heads up that PA_AS_FRESHNESS is defined in this document.  I went
looking for it in RFC 4120; a pointer could have avoided this wild goose


In Figure 1, since the client begins the conversation, it would read
better if the Client were on the left side of the figure.