Re: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-10.txt

[Tony Hansen <[e-mail]>]

On 11/19/15 8:46 AM, Alexey Melnikov wrote:
> On 19/11/2015 13:43, [e-mail] wrote:
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-scram-auth/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-10
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-scram-auth-10
> This version fixes a few typos spotted by people, changes examples
> from using "host.com" to "example.com" (thank you Tony) and fixes more
> things in examples (again, thank you Tony).


I've been thinking about re-authentication and the question about having
a counter that changes to make each sr= unique. Unless I'm mistaken, I
THINK without it, what is there now could allow replay attacks and MITM
attacks.

It might be better to make sr= a base64-encoded block that includes both
the s-nonce and the i value. The s-nonce would be what was in the
earlier response, but uses a higher i= value, such as 4097, 4098, etc.
The i value is ALREADY a counter that can be used to make things unique.
And this should be easy for both sides to calculate because it can use
the earlier result and just do another round of hashing.

More nits below.

    Tony


I keep spotting little things

s/RFC 3174/RFC 6234/


   An the final server response contains data
   attribute which base64 decodes as follows:
to
   >>And<< the final server response contains >>a<< data
   attribute which base64 decodes as follows:

or preferably
   >>The<< final server response contains >>a<< data
   attribute which base64 decodes as follows:


I saw another "earlies" that should be "earlier".

Note: I >really< dislike www-authenticate's overuse of list syntax and
its comma separators.