One-Time Password (OTP) Pre-Authentication
RFC 6560

Note: This ballot was opened for revision 21 and is now closed.

(Stephen Farrell) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-10-04 for -)
No email
send info
I am ballotting "No Objection" on the basis of a light read and reliance on the Security COmmunity to have done adequate review.

Note that idnits shows an unused reference, RFC 5280. Please clean this up.

(Russ Housley) No Objection

(Pete Resnick) (was Discuss) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) (was Discuss) No Objection

Comment (2011-10-05)
No email
send info
It would be helpful to cite RFC 4120 regarding the definition of the
"nonce" production as a 32-bit integer (so as to avoid confusion about
comparison of nonces when authenticating the user) and to clarify the
exact nature of the nonce (e.g., Section 4.1 states "This nonce string 
MUST contain a randomly chosen component at least as long as the 
armor key length" whereas Section 4.2 states "This nonce string MUST 
be as long as the longest key length of the symmetric key types that the 
client supports and MUST be chosen randomly" -- the use of "string" here 
might be taken to imply that the nonce is not an integer, and the 
difference between "at least as long" in 4.1 and "as long" in 4.2 might 
cause confusion about the allowable length).

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2011-10-12)
No email
send info
Updated (added #18)

#1) s2.2: contains the following:

   The PA-OTP-CHALLENGE will contain a KDC generated nonce, an optional
   list of hash algorithm identifiers, an optional iteration count and
   optional information on how the OTP should be generated by the
   client.

Shouldn't "optional" be OPTIONAL x3.  I know it says it later, but it might not hurt to put it up here too.

#2) s2.2: It would also be good to say why this data is optional.  It says it later but putting it in the paragraph makes sense to me.  Something along the lines of:

   The optional information indicates how the OTP was generated.

#3) s3.2: Contains the following:

   This nonce string MUST
   contain a randomly chosen component at least as long as the armor key
   length.

You need to add the obligatory reference to RFC 4086 for randomness requirements.  There's also something like this in s3.3.  Maybe put a catch all in the security considerations.

#4) s3.3: Contains the following:

   In order to generate its response, the client must generate an OTP
   value.

r/must/MUST ?

#5) s4.1: contains the following:

   otp-tokenInfo
      This element SHALL include a sequence of one or more OTP-TOKENINFO
      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.

I think what you're tying to say is that this field MUST always be present and it is ... i.e.,:

      This element MUST be included and it is a sequence of one or
      more OTP-TOKENINFO ....

I don't know maybe that's just the way I'd write it.

#6) s4.1: Contains the following:

      The challenge is an optional
      octet string that SHOULD be uniquely generated for each request
      in which it is present.

r/optional/OPTIONAL to match the other fields.

#7) s4.1: I have to ask ay chance of using SHA-256?

#8) s4.1: Contains the following:

       This value MUST be present
       if and only if supportedHashAlg is present.

Maybe indicate that the iterationCount is OPTIONAL otherwise?

#9) s4.2: Missing a "," in the ASN.1:

        otp-pin        [6]  OCTET STRING                OPTIONAL

it's in the ASN.1 module.

#10) s4.2: Need to say that the field MUST always be included.

#11) s4.2: Should you indicate that the other flags aren't applicable? Or are they?

#12) s4.2: Maybe indicate that the nonce is OPTIONAL otherwise.

#13) s4.2: Indicate encData MUST always be included.

#14) s4.2: RFC 6030 includes the following choices for otp-format:

     DECIMAL:  Only numerical digits

     HEXADECIMAL:  Hexadecimal response

     ALPHANUMERIC:  All letters and numbers (case sensitive)

     BASE64:  Base-64 encoded, as defined in Section 4 of [RFC4648]

     BINARY:  Binary data

should Base64 be added to the list in this draft?

#15) s4.3: Should you indicate that the other flags aren't applicable? Or are they?

#16) s4.3: Indicate pin, minLength, maxLength, and last-req are OPTIONAL or MAY be included.  Mostly for consistency with other sections, but also because the text should match the ASN.1.

#17) s5: Just to make sure I'm following along: there are no otp-algs being registered right?  If there aren't then I think you can delete the 1st paragraph.

#18) To ensure automated matching of KDC-supplied and token-supplied otp-vendor, it might be useful to refer to registry for the value.