Liaquat - I don't think there is any disagreement on weather it is up to the client or not on including the nonce, there is however disagreement on:
-
What the responder returns if it can not return a nonce
-
What the client must do when it receives a response to a nonced request
For #1 my stance has been that the server should always return a authoritative response.
For #2 my stance has been that just like the decision to include the nonce in the first place its up to the client to decide what to do with it when he gets it back, and that clients wanting replay protection SHOULD reject responses that do not contain the nonce from their request.
That being said others believe:
For #1 that the server needs to return a special response indicating it is not capable of supporting nonces
For #2 that the client has no choice on what to do with the nonce in the response if he included a nonce in the request.
My take on #1 is that I don't see why the client needs to know that, after all if the response to a nonced request does not contain the same nonce doesn't that mean the server was unable to produce a nonced response?
Changing the protocol by adjusting the ASN.1 of the nonce, adding a new extension or error code, or adding special semantics to the value of the nonce will break the existing implementations out there and its not clear to me why this is needed (especialy in v1).
My take on #2 is that its a matter of policy of the client to the client, but if accepting the MUST reject text here gets us out of #1 which will break clients I will accept it.
Ryan
Ryan,
We also agree with your viewpoint, particular the point about a nonce
being a matter for local client policy.
In the various OCSP clients we have, the option of whether to include
nonce or not in the request message is left to local policy (i.e. the
administrator can configure whether or not nonce is included in the
request message).
If the administrator decides nonces are necessary (to prevent replays)
then he/she will select these and our OCSP clients will include these in
the requests. Now if an OCSP response is received back without a nonce
it will be rejected by our OCSP clients.
On the other hand, if the administrator feels nonces are not required
(to allow for cached responses) then he/she will not select to include
one in outgoing responses.
The situation "we would like to have nonces in OCSP requests as default,
but if the server legitimately doesn't support nonces we are happy to
forgo nonces or we will generate a fresh request without a nonce" is not
that common in my opinion. If such a case does exist, local policy will
probably be also happy to choose to not include a nonce in the OCSP
request message in the first place.
Regards,
Liaquat
Ascertia Limited, Orchard Building, Royal Holloway, Egham, Surrey, TW20
OEX
tel: +44(0)1784 497 321, fax: +44(0)1784 497301, mobile: +44 (0)7776
308766
website: www.ascertia.com
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Ryan M. Hurst
Sent: 05 December 2003 01:41
To: Florian Oelmaier; David Engberg; ietf-pkix@xxxxxxx
Subject: RE: DISCUSS: MUST reject in OCSPv1
I am concerned with the idea of making any change to the standard that
"changes the 5 year old protocol".
This is particularly true since I don't see anyone on the list saying
this NonceUnsupported is needed, just that they would accept it.
I still think what is done with the nonce is a matter of local (client)
policy, and that if replay protection is desired responses not
containing the requested nonce MUST be rejected.
But since I appear to be odd man out on this, I would rather see us fall
back to Russ's original recommendation of MUST reject than break a 5
year old standard.
Ryan
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Florian Oelmaier
Sent: Thursday, December 04, 2003 1:47 AM
To: David Engberg; ietf-pkix@xxxxxxx
Subject: RE: DISCUSS: MUST reject in OCSPv1
> I like the elegance of Russ and Florian's ideas for securely
signalling
> that a server doesn't support nonces by using a special value for the
> nonce in replies. This seems like the "right" place to put this
message
> to the client.
Just for the record: I think you are referring to our server-generated
nonces when you talk about "Florian's idea". And while Russel is
signalling "NonceUnsupported" with a special nonce-value, we are
singalling "NonceSupported" with the inclusion of a nonce into every
request (mirrored from the request or server-generated). Thus we are not
subject to the attack you mention, as this does not need any additional
code in any existing client.
Russ proposal is a change in the protocol. Thus we need to update all
the clients and servers out there. Seeing that the proposed change is
needed and recognizing it as a good solution, I would accept this.
--
Florian Oelmaier
SyTrust