Last Call Review of draft-ietf-httpauth-digest-15
review-ietf-httpauth-digest-15-secdir-lc-orman-2015-04-09-00

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