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

From: "Covey, Carlin" <[email-masked]>
Date: Wed, 3 Jan 2001 17:21:23 -0800

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 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.

So, to nonce or not to nonce?  That is the question.

- Regards,
Carlin Covey
Cylink Corp.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Jan 2001 09:37:05 -0500

At 5:21 PM -0800 1/3/01, Covey, Carlin wrote:
>The premise of this is that the requester picks a nonce that it 
>hasn't used before, and includes it in its 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, 
>The nonces in the OCSP responses will be of no use to the server, 
>because the server did not generate the OCSP
>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
>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