Subject: About the Nonce issue in OCSPv1

From: "Julien Stern" <[email-masked]>
Date: Fri, 6 Aug 2004 12:34:48 +0200

Dear PKIX list,

I had closely followed the long discussion about OCSP nonce problems
that occured on the list around sep to dec 2003, and recently saw in
the minutes of the WG meeting that OCSPv1 was to be clarified on that
matter.

I would like to submit the following to your appreciation.
I believe that the following clarification (interpretation ? :))
of RFC2560 solves all nonce/replay attack problems, without modifying
the protocol or adding new extensions, and is fairly consistent with
existing client and server implementations and hopefully with the
spirit of the RFC.

Naturally, comments are welcome and you can feel free to do whatever you
want with what's below, notably dumping it into oblivion ;)

Regards,

--
Julien Stern

General
-------
The CRL approach to revocation checking has two principal drawbacks:
the first one is that one needs to download a full CRL in order to
check a single certificate and the second is that a CRL does not
provide timely information (there is always a time frame during which
a revoked certificate is not yet present in the CRL). The OCSP allows
to overcome one or both of these drawbacks, depending on the mode in
which it is used.

An OCSP server can be configured in two different modes: the "caching"
mode and the "live" mode. The live mode means that the server has access
to up to date information and will always provide it. The caching mode
means that the information obtained from the server has a delay with
respect to the up to date information.

The caching mode overcomes the bandwidth problem associated with CRL,
but does not ensure timely information. The live mode solves both
problem, but naturally is more computationaly expensive than the caching
one. Typically, the caching mode would be used when the source of
revocation information are CRLs but could also be used for efficiency
reason when timely information is available.

A server MUST NOT operate in caching and live mode at the same time.

Clarifying requirements for caching OCSP servers
-----------------------------------------------
- the nextUpdate field of all the SingleResponse elements MUST be present.
  It should indicate the expiration date of the (cached) information validity.
- the nonce extension can (and should) be ignored

Clarifying requirement for live OCSP servers
--------------------------------------------
- the nextUpdate field of all the SingleResponse elements MUST be absent,
  thus indicating the information is live
- live servers MUST support the nonce extension

Client behavior
---------------
If a client does not care about timely information, but simply wishes
to save bandwidth, he MAY send a request without the Nonce extension.

However, the behavior that clients SHOULD follow is:

1) Send a request with a Nonce;

2) If the response contains a Nonce, check that the Nonce matches the
one sent. If they do not, reject the response, otherwise, the client is
ensured to have timely information;

3) If the response does not contain a Nonce, check that all the
SingleReponse elements contain a nextUpdate field, if not reject;
otherwise, the client knows that the information is not timely but has,
for each certificate, the time frame during which this information is
deemed valid. Rejection or acceptance can be decided based on a local
policy specifying, for example, acceptable time frames.

About the replay attacks
------------------------
One of the main issue that was raised during the previous discussions
was to enable both server modes (Caching and Live) without prior
knowledge of the client without more than one network interaction,
while preventing replay attacks.

Two different mecanisms are in fact in place to prevent replay attacks:
the nonces and the nextUpdate field. The nextUpdate field places an
upper limit on the time for which replay attacks are possible. However,
because they are only used by caching servers, a replay attack would
simply provide the same information as the server itself would. If
the nextUpdate field is absent, then the server is live and must have
included a nonce in its reply to prevent replay attacks with this
message.

The danger may occurs when a message corresponding to one type of
protection is replaced by a replayed message corresponding to the other.
But in fact, there is only one configuration in which this may lead to a
security risk:

- A client sends a nonceless request
- An attacker replies with a previously intercepted live response

In that case, the client can still check that the producedAt and
thisUpdate fields are recent enough to mitigate the attack... At any
rate, clients should always send requests with nonce if they want
security...

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 6 Aug 2004 15:52:58 -0700

Julien,

Yes, we will be clarifying 2560 in this regard.  As I said in San Diego,
the text will be "accomodative" of servers unable to respond to nonced
requests.  I am aiming to keep this clarification to a paragraph at
most.  Your text is nonetheless very good input.  I look forward to your
review of the final text when it becomes available.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Julien Stern
Sent: Friday, August 06, 2004 3:35 AM
To: [email-masked]
Subject: About the Nonce issue in OCSPv1

