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(_at_)ietf(_dot_)org; ietf
Cc: Black, David; ietf-krb-wg(_at_)lists(_dot_)anl(_dot_)gov; 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(_dot_)black(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf