One-Time Password (OTP) Pre-Authentication
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 -)
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
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
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  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.