Re: [secdir] Review of draft-ietf-httpauth-digest-15

[Rifaat Shekh-Yusef <[e-mail]>]

Hi Hilarie,

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

Regards,
 Rifaat


On Wed, Apr 8, 2015 at 7:04 PM, Hilarie Orman <[e-mail]>
wrote:

> 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.
>
>
Hmmm, did you miss section 5?




> 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.
>
>
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?



> "Also, IP address spoofing is not that hard." would be better stated
> 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.



> Page 5, "opaque" data string.  What is the minimum acceptable length?
> 16 bytes?  Maximum?  There should be a maximum.
>
>
Again, this is implementation dependent.



> 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)?
>
>
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
> be better to use HMAC than the concatenation shown.
>
>
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.



> 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."
>
>
Ok.



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



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



> 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))
>
>
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



> Hilarie
>