Security review of HTTP Digest Access Authentication draft-ietf-httpauth-digest-15 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. HTTP authentication can be done via username and password. This document defines two hash function based methods for sending a binding between the password, username, and other information. The password can be verified on a server by checking the hash using the recorded password and the current information. The method defines the use of newer hash functions but keeps backwards compatibility with MD5. "Section 3.1 Overall Operation .... The security of this protocol is critically dependent on the randomness of the randomly chosen parameters, such as client and server nonces. These should be generated by a strong random or properly seeded pseudorandom source (see [RFC4086])." The above seems to be something that should go into the noticeably absent "Security Considerations" section. Page 5, discussions the "nonce". The "secret-data" is what requires the high-quality randomness mentioned in section 3.1. This should be explicitly noted. There should be some guidance on the minimum acceptable length of the secret-data ... 128 bits seems reasonable to me. The maximum length should also be specified, and I would recommend that it be no more than 512 bits at most. I would further recommend that the secret data be generated explicitly for digest authentication and not copied from some other random value used by the server for other security purposes. Further, the "secret-data" should be changed periodically, not just on server restart. "Also, IP address spoofing is not that hard." would be better stated as "Source IP addresses are no guarantee of end-to-end integrity." Page 5, "opaque" data string. What is the minimum acceptable length? 16 bytes? Maximum? There should be a maximum. Page 6 " algorithm A string indicating a pair of algorithms used to produce the digest and a checksum. If this is not present it is assumed to be "MD5". " How is "MD5" a pair of algorithms? Is "MD5,MD5" a pair? Or is the there actually a single algorithm that will be used in two ways (keyed and unkeyed digest)? It would be helpful to note that "KD" means "Keyed digest". It would be better to use HMAC than the concatenation shown. Rather than "checksum", it would be more appropriate to say "digest" or "unkeyed digest". E.g, "to produce a keyed digest and an unkeyed digest." Page 8, what is the minimum acceptable length for cnonce? Maximum length? Page 10, "cnounce" should be "cnonce". I would recommend that the keyed digest be done in the following way: K = H(password) C = concatenation of a bunch of non-secret stuff KD(K, C) = HMAC(K, C) = H(K, H(K, C)) For the H-ness calculations, C' = unq(username) ":" unq(realm) ":" unq(nonce-prime) ":" unq(cnonce-prime) A1 = HMAC(K, C') and then KD ( A1, C ) = HMAC(A1, C) = H(A2, H(A1, C)) Hilarie