Subject: Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

From: <[email-masked]>
Date: Fri, 2 Sep 2011 10:50:48 -0400

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: 29 August 2011 14:58
> To: Richards, Gareth
> Cc: Black, David; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
> 
> >>>>>   <[email-masked]> writes:
> 
>     >> > Why should we require that alg-ids be registered URIs?
>     >>
>     >> That's not my concern - the existing first paragraph of the IANA
>     >> considerations section in the draft requires IANA registration
>     >> (or at least tries to) by pointing to the PSKC registry.  My
>     >> concern is that if this is going to be done, it needs to be done
>     >> right (duh!), and the current text is insufficient. Please take
>     >> the issue of whether to use IANA for this purpose up with Gareth
>     >> and the WG.
>     >>
>     >> > I have no problem with the IETF registering its algorithms
>     >> there, or us > encouraging people to register them there, but
>     >> it's a URI. What purpose > is served by forcing registration?
>     >>
>     >> Hmm - more than one URI for the same algorithm might cause
>     >> interoperability problems.
>     >>
> 
> g>Some form of identifier will be required for the otp-algID in the PA-
> OTP-CHALLENGE and the PA-OTP-REQUEST and from what I remember about
> when this was first discussed, it was agreed that it would make sense
> to use the registry of identifiers already being established for PSKC
> rather than produce a duplicate one.  My assumption was that a registry
> would be required to ensure that the URIs were unique.
> 
> I don't really care so just fix the current text to resolve David's
> concern.  My point was simply that whatever spec tells you how to use
> some algorithm with Kerberos can provide a unique URI and I'm
> unconvinced that it matters where that URI is drawn so long as everyone
> agrees on the URI.  Having a registry for everything the IETF does is
> fine; reusing an existing registry is better.  Constraining what
> non-IETF people do seems kind of silly but they will not listen to us
> anyway, so no harm is done.

How about the following text?  I am not sure whether to make these SHOULDs rather than MUSTs to allow the option of other algorithm identifiers to be used.

a) Section 4.1:

      otp-algID
         Use of this field is OPTIONAL, but MAY be used by the KDC to
         identify the algorithm to use when generating the OTP.  URIs
         used in this section SHOULD be obtained from the PSKC algorithm
         registry [RFC6030].

b) Section 4.2

   otp-algID
      This field MAY be used by the client to send the identifier of the
      OTP algorithm used, as reported by the OTP token.  Use of this
      element is OPTIONAL but it MAY be used by the client to simplify
      the OTP calculations carried out by the KDC.  It is RECOMMENDED
      that the KDC act upon this value if it is present in the request
      and it is capable of using it in the generation of the OTP value.
      URIs used in this section SHOULD be obtained from the PSKC algorithm
      registry [RFC6030].

c) Section 5

   The OTP algorithm identifiers used as otp-algID values in 
   the PA-OTP-CHALLENGE described in section 4.1 and the PA-OTP-REQUEST 
   described in section 4.2 SHOULD be registered in the PSKC algorithm
   registry [RFC6030].

--Gareth

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Fri, 2 Sep 2011 12:48:53 -0400

> How about the following text?  I am not sure whether to make these
> SHOULDs rather than MUSTs to allow the option of other algorithm
> identifiers to be used.
>
> a) Section 4.1:
>
>       otp-algID

I just realized that the what I said above might not have been clear.

I wasn't totally sure whether the text should contain MUSTs rather than SHOULDs.  The suggested text currently has SHOULDs to allow the for the case of OTP systems not registered with IANA being used within Kerberos.

--Gareth

---

From: <[email-masked]>
Date: Thu, 15 Sep 2011 18:18:38 -0400

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

> From: Black, David
> Sent: Wednesday, August 24, 2011 8:46 PM
> To: Richards, Gareth; [email-masked]; ietf
> Cc: Black, David; [email-masked]; 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-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>