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

From: Peter Williams <[email-masked]>
Date: Fri, 26 Jan 2001 18:21:29 -0800

Steve

Thank you for your instruction notes on style and your
designation of terseness as inappropriate. Forgive the length 
of the note that follows: it is not terse.

Carlin addressed some valuable issues at the outset of
this thread. They concerned the handling of nonces
in the circumstance that one protocol is dependent
upon completion of another - as between the DPV server and
supporting OCSP servers. One should refer to the thread's
first memo, as appropriate.

The PKI vendor community has worked with two PKI-using protocols that 
share this dependency characteristic. OCSP is used, in practice, 
mostly in chained mode where one server relies upon another to 
satisfy a client request.  The Directory's bound DAP queries, used 
in products like Baltimore UniCert, can similarly be chained 
over DSP.

(A) OCSP

The OCSP work does not say how nonces (used as part of mutual 
authentication procedures to prove the intended request 
recipient is the respondent) should be handled (see 2560/3.2)
during 

(1) chaining (2560/4.4.6), and 
(2) when a downstream server's OCSP response is forwarded
to a client, either unchanged or resigned, via the final, 
upstream OCSP responder. 

(B) X.509

The 1986 directory work was more diligent than IETF's OCSP, as its 
signed operations use X.509 procedures for strong authentication. (I 
could not take part in IETF work during OCSP design, due to an 
intervention by a US govt employee.) The X.509 procedures were 
designed for the case that RPC requests and responses requiring 
strong authentication would be operating in a chained, multi-protocol, 
distributed, server-server environment.

The requirement comments that Carlin outlined cites cases where
a DPV server signs a response only after having completed a
request/response dialogue with an OCSP server. Upon reading this, 
I recalled that a conforming OCSP server may be potentially operating 
in chained mode, in which the OCSP request (or response) signature 
verification may start a further round of DPV interaction, which may 
require another round of OCSP interaction, which...  In summary, this
requires that one designs for looping, and one addresses the associated 
requirements to assure a security-critical level of availability.

Then, I generalized for a moment. Where had I seen security experts apply
their talents to such an operational environment - one in which security
servers themselves issue requests to get critical knowledge in order 
to respond, and those knowledge requests may need recursively securing?
The answer was the Directory, when using X.509 to satisfy
its security model (See X.501, 10). Furthermore, I half remembered
replay issues were discussed in the security considerations
of http://www.ietf.org/rfc/rfc2560.txt. So, I did some requirements
homework.

When I considered contributing a memo to the requirements
discussion (with tremor in my terrorised typing fingers in case I 
be the next Juan to be blackballed or fall foul of a co-chair's 
"appropriate conduct" edict) I read the material that Carlin had responded
to, again. Nothing in those excerpts suggested that the persons who
originated the requirements were contemplating the need to address  security

requirements in a distributed, server-server, operations environment.

Given my access to considerable practical experience in deploying 
and/or enhancing chained-OCSP and chained-directories, and having seen 
what careful architects had done to either augment the OCSP facilities or 
fully implement the X.509 specification, I began to engage Carlin in 
developing these requirement by introducing the issues of information
element vs PDU timeliness,. I also gave an example of distributed 
operations. As is the custom, I copied the mail to the list,  for all to 
see, enjoy, and consider - as they think and learn on the issues
as a community.

For my part, I can only write this note, clearly, now that I have had the
benefit of the very dialogue and inputs which flush out the issues. 
Whilst no well-reasoned conclusion is evident, at least the requirement 
issues are well framed. 

My final substantive point notes that TSP contributors have 
previously thought about server-side nonce-handling. The WG 
seemingly and evidently knowingly punted the matter, despite known 
vulnerabilities and use-case issues. I continue to be awe of the 
simplicity of the expression and the foresight of those who 
designed X.509's reusable, PKI-based, strong authentication 
procedures, back in 1986.

If you need any additional context, please identify the topics. I will
respond in full.

Peter.

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

---

From: "Carlin Covey" <[email-masked]>
Date: Wed, 31 Jan 2001 10:31:59 -0700

Thank you Peter, for summarizing this thread so eloquently.
It certainly helped to put my befuddled questions into better
perspective.

Regards,

Carlin

-------------------------------

- Carlin Covey
  Cylink Corp.

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

Steve

(A) OCSP

(B) X.509

Peter.

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 31 Jan 2001 13:26:04 -0500

>of the note that follows: it is not terse.

Ah, again you miss the point!  Concise communication is preferred, so 
long as it is understandable.  Verbose communication can be just as 
poor (from a communication perspective) as terse communication, in 
the right hands. Parts of the rest of this message illustrate my 
point.

>first memo, as appropriate.

A DPV server is a client of an OCSP server, so it is not clear at the 
outset that this is a special case, vs. regular client/server 
interaction.

>in products like Baltimore UniCert, can similarly be chained

This is different from your opening example, i.e., OCSP has an 
ability to chain requests but is it not well described in the RFC, 
whereas DAP has a well defined chaining procedure that receives 
considerable attention in the X.500 standard.  But, a request from a 
DPV server to an OCSP server does not seem exactly equivalent (though 
perhaps analogous), as one has crossed protocol boundaries, which 
might impose limits on nonce formats, etc.

>to a client, either unchanged or resigned, via the final,

OK.