Dear PKIX list,

Regards,

--
Julien Stern

General
-------

Clarifying requirements for caching OCSP servers
-----------------------------------------------
- the nextUpdate field of all the SingleResponse elements MUST be
present.
  It should indicate the expiration date of the (cached) information
validity.
- the nonce extension can (and should) be ignored

- the nextUpdate field of all the SingleResponse elements MUST be
absent,

Client behavior
---------------

About the replay attacks
------------------------

---

From: David Engberg <[email-masked]>
Date: Sat, 07 Aug 2004 18:08:37 -0400

Julien -

Interesting suggestions.  I wonder whether the "nextUpdate" field in an 
OCSP response may have value for clients, even when a nonce is used. 
For example, even a client who uses nonces to partially mitigate against 
freshness-related attacks may wish to locally cache responses for some 
period of time.  The "nextUpdate" field may give some guidance to the 
client to indicate an upper bound on safe local caching.

Previous proposals suggested using a new response extension to signal 
cache/live server support.  Overloading the "nextUpdate" field for this 
purpose allows us to avoid adding any new syntactic elements, but a new 
field or extension would permit the continued use of "nextUpdate" in all 
settings.

Thanks,
Dave

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 8 Aug 2004 10:57:25 -0400

Julien:

I have a problem with the proposal since you can have a "live" mode and
still some latency in the revocation information as bounded by the next
Update field.

An example of such situation is when the responder is not the CA and uses
the CRL as the means of obtaining the revocation information.

Please note that 2560 does not provide any standard for obtaining
revocation information.  nextUpdate relates to how the OCSP Responder
obtains and processes revocation information where as nonce relates to how
the OCSP Responder produces responses.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Engberg
Sent: Saturday, August 07, 2004 6:09 PM
Cc: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1

Julien -

Thanks,
Dave

Julien Stern wrote:
> I believe that the following clarification (interpretation ? :)) of
> RFC2560 solves all nonce/replay attack problems, without modifying the
> protocol or adding new extensions, and is fairly consistent with
> Naturally, comments are welcome and you can feel free to do whatever
> you want with what's below, notably dumping it into oblivion ;)
>
> Regards,
>
> --
> Julien Stern
>
>
> General
> -------
> mode and the "live" mode. The live mode means that the server has
> access to up to date information and will always provide it. The
> caching mode means that the information obtained from the server has a
> delay with respect to the up to date information.
>
> problem, but naturally is more computationaly expensive than the
> caching one. Typically, the caching mode would be used when the source
> of revocation information are CRLs but could also be used for
> efficiency reason when timely information is available.
>
present.
absent,
> one sent. If they do not, reject the response, otherwise, the client
> is ensured to have timely information;
>
> otherwise, the client knows that the information is not timely but
> has, for each certificate, the time frame during which this
> information is deemed valid. Rejection or acceptance can be decided
> based on a local policy specifying, for example, acceptable time
> frames.
>
> About the replay attacks
> ------------------------
> Two different mecanisms are in fact in place to prevent replay
> attacks: the nonces and the nextUpdate field. The nextUpdate field
> places an upper limit on the time for which replay attacks are
> possible. However, because they are only used by caching servers, a
> replay attack would simply provide the same information as the server
> itself would. If the nextUpdate field is absent, then the server is
> live and must have included a nonce in its reply to prevent replay
> attacks with this message.
>
> protection is replaced by a replayed message corresponding to the
> other. But in fact, there is only one configuration in which this may
> lead to a security risk:
>

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 9 Aug 2004 10:47:30 +0200

> client to indicate an upper bound on safe local caching.

David,

Well, I would tend to think that if a nextUpdate field is present to
indicate a "safe local caching" period, then, a nonce was useless
anyway. As a matter a fact, a "safe local caching" period would tend to
indicate the status of the cert will not be changed until the end of
the period, so why use nonces ?

