Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-krb-wg-otp-preauth-18
Reviewer: David L. Black
Review Date: August 24, 2011
IETF LC End Date: August 29, 2011

Summary: This draft is on the right track but has open issues, described in the review.

This is a tightly written draft on one-time-password token-based preauthentication for Kerberos.
The text does a good job of tightly specifying the algorithms and protocol steps; the resulting
text is a bit dense to read, but provides the necessary precision for implementation.

Disclaimer - the draft author and this reviewer work for different organizations in the
	same company (EMC).

I found two open issues, both of which are relatively minor:

[1] In section 6.1 at the top of p.28, I don't believe that the use of lower case
"recommended" is a strong enough warning about the danger in using
anonymous PKINIT because it exposes the OTP value:

   It is therefore recommended that anonymous PKINIT not be used with
   OTP algorithms that require the OTP value to be sent to the KDC and
   that careful consideration be made of the security implications
   before it is used with other algorithms such as those with short OTP
   values.

At a minimum, that warning should be in upper-case:

   It is therefore RECOMMENDED that anonymous PKINIT not be used with
   OTP algorithms that require the OTP value to be sent to the KDC. In
   addition, the security implications should be carefully considered
   before anonymous PKINIT is used with other algorithms such as those
   with short OTP values.

Beyond that, the security issue in the first sentence may be severe enough
to justify a prohibition, so the following would also be acceptable:

   Therefore anonymous PKINIT SHALL NOT be used with
   OTP algorithms that require the OTP value to be sent to the KDC. In
   addition, the security implications should be carefully considered
   before anonymous PKINIT is used with other algorithms such as those
   with short OTP values.

[2] In section 5, the first paragraph in the IANA considerations is unclear, and
following its reference to section 4.1, I don't see any clarifying text there either.
I think Sections 4.1 and 4.2 need to say that the value of otp-algID is a URI obtained
from the PSKC Algorithm URI Registry, and the first paragraph in section 5 should
say that URIs for otp-algID are to be registered in that registry, see RFC 6030.

I also found a couple of minor nits:

In Section 1.1, please expand the FAST acronym on first use.

In section 2.4, the following sentence is potentially confusing:

   For example,
   event-based tokens may drift since the counter on the token is
   incremented every time the token is used but the counter on the
   server is only incremented on an authentication.  Similarly, the
   clocks on time-based tokens may drift.

The confusion arises because the resync mechanism described in that section causes
the client to use the next token value.  By itself, that won't help when an event based
has gotten ahead of the server; using the next value only puts the token further ahead.
Similarly, by itself, this mechanism does not help if the token clock has drifted ahead
of the server clock, but does help if the token clock has drifted behind.  A little more
explanation of what the server can do to take advantage of this mechanism (e.g., how to
deal with an event-based token that is ahead of the server) would reduce the confusion.

idnits 2.12.12 generated a bunch of warnings, none of which require any change to the draft.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@xxxxxxx        Mobile: +1 (978) 394-7754
----------------------------------------------------


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]