>distributed, server-server environment.

A "US govt employee?" Someone from the FDA, NIH, OSHA? That's 
intriguing, but not clearly relevant to the cause of clearly 
explaining the issue at hand.

>requirements to assure a security-critical level of availability.

Ah, finally getting to the point.

>of http://www.ietf.org/rfc/rfc2560.txt. So, I did some requirements

The context of the OCSP (RFC 2560) discussion focuses only on client 
use of nonces, although the client could be an end user or another 
OCSP server.

>requirements in a distributed, server-server, operations environment.

You begin the paragraph with an irrelevant aside (and a poor excuse), 
which demonstrates how verbose writing can be as obfuscatory as terse 
writing, in the right hands. The end of the paragraph merely 
continues this pattern.

>see, enjoy, and consider - as they think and learn on the issues

I, for one, learn better when the information is communicated in a 
fashion that is clear.

>Whilst no well-reasoned conclusion is evident, at least the requirement

This note does not, in my opinion, do a good job of framing the 
issues. Most of it was an extended background discussion justifying 
your original messages, and making critical asides in your defense.

>procedures, back in 1986.

I agree that, on this one point the X.509 authentication protocols 
seem to have done a very good job. But. in fairness, at least one 
member of that protocol suite was found to contain security holes 
that were the topic of publications in the late 80s or early 90s, so 
the suite is hardly without flaws, as are protocols like OCSP.

>If you need any additional context, please identify the topics. I will

What is useful for the DPV/DPD requirements development is a concise, 
self-contained proposal for nonce management in this context. It 
should define propose requirements for clients and servers, justify 
the requirements in this context, describe implications for chaining 
(or motivations derived from an assumption of support for chaining), 
and note what requirements might be relaxed if recursion within these 
protocols, is not supported. That, would be useful.

Steve

---

From: "Carlin Covey" <[email-masked]>
Date: Wed, 31 Jan 2001 12:16:19 -0700

Steve,

Please see my comments embedded below.

- Regards,

  Carlin

----------------

- Carlin Covey
  Cylink Corp.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 11:26 AM
To: Peter Williams
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

<snip>

<snip>

[Carlin's Jan 31 comment: I agree that a chain of relayed OCSP queries
   is a series of regular client/server interactions, but the issue I
   raised concerned the fact that nonces ordinarily provide replay
   protection for a client, not the client of a client.  The purpose
   of DPD is to return a chain of evidence to be evaluated by the
   end-client, but this end-client does not have the benefit of the
   replay protection afforded by the nonces exchanged between servers
   farther down the relay chain.  I had earlier raised the possibility that
   these nonces could be made meaningful to the end-client if the server
   used the client's same nonce when the server relayed an OCSP request
   to another server.  I observed that this may make the protocol vulnerable
   to some attacks, unless the server ensures that the nonce is not
repeated.
   I bemoaned the fact that keeping track of previously-used nonces might be
   expensive.  Peter pointed out a working implementation that minimized
   the expense.]

<snip>

[Carlin's Jan 31 comment: Steve, did you mean that OCSP is without flaws,
     or that OCSP is not without flaws?]

<snip>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 31 Jan 2001 19:01:56 -0500

carlin,

>    expensive.  Peter pointed out a working implementation that minimized

Not sure I see the problem clearly, yet. The communication between 
the end user client and a DPV server should employ security 
mechanisms that address the replay attack at least from the client 
side.  The response from the server already has to ensure integrity, 
so I would expect it to bundle components of the response, e.g., OCSP 
responses acquired by the DPV server from OCSP servers,  in a fashion 
that ensures integrity. Thus, I'm not sure why a nonce used by a 
client in its exchange with a DPV server need to be related to nonces 
in OCSP responses returned by the DPV server to this client. It's up 
to the DPV server to ensure that its interactions with OCSP servers 
are not replays, which is a local nonce management concern for the 
DPV server. The client of the DPV server relies on that server to do 
this properly and may not (need not?) be concerned with how this was 
accomplished.

>      or that OCSP is not without flaws?]

I meant that OCSP is not without flaws, just as X.509 authentication 
protocols were not without flaws.

Steve

---

From: "Carlin Covey" <[email-masked]>
Date: Wed, 31 Jan 2001 19:04:41 -0700

Steve,

I see the "nonce issue" as being different for DPD and for DPV.
See below.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 5:02 PM
To: Carlin Covey
Cc: [email-masked]
Subject: RE: DPD & DPV requirements - to nonce or not to nonce?

<snip>

[Carlin]:
I agree that if the client is going to trust the DPV server
to give a correct status response, the client should also trust the
DPV server to check the nonces in any responses that the server receives
from queries that it relays to other servers.  

But what about a DPD query?  The client gets back a list of certificates 
and a set of certificate status information that may contain OCSP responses
with nonces in them.  But the client can't use the nonces to protect itself
against replay, because the client didn't generate those nonces.  Some
server downstream (upstream? which way does this stream flow?) put the
nonces in queries that were relayed to other servers.  If the client can
make do without replay protection, why were nonces put in the OCSP protocol
in the first place?  Note that this isn't a deficiency of OCSP.  The same 
thing would be true of DPV, DPD or SCVP if those responses were returned 
in DPD responses.

Regards,

Carlin

---------------------------------

- Carlin Covey
  Cylink Corp.