Subject: OCSP extensions

From: Ambarish Malpani <[email-masked]>
Date: Mon, 21 Jan 2002 09:35:40 -0800

Hi Florian,

    Interesting point of view. However, we are at the stage of
progressing OCSP from a Proposed to a Draft Standard.

If the standard as it currently stands is not broken, I would
prefer leaving the meaning of fields as they currently are.

What you are proposing is a legitimate extension, but quite
different in semantics from the nonce as defined in OCSP.

What might make sense, is to come up with a separate draft of
useful OCSP extensions, run that through the standards process
and merge it with the OCSP spec when both reach the same level
of acceptance. A list of "standard" OCSP extensions has been
on my TODO list for some time now - so if you like, we can work
on such a draft together.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Florian Oelmaier [mailto:[email-masked]]
> Sent: Monday, January 21, 2002 4:08 AM
> To: Santosh Chokhani; Yuriy Dzambasow; Ambarish Malpani; 
> 'Deacon, Alex';
> [email-masked]
> Subject: RE: OCSP RFC and OCSP version 2 ID
> 
> 
> Hello Santosh,
> 
> I would like to add some comments to your suggestion b)
> 
> >
> > b.  If the request has a nonce extension, the response must have
> > the nonce extension with the same value as the request.
> >
> 
> Although I appreciate this change as it improves the security of the
> protocol, I have a point that I want you to see clearly 
> before making this
> change.
> 
> As the client most probably knows nothing about the 
> Validation-System behind
> a PKI (except the IP of the OCSP-Responder, he has to contact) it is
> advisable for the client to always include a nonce into his request
> ("well-behaving client"). With "well-behaving clients" and 
> the proposed
> change of the RfC we will face problems with these scenarios:
> 
> Scenario 1: Setup of a Responder that pre-produces answers as 
> specified in
> 2.5 of RfC 2560.
> 
> Scenario 2: Setup of a PKI that uses HTTP-Caching as given 
> for example in
> A.1.1 of RfC 2560.
> 
> Scenario 3: Some PKIs use a Root-Responder architecture with 
> various other
> responders relaying to this root responder and caching his 
> answer for a
> certain period of time. [Although I disregard such an 
> architecture, it is
> used today]
> 
> These problems may lead to clients not using nonce per 
> default. If a client
> does not use a nonce, it is vulnerable to replay-attacks.
> 
> Today an OCSP-Responder can decide if he wants to expose himself to
> replay-attacks by generating answers without nonces. That means if a
> responder generates only ONE response without nonce it is 
> vulnerable. On the
> other hand, if an OCSP-responder includes a nonce in every 
> response ever
> generated in his lifetime, regardless of a nonce in the 
> request, it is NOT
> vulnerable to replay-attacks (at least not to "well-behaving 
> clients").
> 
> Therefore I would suggest the following change to clarify the 
> RfC instead of
> the proposed change:
> 
> "Every client MUST include a nonce into his request. If a 
> nonce is included
> in the response, the client MUST match it to the nonce of the request.
> Although imposing a security problem, a client MAY trust 
> OCSP-responses
> without nonce."
> 
> and
> 
> "To prevent replay-attaks an OCSP-responder SHOULD include a 
> nonce in every
> response."
> 
> Rationale:
> - Responders can choose between security and functionality
> - Clients can detect Responders that chose functionality
> 
> --
> Dipl.Inf. Florian Oelmaier
> syTrust S.A.
> 
>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 28 Jan 2002 15:29:03 +0100

Ambarish,

The current text is the following:

   The nonce cryptographically binds a request and a response to prevent
   replay attacks. The nonce is included as one of the requestExtensions
   in requests, while in responses it would be included as one of the
   responseExtensions. In both the request and the response, the nonce
   will be identified by the object identifier id-pkix-ocsp-nonce, while
   the extnValue is the value of the nonce.

If the nonce is not used, then the only field to prevent replay attacks is
the use of the field producedAt. However the text does not explain what kind
of processing should be done with that field from a client point of view.

At the end of section "4.2.2.1 Time" it would be appropriate to add after:

   The producedAt time is the time at which this response was signed.

The following sentence:

"When replay attack protection is required, a client MUST check that the
producedAt time is close to the local current time, otherwise when no local
clock is available, then, it SHALL use a nonce (see section 4.4.1)."

Then in the security considerations section we should provide some warning
when using the producedAt time in the context of 2.5.

" When pre-produce signed responses are used by the servers, the field
producedAt time is not necessarily a time close to the time of the request.
So unless this field is checked to be close to the current time, replay
attacks are possible."  

Denis

---

From: "Florian Oelmaier" <[email-masked]>
Date: Mon, 28 Jan 2002 19:03:53 +0100

This proposal for clarification would be great. It is wholeheartly welcomed
here.

Head of Development
syTrust S.A.

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Monday, January 28, 2002 3:29 PM
> To: Ambarish Malpani
> Cc: 'Florian Oelmaier'; [email-masked]
> Subject: Re: OCSP extensions
>
>
> Ambarish,
>