|
See my comments inline. Regards, LK -----Original Message----- 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: 1. What the
responder returns if it can not return a nonce 2. 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. LK: I agree (precisely for the reason you
give for #2, i.e. this replay protection was requested by the client, so let
the client decide whether or not it wants to go ahead and accept a nonce-less
response. Our ARP client will
currently reject such nonce-less responses, if it included a nonce in the
outgoing message.) 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? LK: I assume the others believe that if
you can indicate in a special way that a nonce-less response is still “trustworthy”…i.e.
the only reason it doesn’t contain a nonce is because it’s coming
from a keyless responder otherwise it’s trustworthy. Rather than a normal nonce-less
response which may be coming from a keyless responder or may be a replay! Assuming my understanding is correct, I
still think this is unnecessary complication. Even in this case the final
decision will still remain with the client on what to do next…i.e. the
client may accept the response or reject it depending on local policy….so
what are you gaining?? 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 From: Liaquat
Khan Ryan,We also agree with your viewpoint, particular the point about a noncebeing a matter for local client policy. In the various OCSP clients we have, the option of whether to includenonce or not in the request message is left to local policy (i.e. theadministrator can configure whether or not nonce is included in therequest message). If the administrator decides nonces are necessary (to prevent replays)then he/she will select these and our OCSP clients will include these inthe requests. Now if an OCSP response is received back without a nonceit 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 includeone 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 toforgo nonces or we will generate a fresh request without a nonce" is notthat common in my opinion. If such a case does exist, local policy willprobably be also happy to choose to not include a nonce in the OCSPrequest message in the first place.Regards,LiaquatAscertia Limited, Orchard Building, Royal Holloway, Egham, Surrey, TW20OEXtel: +44(0)1784 497 321, fax: +44(0)1784 497301, mobile: +44 (0)7776308766website: www.ascertia.com-----Original Message-----From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Ryan M. HurstSent: 05 December 2003 01:41To: Florian Oelmaier; David Engberg; ietf-pkix@xxxxxxxSubject: RE: DISCUSS: MUST reject in OCSPv1I 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 sayingthis 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 notcontaining the requested nonce MUST be rejected.But since I appear to be odd man out on this, I would rather see us fallback to Russ's original recommendation of MUST reject than break a 5year old standard. Ryan-----Original Message-----From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Florian OelmaierSent: Thursday, December 04, 2003 1:47 AMTo: David Engberg; ietf-pkix@xxxxxxxSubject: RE: DISCUSS: MUST reject in OCSPv1> I like the elegance of Russ and Florian's ideas for securelysignalling > 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 thismessage > to the client.Just for the record: I think you are referring to our server-generatednonces when you talk about "Florian's idea". And while Russel issignalling "NonceUnsupported" with a special nonce-value, we aresingalling "NonceSupported" with the inclusion of a nonce into everyrequest (mirrored from the request or server-generated). Thus we are notsubject to the attack you mention, as this does not need any additionalcode in any existing client.Russ proposal is a change in the protocol. Thus we need to update allthe clients and servers out there. Seeing that the proposed change isneeded and recognizing it as a good solution, I would accept this. -- Florian OelmaierSyTrust |