Security review of OTP Pre-authentication, draft-ietf-krb-wg-otp-preauth-18 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines how to use "one-time passwords" with Kerberos pre-authentication, over a secure tunnel between the client and the key distribution center (the KDC). A secure tunnel mechanism called "FAST", the subject a Crypto eprint paper and another Kerberos RFC, defines the use of cryptography. The OTP system uses its FAST key as part of generating its own one-time keys, and this combination is meant to protect against man-in-the-middle attacks. Although this document seems is in almost all respects well-written, it is difficult to review because of nesting depths of RFCs on which it relies, and because of the "ifs". The narrative description of the protocol has so many "ifs" that it is difficult to keep track of them. There are approximately 100 conditionals. Diagrams might be helpful. The protocol security relies directly on the ability to decrypt a nonce. A nonce sent by the challenging part must be encrypted by the responder using a one-time key that both parties can computer from their shared state. The challenger decrypts and compares to the nonce. This is something that Needham's "prudent principles" warns against, and in this case I cannot discount the advice. This is because the document does not supply exact definitions of cipher functions. Instead, it relies on generic elements of the cipher suite. The key derivation function ultimately depends on the "random-to-key" function of the cipher suite, but even finding this information involves looking at other RFCs and doing Google searches. So, it is difficult to review the security in general, and I cannot dissuade myself from thinking, even after reading the well-done security considerations section, that the authentication method might have flaws. The devil is in the details and the details are generic. In "2.3. PIN Change", we read "Most OTP tokens involve the use of a PIN in the generation of the OTP value." Is there a reference for a common OTP system that uses PINs? An editorial comment about the security consideration re "remaining entropy" ... this is really an issue about secrecy, not information theory, and I would call it "secret information". Reference to "Cryptology ePrint Archive" should include a URL for the archive, which is a service of the IACR (www.iacr.org). Hilarie