[Ietf-krb-wg] draft-ietf-krb-wg-otp-preauth-13 PROTO write-up comments

While preparing the PROTO write-up for draft-ietf-krb-wg-otp-preauth-13, I have the following comments:

1) Nits: Section 1.2 page 4, s/the standard Reply Key/the classic Reply Key (as defined in RFC4120)/. The word "standard" is overloaded in this context though the same phrase would sound perfectly fine anywhere else. This is just a suggestion and the same applies to the rest of my comments with regarding to the word "classic" vs "standard.
2) Nits: section 3.2 page 9, ditto s/standard/classic/.
3) Nits: section3.2, page 9, can you please upper case KDC in "kdc-authentication", as "KDC-authentication".
4) Grammar: section 3.2, page 9, s/PA-OTP-CHALLENGE that do not have the set the/ PA-OTP-CHALLENGE that do not have the/, i.e. extra "the set" seems to be just a copy&paste error.
5) Nits: section 3.3 page 11, at the very end, s/if the algorithm identifiers do not conform/if none of the algorithm identifiers conforms/.
6) Section 3.4, page 13. If kdc-authentication is required then a PA-OTP-REQUEST containing an otp-value must be rejected. This discusses the KDC side of verifying the preauth-data, how does the KDC know if KDC-authentication is required. Isn't that KDC-authentication is a client side thing?
7) Nits: section 3.4, page 14, s/standard encrypted timestamp/classic encrypted timestamp/.
8) Section 3.4, page 14, the expiration time of the OTP account. This text introduces a new concept "OTP account". Does this imply a separate life-time management is required or recommended for OTP usage? Can you please clarify?
9) Section 3.4, page 14, the current text says "it SHOULD return the same response as for a non-OTP expired password", first, what does it mean by "non-OTP expired password", does it imply there may exist an OTP expired password, secondly, and is it intentional that the KDC is not returning KDC_ERR_PIN_EXPIRED in this case?
10) Section 4.1,page 30,  for consistency please add a ',' at the end of "-pin-not-required(4)'.
11) Section 4.1, page 18, s/both flags MUST NOT be set and the client MUST regard/ both flags MUST NOT be set, or the client MUST regard/.
12) Section 4.3, page 23, for consistency, please remove the comma at the end of "-mandatory(2)," so that it looks like "--mandatory(2)" .
13) Section 6.1, this section explains MITM can choose the session key when anonymous PKINIT is used. That is no longer true with anonymity draft 12 (the latest). Can this be updated? I believe Sam raised this issue during the last WGLC on -12. Can you please summarize the discussion and the conclusion?
14) Grammar: appendix b4, s/The Client generates Client Key Reply Key as described in/ The Client generates the Client Key and the Reply Key as described in/
15) Appendix b4, page 39, s/proceed as with the standard sequence/proceed as with the classic sequence as defined in RFC4120/.
16) Section 2.3, on top of page 7,  "as described above". I believe what was described above was removed. You can say "similarly as illustrated in RFC3244" and add a non-normative reference to RFC3244.
17) I have the opinion that the reference to PKINIT and anonymity draft should be normative. Do you have good reasons otherwise?
18) Section 3.6, page 16, the current text says that "the salt SHALL be the default salt for the principal requested in the AS-REQ". I do not think "default salt for the principal" is defined in existing standards or in this document. I can see a few possibilities to address this issue. A) we might need to have a protocol change, for example, we can add the optional "salt" field of KerberosString type in the OTP challenge message and allow the client to retry if it got it wrong when the two-pass variant; B) you can simply say that the salt is an empty string if the OTP value is already salted when computed from a secret; C) go back to draft 12 and I do agree that approach in -12 can create an unnecessary pain point. 
19) draft-ietf-keyprov-pskc has been published as RFC 6030.
20) I was able to compile the ASN module in appendix A except the latest 3 lines before the "end", ignoring the blank line right before that. Can you please confirm this module passes a modern ASN1 compiler?

Draft 13 contains significant changes from draft 12 mostly due to WGLC comments. The quality of the document has been significantly improved. Out of these, issue 18 must be addressed before the document can move forward but overall the document is very close. In order to allow the document progress quickly, I just started another WGLC on 13 together with these comments. Taking into account of the holidays at this time of the year, I have extended the last call to cover 3 weeks instead of the normal 2 week length.

Thanks,
--Larry

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg@lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg