Subject: [http-auth] Review of draft-ietf-httpauth-digest-15

From: "Hilarie Orman" <[email-masked]>
Date: Wed, 8 Apr 2015 17:04:08 -0600

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

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 8 Apr 2015 20:56:39 -0400

Hi Hilarie,

Thanks for your review and comments.
Please, see my reply inline...

Regards,
 Rifaat

> absent "Security Considerations" section.
Hmmm, did you miss section 5?

> "secret-data" should be changed periodically, not just on server
The document explicitly states that "The contents of the nonce are
implementation dependent".
The text was copied from RFC2617, and unless there is a good chance that
people would be interested in implementing these new ideas, I would rather
we keep it as is.
Also, can you explain why do you recommend 128 bits as minimum and 512 bits
as maximum?

> as "Source IP addresses are no guarantee of end-to-end integrity."
Well, the existing text at least states why you should not rely on IP
address. With your proposed text, you state something but do not explain
what is that the case.

> 16 bytes?  Maximum?  There should be a maximum.
Again, this is implementation dependent.

> there actually a single algorithm that will be used in two ways (keyed
This is the way it was stated in RFC2617. It is the same algorithm used to
hash different things. I will fix it.

> It would be helpful to note that "KD" means "Keyed digest".

Ok.

> It would
Yeah, as I mentioned in a response to a previous review, and I would be
happy to do that if there is interest and support for adding HMAC support.

> or "unkeyed digest".  E.g, "to produce a keyed digest and an unkeyed
Ok.

> Page 8, what is the minimum acceptable length for cnonce?  Maximum length?
This is implementation dependent.

> Page 10, "cnounce" should be "cnonce".
Ok

>  KD ( A1, C ) = HMAC(A1, C) = H(A2, H(A1, C))
Let's first see if there is support for the idea of adding HMAC support;
after that we will deal with these details.

Regards,
 Rifaat