Nonce only offer additionnal protection for "really live" message,
otherwise the thisUpdate + nextUpdate fields are enough. It works for
CRLs :)

> field or extension would permit the continued use of "nextUpdate" in all 

I have naturally read all of them, and I was at first quite convinced by
a "IDoNotSupportNonces" extension, but I then though that the
nextUpdate field might be enough and (maybe) match real-life usage.
The quasi-totality of deployed OCSP responders are "caching" anyway.

--
Julien

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 9 Aug 2004 11:03:37 +0200

> the CRL as the means of obtaining the revocation information.

Santosh,

this example would typically fall into the "caching" mode in the
terminology below. I do not see any advantage to use nonces when the
information is backed up by CRLs anyway. Because you know the CRL will
not change until what is indicated in its "nextUpdate" field, sending
a nonce-less OCSP reply should not expose you to any replay attack.

I'm currently thinking that nonces are an overkill in most cases,
because they are meant to protect against replay attacks that do not
exist if (i) there is a nextUpdate field (ii) no status change will
occur before the nextUpdate.

Note that if there is a status change before the nextUpdate, then
clients that have cached the information may have wrong information.

Now, when the OCSP is really live (meaning that the status of a particular
cert may change any time), one does not want to put any nextUpdate
field, because there is no time frame during which the information may
be cached by the client. And in this case, you need nonces to defend
against replay attacks.
 
> the OCSP Responder produces responses.

Well, the RFC says:

   - nextUpdate: The time at or before which newer information will be
                    available about the status of the certificate

will essentially says "my reply is valid until nextUpdate". (So, why
use nonces here ...)

and 

   If nextUpdate is not set, the responder is indicating that newer
      revocation information is available all the time.

and in this case, nonces are vital, because the message is not
intrinsically protected as were those containing the nextUpdate field.

--
Julien

---

From: "Liaquat Khan" <[email-masked]>
Date: Mon, 9 Aug 2004 10:25:23 +0100

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Julien Stern
> Sent: 09 August 2004 10:04
> To: Santosh Chokhani
> Cc: [email-masked]

What about emergency CRLs which may be issued before the next official
"nextUpdate", and pushed by the CRL issuer to the OCSP responder? 

Does anyone have an idea of what percentage of PKIs really use emergency
CRLs? 

Regards,
Liaquat

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 9 Aug 2004 11:49:52 +0200

> "nextUpdate", and pushed by the CRL issuer to the OCSP responder? 

Yes, that might be a problem depending on the client behavior. I guess
most clients would cache answers until the nextUpdate. If you want
an "emergency" information to be propagated, it seems you would need
a real "live" (and nonced) OCSP responder...

> Does anyone have an idea of what percentage of PKIs really use emergency

Well, I don't ;)
 
--
Julien

---

From: "Liaquat Khan" <[email-masked]>
Date: Mon, 9 Aug 2004 12:18:43 +0100

> Sent: 09 August 2004 10:50
> To: Liaquat Khan
> Cc: 'Santosh Chokhani'; [email-masked]
> > > > I have a problem with the proposal since you can have a "live"
mode
> > and
> > > > still some latency in the revocation information as bounded by
the
> > next
> > > > Update field.
> > > >
> > > > An example of such situation is when the responder is not the CA
and
> > > uses

Yes, this was the point I was trying to make, in such cases the OCSP
responder although working from CRLs, would still find it worthwhile to
use nonces.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Aug 2004 09:46:47 -0400

PKIs I have been involved with, commit to publish CRL when there is a key
compromise immediately.

Of course, none of them have had compromises yet.

But, they do issue CRL reasonably well before next update.

It is typical to have a next update as this update + 7 days, but the actual
publication within 24 to 48 hours.

-----Original Message-----
From: Liaquat Khan [mailto:[email-masked]] 
Sent: Monday, August 09, 2004 5:25 AM
To: 'Julien Stern'; 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: About the Nonce issue in OCSPv1

Regards,
Liaquat

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Aug 2004 09:43:38 -0400

Julien:

Nonces help with the freshness of the revocation information.  For example,
a Responder could poll or CA could push CRLs using SSL, in which case there
is no old CRL substitution threat.  Thus, the Responder could get out of
cycle (i.e., CRL issues prior to the next update) and use that later
information.

Thus, it is important to keep the concept of next update and nonce separate.

-----Original Message-----
From: Julien Stern [mailto:[email-masked]] 
Sent: Monday, August 09, 2004 5:04 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1

On Sun, Aug 08, 2004 at 10:57:25AM -0400, Santosh Chokhani wrote:
> Julien:
> 
> I have a problem with the proposal since you can have a "live" mode 
> and still some latency in the revocation information as bounded by the 
> next Update field.
> 
> An example of such situation is when the responder is not the CA and 
> uses the CRL as the means of obtaining the revocation information.

Santosh,

this example would typically fall into the "caching" mode in the terminology
below. I do not see any advantage to use nonces when the information is
backed up by CRLs anyway. Because you know the CRL will not change until
what is indicated in its "nextUpdate" field, sending a nonce-less OCSP reply
should not expose you to any replay attack.

I'm currently thinking that nonces are an overkill in most cases, because
they are meant to protect against replay attacks that do not exist if (i)
there is a nextUpdate field (ii) no status change will occur before the
nextUpdate.

Note that if there is a status change before the nextUpdate, then clients
that have cached the information may have wrong information.

Now, when the OCSP is really live (meaning that the status of a particular
cert may change any time), one does not want to put any nextUpdate field,
because there is no time frame during which the information may be cached by
the client. And in this case, you need nonces to defend against replay
attacks.
 
> obtains and processes revocation information where as nonce relates to 
> how the OCSP Responder produces responses.

Well, the RFC says:

will essentially says "my reply is valid until nextUpdate". (So, why use
nonces here ...)

and 

and in this case, nonces are vital, because the message is not intrinsically
protected as were those containing the nextUpdate field.

--
Julien

> Interesting suggestions.  I wonder whether the "nextUpdate" field in 
> an OCSP response may have value for clients, even when a nonce is 
> used. For example, even a client who uses nonces to partially mitigate 
> against freshness-related attacks may wish to locally cache responses 
> for some period of time.  The "nextUpdate" field may give some 
> guidance to the client to indicate an upper bound on safe local 
> caching.
> 
> cache/live server support.  Overloading the "nextUpdate" field for 
> this purpose allows us to avoid adding any new syntactic elements, but 
> a new field or extension would permit the continued use of 
> "nextUpdate" in all settings.
> 
> Thanks,
> Dave
> 
> 
> Julien Stern wrote:
> >
> >
> > Dear PKIX list,
> >
> > the minutes of the WG meeting that OCSPv1 was to be clarified on 
> > that matter.
> >
> > I would like to submit the following to your appreciation. I believe 
> > that the following clarification (interpretation ? :)) of RFC2560 
> > solves all nonce/replay attack problems, without modifying the 
> > provide timely information (there is always a time frame during 
> > which a revoked certificate is not yet present in the CRL). The OCSP 
> > allows to overcome one or both of these drawbacks, depending on the 
> > mode in which it is used.
> >
> > An OCSP server can be configured in two different modes: the 
> > "caching" mode and the "live" mode. The live mode means that the 
> > server has access to up to date information and will always provide 
> > it. The caching mode means that the information obtained from the 
> > server has a delay with respect to the up to date information.
> >
> > The caching mode overcomes the bandwidth problem associated with 
> > CRL, but does not ensure timely information. The live mode solves 
> > both problem, but naturally is more computationaly expensive than 
> > the caching one. Typically, the caching mode would be used when the 
> > source of revocation information are CRLs but could also be used for 
> > If a client does not care about timely information, but simply 
> > wishes to save bandwidth, he MAY send a request without the Nonce 
> > extension.
> >
> > 2) If the response contains a Nonce, check that the Nonce matches 
> > the one sent. If they do not, reject the response, otherwise, the 
> > client is ensured to have timely information;
> >
> > One of the main issue that was raised during the previous 
> > discussions was to enable both server modes (Caching and Live) 
> > without prior knowledge of the client without more than one network 
> > interaction, while preventing replay attacks.
> >
> > replay attack would simply provide the same information as the 
> > server itself would. If the nextUpdate field is absent, then the 
> > server is live and must have included a nonce in its reply to 
> > prevent replay attacks with this message.
> >
> > other. But in fact, there is only one configuration in which this 
> > may lead to a security risk:
> >

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 9 Aug 2004 16:26:41 +0200

