Subject: Re: [Ietf-krb-wg] OTP preauth status

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Apr 2011 07:37:19 -0400

Hi.
The OTP preauth draft is now ready to go to the IESG.
Please do not issue any more updates without explicit direction from the
chairs.

Larry, do you still want to handle this, or should I take it over? This
is all about balancing chair load.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Linus Nordberg <[email-masked]>
Date: Fri, 22 Apr 2011 15:33:12 +0200

Sam Hartman <[email-masked]> wrote
Wed, 20 Apr 2011 07:37:19 -0400:

| The OTP preauth draft is now ready to go to the IESG.

Sorry for bringing up changes at this late stage.  The suggested changes
are language (p.7, p.20, p.24) or typos with more than one possible
resolution (p.16, p.18).

I have the following suggestions for changes to
draft-ietf-krb-wg-otp-preauth-16.

Page 7 (2.4.  Re-Synchronization)

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

  Would it make sense to say that the counter on the server is only
  incremented on a _successful_ authentication since increasing the
  counter on every try would open up for a de-synchronisation attack?

Page 16 (3.6.  Reply Key Generation)

  The initial hash is generated thus:

             H = hash(sname|nonce|OTP)

  but `sname' is not defined, but instead `realm' is defined.
  
  Renaming `sname' to `srealm' in both the formula and the definition
  or renaming `realm' to `sname' are two options for solving this.

Page 18 (4.1.  PA-OTP-CHALLENGE)

  The otp-keyInfo field is not marked OPTIONAL while the description
  (on page 19) states that it is optional.

  If the ASN.1 definition is changing, the same change would have to
  go into the definition on page 32 too.

Page 20 (4.1.  PA-OTP-CHALLENGE)

  Would it make sense (and be of any value) to rename the otp-keyID to
  otp-tokenID?  The word "key" makes me think of a secret key held by
  a physical token.  If keyID is already a well established word for
  this, please ignore this.

Page 24 (4.2.  PA-OTP-REQUEST)

  In the description of the otp-time field it's said that

    "Use of this element is OPTIONAL but it MAY be used by a client to
    simplify the OTP calculations of the KDC."

  The otp-counter field reads _almost_ the same, except that it says
  "calculation" instead of "calculation".

  The otp-format field lacks the final "calculation[s] of the KDC".

  If the clarification that it's on the KDC this will help, I suggest
  that all three fields says "simplify the OTP calculation on the
  KDC".  Note that I would like to change "of" to "on".  Perhaps "for"
  is a more correct preposition?  English is not my native language.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Apr 2011 22:53:23 -0400

>   counter on every try would open up for a de-synchronisation attack?

No; this language is descriptive and an example at that.  It describes a
problem created by the way tokens actually work, which we don't get to
change.

>   is a more correct preposition?  English is not my native language.

I agree; "on" and "for" are both reasonable choices, with slightly
different but appropriate meanings, while "of" seems... awkward.  That
said, this is the sort of change that should be fixed in editing, unless
some other reason arises for submitting a new version (still, there's
nothing wrong with pointing it out; if these are the worst problems
people have found, we're doing pretty well).

Speaking as an individual, I have no objection to the suggested changes
related to fixing the text in section 3.6 or adding the missing OPTIONAL
on otp-keyInfo.  I'm unclear on the exact semantics of otp-keyID, so
don't feel I can comment on that proposal.

-- Jeff

---

From: <[email-masked]>
Date: Tue, 26 Apr 2011 04:48:44 -0400

>   counter on every try would open up for a de-synchronisation attack?
This is just descriptive text and is not meant to describe the detailed workings of particular OTP methods.

>   or renaming `realm' to `sname' are two options for solving this.
I agree that this does look like an error.  The hashing was changed in V13 to use the Kerberos realm rather than the KDC's fully qualified domain name and so the text was changed but I forgot to edit the formula.  This should read

             H = hash(realm|nonce|OTP)

>   go into the definition on page 32 too.
The ASN.1 is correct, the otp-keyInfo is not optional in the PA-OTP-CHALLENGE (as described in section 3.2 on page 8).  It was originally optional but then the flags, supportedHashAlg and iterationCount elements were moved into the otp-KeyInfo from the parent PA-OTP-CHALLENGE requiring at least one of these elements to be included.  However, the text describing the element in section 4.1 was not updated correctly.  This should read:

   This element SHALL include a sequence of one or more otp-keyInfo objects
   containing information on the token or tokens that the user can use
   for the authentication and how the OTP value is to be generated using
   those tokens.  If a single otp-keyInfo element is included then only
   a single token is acceptable by the KDC and any OTP value generated
   by the client MUST be generated according to the information
   contained within that element.  If more than one otp-keyInfo element
   is included then the OTP value MUST be generated according to the
   information contained within one of those elements.

>   this, please ignore this.
The use of the word "key" came from the documents PKCS#11 origins where the tokens are represented by key objects.  Maybe you are right and otp-tokenInfo would be clearer.

>   is a more correct preposition?  English is not my native language.
This text is really just meant to state that the information may be used by the client to simplify the work carried out by the KDC.  Maybe the correct wording is "simplify the OTP calculations carried out by the KDC".

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Apr 2011 14:28:45 -0400

I'd prefer to have the hash formula correct when we go to IETF last
call.  If you can submit a new draft with the changes you enumareted in
your message to Linus and only these changes by Friday, please do so.

Thanks,

--Sam