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

["Covey, Carlin" <ccovey@xxxxxxxxxx>]

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:peterw@xxxxxxxxxxxx]
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:kent@xxxxxxx]
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