Santosh,

All right, but then, what is the nextUpdate field supposed to mean for
the client ? My understanding was that the nextUpdate field meant more
or less: this information is valid and can be cached until this time.

If one publishes CRL every day with a difference between thisUpdate and
nextUpdate of one week, I believe that the vast majorities of the
clients will only actually pick one CRL out of seven, as they will cache
the information until the nextUpdate.

If an OCSP was to feed itself on daily CRLs like that, it could set
a nextUpdate of one day instead of one week, and if it does not want
clients to cache information, it should not set nextUpdate.

If not yet convinced that the nextUpdate and the nonces are so separate.
Either I'm not grasping exactly the signification of nextUpdate or I
really do not see the combined use of nonces and the nextUpdate field.

--
Julien

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Aug 2004 12:21:30 -0400

Julien:

nextUpdate and nonce are different.

As to the meaning of nextUpdate, I always use the field as absent other
security mechanisms freshness of CRL and windows of CRL substitution attack
is no worse than nextUpdate.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Monday, August 09, 2004 10:27 AM
To: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1

On Mon, Aug 09, 2004 at 09:43:38AM -0400, Santosh Chokhani wrote:
> 
> Julien:
> 
> Nonces help with the freshness of the revocation information.  For 
> example, a Responder could poll or CA could push CRLs using SSL, in 
> which case there is no old CRL substitution threat.  Thus, the 
> Responder could get out of cycle (i.e., CRL issues prior to the next 
> update) and use that later information.
> 

Santosh,

All right, but then, what is the nextUpdate field supposed to mean for the
client ? My understanding was that the nextUpdate field meant more or less:
this information is valid and can be cached until this time.

If one publishes CRL every day with a difference between thisUpdate and
nextUpdate of one week, I believe that the vast majorities of the clients
will only actually pick one CRL out of seven, as they will cache the
information until the nextUpdate.

If an OCSP was to feed itself on daily CRLs like that, it could set a
nextUpdate of one day instead of one week, and if it does not want clients
to cache information, it should not set nextUpdate.

If not yet convinced that the nextUpdate and the nonces are so separate.
Either I'm not grasping exactly the signification of nextUpdate or I really
do not see the combined use of nonces and the nextUpdate field.

--
Julien

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 9 Aug 2004 18:59:43 +0200

Santosh,

Of course they are ! We were arguing about whether they were "separate"
or not. I believe that nonces add almost no value if you use nextUpdate,
and are critical when nextUpdate is absent.
If nextUpdate indicate when new information will be available, there is
no risk of replay attack in between anyway.

> is no worse than nextUpdate.

??? Sorry, I just don't get that part :)

--
Julien

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 09 Aug 2004 16:42:59 -0400

Woman: without her, man is nothing.
Woman, without her man, is nothing.
     -- from "Eats, Shoots & Leaves"

Punctuation is often helpful and sometimes essential.  I believe
Santosh meant:

   As to the meaning of nextUpdate, I always use the field as:
   "absent other security mechanisms, freshness of CRL and windows
   of CRL substitution attack is no worse than nextUpdate."

Julien Stern wrote:

 > ...

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 9 Aug 2004 20:33:37 -0400

Thanks you, David.  Well put and properly corrected.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David P. Kemp
Sent: Monday, August 09, 2004 4:43 PM
To: [email-masked]
Subject: Re: About the Nonce issue in OCSPv1

Punctuation is often helpful and sometimes essential.  I believe Santosh
meant:

Julien Stern wrote:

>>As to the meaning of nextUpdate, I always use the field as absent 
>>other security mechanisms freshness of CRL and windows of CRL 
>>substitution attack is no worse than nextUpdate.
> 
>