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

Request Review of draft-ietf-kitten-pkinit-freshness
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-11-03
Requested 2016-10-22
Authors Michiko Short, Seth Moore, Paul Miller
Draft last updated 2016-12-12
Completed reviews Genart Last Call review of -07 by Russ Housley
Opsdir Last Call review of -07 by Scott Bradner
Assignment Reviewer Scott Bradner 
State Completed
Review review-ietf-kitten-pkinit-freshness-07-opsdir-lc-bradner-2016-12-12
Reviewed rev. 07
Review result Has Issues
Review completed: 2016-12-12


This is an OPS-DIR review of Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) 
Freshness Extension (draft-ietf-kitten-pkinit-freshness-07).

This ID describes PKINT systems that use Diffie-Hellman exchanging information to prove that the 
client actually has the correct private key.  This ID plugs a vulnerability in the PKINT use of Diffie-Hellman.

The client capable of using the new mechanism signals that fact to the server which can then test to be
 sure the client has the correct private key.

The mechanism described seems simple enough and generally is built on mechanisms already 
present in the PKINT specifications so should be easy to implement.

The added verification feature, by itself, presents no operational issues - anything that plugs 
vulnerabilities is to be applauded.

I do see an operational issue that is not covered in the ID.    It might help to add a section 
providing guidance in the case where a server operator wants to require use of the verification 
feature and a client does not support it. Is there an error the server can return that a human could 
use to figure out why an exchange fails?  In any case, some guidance as to what the server should
do in such a case could be helpful. 

If such a situation is to be avoided (configuring a server to require the feature) then discussing
that fact would be useful.