Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

From: Peter Williams <[email-masked]>
Date: Tue, 23 Jan 2001 17:44:09 -0800

Steve,

Thanks for your comments on the usual viewpoint about nonces. Let me restate
what the standard that we profile asserts about "signed request/signed
response" 
authentication procedures. I separate each point, below, so that my comments
on 
your requirements formulation are clear.

X.509 advises that the rA (non-repeating number) generated by a UA, used to
detect 
replay attacks and prevent forgery, be used in the context of a tA, an
expiry date.

(tA, from X.511/518 is, semantically, the "expiry time for the validity of
the signature")

X.509 recommends that, it is reasonable for a party B (a server) to "store
the 
sequential part (rA) together with a timestamp tA in the clear and together
with 
the hashed part of the token, during time range tA."

The X.509 one-way AND two-way authentication procedures are a general case
of strong
authentication: there is nothing specific to use by the Directory. X.511/518
signed request/response PDUs are consistent with the X.509 recommendation,
and require servers supporting origin authentication of requests, to detect 
client replay attacks to PREVENT forgery. 

X.500 does not say what one should do, upon detection.... (I chose to return
the
official security error code of "Signature invalid" in civilian deployments,
and
official security error code "no-information" in the military
configuration.)

Should we not follow the recommendation of X.509, when formulating
the nonce/time elements of the strong authentication requirements,
for our request/response/chained-response chain-validation protocol?

Are the user's authentication requirements different to X.509? Do we wish to
accomplish more, or less, than "detect replay attacks and prevent forgery?"
by
exploiting strong authentication, for example?

If we wish to achieve the same objectives as specified for the strong
authentication
service in X.509, then surely we would have servers detect client nonce
replay within
the validity window of the signature of the request token. We would
similarly act
at the UA, for server nonce and response token. 

To do all this, one would need some kind of data store (e.g. hash tree) at
the 
server in order to  to be in compliance with the standard strong
authentication 
procedures, and thereby act "reasonably", as defined by X.509.

I hope you recognise my reasoning is nothing other than a restatement of or
or description of an implementation of, what X.509 drafts have recommended
to 
us since about 1986. 

Finally,

Does IETF have actual notice of timestamping patents that claim 
rights on a strong authentication-using server maintaining a store of 
anti-replay information? (The ITU disclosure database 
(http://www.itu.int/ITU-T/patent/files/13122000.pdf)
contains no notices, after 15 years, for X.509 other 
than the Entrust '431 disclosure.)

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Tuesday, January 23, 2001 3:29 PM
To: Peter Williams
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

At 11:52 AM -0800 1/22/01, Peter Williams wrote: 
Steve, 
Thank you for your memo. 
Let me summarize a requirement of your protocol design that seems to derive
from 
your comments: 
IETF-standardized validation servers MUST respond normally, when in
conforming mode, to a request that 
repeats an anti-replay, nonce value. 

Nonces are usually viewed as mechanisms employed by a client to detect
replays of responses. What you cite is a mechanism for a server to detect
and reject replays from a client, which is obviously quite different. (Maybe
it's just me, but I could not figure out what you were referring to in your
previous, cryptic message that you cite below.) It is contrary to many
server design notions, in that it requires maintaining state for each
client, to detect and reject reused nonces. Also, the client and server
might employ a lower layer protocol that would deal with this problem,
securely, obviating the need for such measures. But you do raise an
interesting point. 

So, in response to the question above, no, a server would not be required to
respond to a replayed request, nor would it be required to detect and reject
such a response. Unless we impose constraints on clients in their generation
of nonces, something that many protocols do not do, then a sender might
repeat a nonce due to inadequate, local PRNG capability. This would subject
the client to a replay attack, which we would like to prevent. However, do
we want to reject the request and deny the client service? Maybe that's a
good way to bring the error the the attention of the client. 

Steve 

Peter. 
-----Original Message----- 
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, January 15, 2001 7:41 PM 
To: Peter Williams 
Cc: [email-masked] 
Subject: RE: DPD & DPV requirements - to nonce or not to nonce? 

Peter, 

[Peter Williams] 

Not sure I see the need for the nonce hash tree you described, though it is
a clever approach, but it also might run afoul of the time stamp patents of
some folks. 

[Peter Williams] 

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Jan 2001 12:03:41 -0500

Peter,

Thanks for the tutorial. I didn't think that (many?) folks 
implemented the authentication protocols from the X.500 series 
recommendations you cited, so I have to admit to not having paid 
close attention to them. Looking at most of the other security 
protocols that make use of nonces, it seems that few other folks have 
paid close attention to these documents as well.

Now that I fully understand the context in which you referred to hash 
trees, I have to withdraw my concerns re possible intellectual 
property problems.  While we do know of patents on use of hash trees 
to deal with cert revocation, I don't know of any that would apply to 
the anti-replay feature you mention.

In my defense, I will say that if your messages were clearer, this 
sort of confusion would be less likely to arise.  For a native 
speaker of the English language, the level of obfuscation in your 
e-mail is amazing. You often write very concise, almost context-free 
sentences that I have trouble relating to the discussion at hand.

Steve