The -19 version of this draft resolves the issues raised by the Gen-ART review of the -18 version, although issue [2] on registering the URIs has a couple of nits: - IANA also found issue [2] and IANA will need to acknowledge that the -19 version of this draft resolves this registration issue to IANA's satisfaction (the text in the -19 version should be sufficient). - It is unclear to me whether the PSKC registry used to resolve issue [2] is appropriate, but this topic has been discussed in the WG, and hence I prefer to defer this topic to the WG and the responsible Security AD. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Wednesday, August 24, 2011 8:46 PM > To: Richards, Gareth; gen-art@xxxxxxxx; ietf > Cc: Black, David; ietf-krb-wg@xxxxxxxxxxxxx; Sam Hartman; Stephen Farrell > Subject: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 > > 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