RE: New draft for Digest Authentication

John said-

] In light of the recent discussion in this group I want to make some
] additional comments.  I have not added "nonce icrementing" to the
] draft and I personally am not in favor of such a change.  Here are my
] reasons:
] 1) Nonce incrementing, does not in any way strengthen the security of
] digest authentication over the use of one-time nonces. One-time nonces
] are consistent with, and suggested in, the current and past
] specifications.  The only advantage of nonce incrementing would be a
] small efficiency improvement.

It isn't small. It's an extra round trip on every authenticated 
request. And every request SHOULD be authenticated. Making the extra 
security be unnecessarily expensive will only lead to it not being used.

The trivial change I outlined in a previous post (reproduced below) 
will make it possible for every request to be authenticated at no extra cost.

] 2) Nonce incrementing breaks current implementations.

No it doesn't, as my previous mail explained. Reproduced below.

] Making it
] optional to maintain backwards compatibility would make it useless for
] security as any attacker would simply use the old version of the
] protocol.

No it doesn't. An existing client that doesn't send in an incremented 
nonce will get a new challenge with a new nonce. Ditto for an attacker.

] 3) HTTP is, in general, a "stateless" protocol.  Incorporating nonce
] incrementing makes it "stateful."  Many people will strongly oppose
] this change.  If you want to debate whether statelessness is a
] desirable design goal for HTTP, or whether the maintaining of state
] can be done efficiently for nonce incrementing I hope you will find
] another forum.  I am simply reporting a historical fact that many
] people want to keep HTTP a stateless protocol.  I am aware that one-time
] nonces (advocated above) and many CGI applications require maintaining
] state.  The difference is that these are implementation decisions, not
] part of the protocol and, in particular, the protocol does not
] *require* the server to keep state information across connections.

Two comments on this one:
a. Servers aren't required to implement incrementing nonces. Any server 
that wants to remain purely stateless can.
b. Servers that do implement it can discard the state at any time, as 
equivalent state can be reacquired at the cost of a challenge. Hence, 
such a server is not stateful in the sense that server writers usually 
object to, where they can get clogged with state that they MUST 
maintain in order to conform to the protocol.

I would like to see the <nonce> section changed to:

         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> + ":" + <timestamp> + ":" + <private key> + ":" + 
<uri>) + <sequence16>

         Where <client IP> is the dotted quad IP address of the client
         making the request, <timestamp> is a server time value,
         <private key> is data known only to the server, <uri> is
         the requested URI, and <sequence16> is a 16 bit sequence number.
 	 Clients are encouraged to increment the sequence number after each use,
	 which will always be the last 16 bits of the nonce if present.
  	 The timestamp can be used to expire nonces, and the sequence number can
	 be used to prevent replays.
         Instead of using a timestamp the implementation might choose
         never to reuse nonce values.  Or, an implementation might choose
         to use one-time nonces for POST or PUT requests and a timestamp
         for GET requests.

         The nonce is opaque to the client, except for the <sequence16>,
	 which the client may assume is the last 16 bits of the nonce, and
	 is strongly encouraged to increment.

There are four sentences changed:
added: "<sequence16>" to the recommended nonce
added: "<sequence16> is a 16 bit sequence number" to the desciption of 
the nonce fields
added: "and the sequence number can be used to prevent replays."
added: "except for the <sequence16>, which the client may assume is the 
last 16 bits of the nonce, and is strongly encouraged to increment."


Let me try to reduce this to the bare minimum.
All I want to do to the spec is add one little thing -- say that the 
low order 4 digits of the nonce are a counter modulo 10^n, and that 
client is highly encouraged to increment it after each use (but, for 
backward compatibility, doesn't have to).

Let's look at the ramifications of such a change:

Servers that don't want to rememeber nonces wouldn't have to. They 
wouldn't even have to change. When the response arrives, they would compute
	H(H(A1) + ':' + N + ":" + H(A2))
from info in the incoming request and the server's knowledge ot the 
paswword ,just as they now do, and if it maches the digest in the 
"response=", then the request is authenticated. If it happens not to 
check, then the worst that will happen is a challenge.

Old clients, that don't increment the nonce, will continue to work (by 
the same reasoning) with old servers that don't care about replay, and 
will just generate a challenge on each request from servers that do.

New clients, that increment the nonce, will work with old servers, new 
servers that don't remember the nonce, and efficiently with new servers 
that demand the nonce not be reused.

Net net: it's not an implementation change unless increased security is 
desired; it's a spec change to say that part of the nonce is not opaque 
(and to describe how one could efficiently get increased security..).

Received on Friday, 23 February 1996 13:40:26 UTC