RE: Digest Auth defending against replay

On Saturday, February 24, 1996 8:20AM, John suggested "one-time 
response digests".

] I think I may have a solution to the "nonce incrementing" issue. This is
] really the issue of how to defend against replay attacks efficiently.
]
] My suggestion is to forget one-time nonces and use one-time
] response digests.  In other words, instead of keeping hashes of
] previously used nonces the server may keep hashes of previously
] used response digests (or response digest + message digest if message
] digest is present).  If the server detects a previously used digest
] it will request re-authentication with a new nonce using the stale
] nonce field.

It didn't dawn on me until you made this latest suggestion, but the
recommended nonce includes the URI of the requested entity.
This will require a at least one challenge for each document requested.
This latest suggestion achieves that lower bound.

However: incrementing nonces only require one challenge per *session*,
which is much more efficient, especially for long sessions. (This won't
matter for sites where most information doesn't require authentication,
but subscription based sites are an important case that lots of people
want to support and  they would have almost all pages be authenticated
if it were cheap enough.)

Note that the 1.1 spec says that a client can include the Authorization:
header without having been challenged, and that this is current practice
with Basic authentication -- after being challenged by a site the browser
includes the Authorization: header in all subsequent requests, and this
usually results in no further challenges.  If we want Digest
authentication to be as message efficient as Basic (an achievable goal),
then either the URI can't be in the nonce, or the client needs to know
that the URI is in the nonce, and change the nonce with each request.
(Besides which, the URI is already in the digest as part of H(A2), so
putting it in the nonce doesn't add anything.)

When using persistent connections, the next expected nonce on that
connection can be kept in a per-connection data structure (which
the server probably already has and where the authenticated user
name would also be kept), and directly accessed, without the
overhead of a hash table.

Lastly, incrementing nonces are compatible with all existing
implementations. A server that wasn't expecting the (new) client
to modify the nonce will fail to authenticate and reissue the
challenge. (A clever client could even notice this and stop
incrementing the nonce after a couple of challenges to see if that helped.)

Paul

Updated proposed text for <nonce>:

 <nonce>
         A server-specified data string which may be uniquely generated each
         time a 401 response is made.  It is recommended that this string be
         base64 or hexadecimal data.  Specifically, since the string is passed
         in the header lines as a quoted string, the double-quote character
         is not allowed.

         The contents of the nonce is implementation dependent.  But the
         quality of the implementation depends on a good choice.  A
         recommended nonce would be

	 H(<client IP> + ":" + <private key>) + <sequence>

         Where <client IP> is the dotted quad IP address of the client
         making the request, <private key> is data known only to the 
server, and
         <sequence> is a  16 bit sequence number, which the client is strongly
	 encouraged to increment after each use to prevent replay (but does not
	 have to, for backwards compatibility).

         The nonce is opaque to the client, except for its assumption that
	 the sequence number is the last 16 bits.

Received on Monday, 26 February 1996 11:30:33 UTC