- From: Paul Leach <paulle@microsoft.com>
- Date: Fri, 23 Feb 96 13:40:45 PST
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, john@math.nwu.edu
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:
<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> + ":" + <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."
Paul
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