Skip to main content

Last Call Review of draft-ietf-kitten-pkinit-freshness-07
review-ietf-kitten-pkinit-freshness-07-opsdir-lc-bradner-2016-12-12-00

Request Review of draft-ietf-kitten-pkinit-freshness
Requested revision 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
I-D last updated 2016-12-12
Completed reviews Genart Last Call review of -07 by Russ Housley
Opsdir Last Call review of -07 by Scott O. Bradner
Assignment Reviewer Scott O. Bradner
State Completed
Request Last Call review on draft-ietf-kitten-pkinit-freshness by Ops Directorate Assigned
Reviewed revision 07
Result Has issues
Completed 2016-12-12
review-ietf-kitten-pkinit-freshness-07-opsdir-lc-bradner-2016-12-12-00
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.

Scott