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

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Aug 2011 22:04:12 -0400

>>>>>   <[email-masked]> writes:

    > [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.

I definitely agree that we should use RFC 2119 language.
Note that WG participants have questioned this text in last call for
other reasons.
Many implementations use anonymous pkinit in a mode where the KDC's
certificate is verified--that is the client is anonymous but the KDC is
identified through a PKI.
WG participants believe (and I agree) that the security concern does not
apply at all in this case.
So, the text needs reworking.

    > [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.

Why should we require that alg-ids be registered URIs?  I.E. what is
wrong with me using
http://algorithms.painless-security.com/otp/best-thing-since-unsliced-bread
(or a tag URI if you like) for my OTP algorithm?
I have no problem with the IETF registering its algorithms there, or us
encouraging people to register them them, but it's a URI. What purpose
is served by forcing registration?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Thu, 25 Aug 2011 09:13:47 -0400

Hi Sam,

Thanks for the quick response?  I'll watch for the new text on anonymous PKINIT.

> 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.

> encouraging people to register them there, but it's a URI. What purpose

Hmm - more than one URI for the same algorithm might cause interoperability problems.

Thanks,
--David

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Wednesday, August 24, 2011 10:04 PM
> To: Black, David
> Cc: Richards, Gareth; [email-masked]; [email-masked]; [email-masked]; hartmans-
> [email-masked]; [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
>

---

From: <[email-masked]>
Date: Thu, 25 Aug 2011 09:20:37 -0400

Make that - Thanks for the quick response. (off-by-one key error ...)

Thanks,
--David

> From: Black, David
> Sent: Thursday, August 25, 2011 9:14 AM
> To: Sam Hartman
> Cc: Richards, Gareth; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Black, David
> Subject: RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
> 
> Hi Sam,
> 
> 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.
>

---

From: <[email-masked]>
Date: Wed, 24 Aug 2011 20:45:58 -0400

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.

   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
----------------------------------------------------

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 25 Aug 2011 16:22:50 -0700

> deal with an event-based token that is ahead of the server) would reduce the confusion.

Possibly there is something in RFC4226, section 7.4 which could be referenced or re-used?  It seems to assume that the server itself knows the token seed, which may not be a valid assumption, so perhaps not.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: <[email-masked]>
Date: Fri, 26 Aug 2011 06:55:36 -0400

> So, the text needs reworking.

I believe that the WG consensus here was that this security issue only applies if the identity of the KDC has not been verified.

How about the following updated version of the paragraph?

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

--Gareth

---

From: <[email-masked]>
Date: Fri, 26 Aug 2011 10:45:14 -0400

> Possibly there is something in RFC4226, section 7.4 which could be
> referenced or re-used?  It seems to assume that the server itself knows
> the token seed, which may not be a valid assumption, so perhaps not.

Resynchronization in the algorithms I am familiar with involves the server resetting its OTP search window and the system in the ID allows the client to send an additional value to help the server do this.  This is just as described in RFC4226.

How about the following clarification text:

Methods to recover from this type of situation are OTP algorithm specific but may involve the client sending a sequence of OTP
values to allow the server to further validate the correct position in its search window  (see section 7.4 of [RFC4226] for an example).

--Gareth

---

From: <[email-masked]>
Date: Fri, 26 Aug 2011 10:52:17 -0400

> Resynchronization in the algorithms I am familiar with involves the server resetting its OTP search
> window and the system in the ID allows the client to send an additional value to help the server do
> this.  This is just as described in RFC4226.
> 

That new text is fine.  My primary concern with the existing text is that the server has to do
something like this for all the cases except when the clock in a clock-based token is slightly
slow, but the existing text doesn't indicate that such server action may be needed.  The proposed
new text does so, and the reference to section 7.4 of RFC 4226 is a good addition that makes the
point clear.

Thanks,
--David

> From: Richards, Gareth
> Sent: Friday, August 26, 2011 10:45 AM
> To: [email-masked]
> Cc: Black, David; [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
> 
> >
> Resynchronization in the algorithms I am familiar with involves the server resetting its OTP search
> window and the system in the ID allows the client to send an additional value to help the server do
> this.  This is just as described in RFC4226.
>

---

From: <[email-masked]>
Date: Fri, 26 Aug 2011 10:43:57 -0400

>    before anonymous PKINIT is used with other algorithms such as those with short OTP

That works for me, as the use of "SHALL NOT" is clear and explicit.

Thanks,
--David

> Sent: Friday, August 26, 2011 6:56 AM
> To: [email-masked]; Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Fri, 26 Aug 2011 11:04:22 -0400

> 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.
>

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.

--Gareth

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 26 Aug 2011 17:48:15 +0200

<[email-masked]> writes:

> 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 think a separate registry is needed, RFC 6030 requires several things
from a profile that shouldn't be required in order to support Kerberos
OTP.  See below.

/Simon

12.4.  PSKC Algorithm Profile Registry

   IANA has created a registry for PSKC algorithm profiles in accordance
   with the principles set out in RFC 5226 [RFC5226].

   As part of this registry, IANA maintains the following information:

   Common Name:  The name by which the PSKC algorithm profile is
      generally referred.

   Class:  The type of PSKC algorithm profile registry entry being
      created, such as encryption, Message Authentication Code (MAC),
      One-Time Password (OTP), Digest.

   URI:  The URI to be used to identify the profile.

   Identifier Definition:  IANA will add a pointer to the specification
      containing information about the PSKC algorithm profile
      registration.

   Algorithm Definition:  A reference to the stable document in which
      the algorithm being used with the PSKC is defined.

   Registrant Contact:  Contact information about the party submitting
      the registration request.

   Deprecated:  TRUE if this entry has been deprecated based on expert
      approval and SHOULD not be used in any new implementations.
      Otherwise, FALSE.

   PSKC Profiling:  Information about PSKC XML elements and attributes
      being used (or not) with this specific profile of PSKC.

   PSKC algorithm profile identifier registrations are to be subject to
   Specification Required as per RFC 5226 [RFC5226].  Updates can be
   provided based on expert approval only.  Based on expert approval, it
   is possible to mark entries as "deprecated".  A designated expert
   will be appointed by the IESG.

   IANA has added two initial values to the registry based on the
   algorithm profiles described in Section 10.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Fri, 26 Aug 2011 11:58:55 -0400

Could we add a URI list to draft-lha-krb-wg-some-numbers-to-iana?

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 26 Aug 2011 20:20:54 -0700

Could we define a new section for the PSKC registry instead of a whole new registry?  (Agree we don't need all this info.)

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Aug 2011 09:58:03 -0400

>> 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?
    >> 

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.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Aug 2011 10:03:35 -0400

What information required by the PSC registry do we not need?
The only thing I see is the XML information, but it looks like that
could be blank.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 29 Aug 2011 10:16:58 -0700

I was thinking that if it's a proprietary OTP, we can still use it even if the algorithm is secret.  If we know we're getting a "clear text" OTP value and we have an (unspecified) method of verifying it against some external infrastructure, that's enough to use otp-preauth.

However I don't think this actually requires a complete registry.  A single undefined/external entry for the existing PSKC registry would be sufficient, wouldn't it?

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Aug 2011 16:26:50 -0400

>>>>> "Henry" == Henry B Hotz <[email-masked]> writes:

    Henry> I was thinking that if it's a proprietary OTP, we can still
    Henry> use it even if the algorithm is secret.  If we know we're
    Henry> getting a "clear text" OTP value and we have an (unspecified)
    Henry> method of verifying it against some external infrastructure,
    Henry> that's enough to use otp-preauth.  However I don't think this
    Henry> actually requires a complete registry.  A single
    Henry> undefined/external entry for the existing PSKC registry would
    Henry> be sufficient, wouldn't it?

It's exactly the proprietary OTPs where I think they should specify
their own URI in their own namespace.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Aug 2011 16:28:22 -0400

> Could we add a URI list to draft-lha-krb-wg-some-numbers-to-iana?

We could do that.  Doing so would be a very inefficient way of moving
the OTP document forward.  I'd recommend that we use an existing
registry.  If we cannot do that, we'll need to do the registry in the
OTP document.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg