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

From: "Covey, Carlin" <[email-masked]>
Date: Mon, 15 Jan 2001 12:33:46 -0800

Thanks Peter, that was very informative.  I guess keeping track of used
nonces, while not fun,
can be fairly time-efficient.  
 
If you are keeping track of nonces as supporting evidence for
non-repudiation, don't you have
to keep the requests around, as well as the responses?  But these requests
would not be very 
convincing evidence unless they were signed by the client.  Would the server
refuse to reply to 
unsigned requests?  Would the server refuse to respond to a request that
included a reused
nonce?
 
If you had a choice, would nonces be your first choice for a replay
countermeasure?
 
Regards,
Carlin
 
_______________________
- Carlin Covey
  Cylink Corp.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Monday, January 15, 2001 12:31 PM
To: Covey, Carlin
Cc: PKIX-List
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

X.511 enables signed requests and signed responses to be linked by nonce
values. X.500 however had no
clear statements about nonce handling. I implemented an online responder for
certificates status
values using X.511 signed request/response pairs several years ago. I
maintained at the server a 
hash-tree of nonce values provided to, and generated by the server, and
checked that a nonce value 
was not repeated in a certain period. As X.500 operations are rather more
complex than simple OCSP, requiring support for multicasting, result
reconstruction/resigning and n-level chaining of operations 
between master and slave servers, the issues of nonces seemed important
beyond merely the issue of linking one request to the initiating servers
response to thwart replay. The party who generates
the information element in the response may not be the party that provides
it (once resigned) to the 
relying party. The nonce value says nothing about the timeliness of the
information, only the issuing
time of the signed response PDU; the source of response data, under X.500
reconstruction rules
may be cached data held by the server as a slave or replicate of a master
DSA responsible
for the status-data DIB. (*)
 
Today, for NR reasons, Id use a hash-tree (just like CRTs!) that is
persistent and stored as part 
of the NR records showing the proper conduct of the server when acting for
the relying party. The thing
that has changed in 10 years is the realization that the server is really
the agent of the
relying party: its not a frontend of the CA. The server now needs to ensure
that it
can show it fulfilled its obligations under the relying party
agreement/policy.
 
(*) Careful configuration of multi-mastering replication, to assure the
relying-party that cache
attacks are not in place, is used to address this in modern X.500 versions,
btw)

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, January 04, 2001 6:37 AM
To: Covey, Carlin
Cc: PKIX-List
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

At 5:21 PM -0800 1/3/01, Covey, Carlin wrote: 

To thwart replay attacks, both OCSP and SCVP have provisions for the
optional inclusion of nonces in requests and responses . 

The premise of this is that the requester picks a nonce that it hasn't used
before, and includes it in its request. 

The server is obligated to return this same nonce, ensuring that the
response was prepared after the request. 

I don't see a provision in the proposed DPD and DPV requirements for the
optional inclusion of a nonce. 

Is this an intentional omission, or inadvertent? Do we want/need nonces in
the new DPD/DPV standards? 

I didn't want to mandate the use of nonces per se. However, the security
requirement that nonces address is covered in 1.8: 

1.8     Either the request/response protocol itself, or a specified lower
layer protocol to be employed for requests and responses, there must be a
provision for data origin authentication and connectionless integrity for
requests and responses, and responses must be matched to requests. Request
authentication & integrity is needed to support access control to the
server, a requirement for public servers. Responses must be authenticated
and integrity-protected to ensure that they are from the indicated server,
and matched to the request in question. Additional security services may be
offered optionally. 

I won't venture an opinion, but I will make some observations. Since nonces
are permitted in OCSP v1 responses, 

nonces may appear in OCSP responses embedded in the requests sent to the DPD
or DPV server. 

"1.2 A client request can contain one or more revocation data items, 

to assist the server in path validation." - from proposed DPD & DPV
requirements 

The nonces in the OCSP responses will be of no use to the server, because
the server did not generate the OCSP 

requests with the matching nonces. 

Likewise, the responses that a DPD server returns may contain OCSP responses
with nonces. (To thwart replay attacks, 

the DPD server may have put nonces in the requests that it made to OCSP
servers.) 

"2.2 A server must be able to return one or more sets of certification paths
and associated 

revocation data as a result of path discovery/validation. Each set shall
consist of an ordered 

list of certificates and associated CRLs and/or OCSP responses." - from
proposed DPD & 

DPV requirements 

These nonces will be useful to the DPD server, but not to the DPD client,
since the client did not generate the matching 

OCSP requests. UNLESS ....... the DPD server chooses the same nonce that it
received from the DPD client. (Contemplating 

this makes me queasy.) Recall that the protection against replay attacks was
based upon the requester not using the same 

nonce it had used before. This can be done cheaply by generating the nonces
as a sequence, or as a sizable random number. 

But if the DPD server doesn't generate the nonce, then it must keep a record
of all the nonces that it has seen (well, perhaps 

only those it has seen within some global time-ambiguity interval). Failing
to keep track of past nonces renders the DPD 

server vulnerable to conspiracies between the DPD client and another agent
replaying older OCSP responses to the DPD server. 

But why would a DPD client conspire against itself? It might undertake such
a conspiracy in order to fool the DPD server 

into attesting to incorrect (or at least out-of-date) certificate status,
with a view toward later presenting this incorrect 

attestation to someone else. (If the DPD response is timestamped, then all
the response data, including the incorrect revocation 

data, will have been signed as part of the timestamp.) 

An alternative would be for the DPD server to generate its own nonces, and
then simply attest to the DPD client that all the OCSP 

responses returned in the DPD response are fresh. But this calls for some
amount of trust in the DPD server, and part of the 

premise for DPD (as opposed to DPV) was that the client might not trust the
server. 

Interesting point re a DPD server returning OCSPv1 responses. i didn't think
about that in detail! I'll have to think more about that case. 

Steve