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; [email protected]; ietf
> Cc: Black, David; [email protected]; 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
> [email protected] Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
