RE: XKMS

[This just to the list, avoid duplicate copies]
 
I spent a lot of time thinking about the 'nonce issue' and have held every
side of the argument to be true at one time...
 
 
WRT caching and nonces, the problem does not actually occur, there are
exactly two situations:
 
1) The relying party requires 'fresh' data, the relying party must issue
some form of nonce and check it in the response.
2) The relying party is prepared to accept cached data, the relying party
ignores the nonce if present.
 
The <TransactionID> element may be used to provide a nonce, the text could
make this clearer.
 
 
There are two levels at which this issue might be addressed:
 
1) In XKMS (probably right for us)
2) In ws-security (or xkms-security being the pro-tem version).
 
One thought is that we might define a signed element that would carry the
security context of a request/response, this could be a part of the
<Signature> block and look something like:
 
<SigningContext>
 
<WebService>http://xkms2_0.xmltrustcenter.test/high_security</WebService>
 
<TransactionID>szw4o57bw9a84yq2437y56q24y5698q2y46q20637y</TransactionID>
</SigningContext>
 
 
I think we need to make sure we keep track of all the issues of this type
since they are all applicable to any web service requiring security
guarantees.
 
 
It is important to note in the security considerations section that the
scenario Mike is talking about is only secure if you have authenticated
requests and responses. Otherwise Alice can request status of cert X and
mallet substitute cert Y in the request to get a 'valid' back.
 
 
        Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


-----Original Message-----
From: Mike Just [mailto:Mike.Just@entrust.com]
Sent: Tuesday, November 27, 2001 8:55 AM
To: 'stephen.farrell@baltimore.ie'; Rich Salz
Cc: Blair Dillaway; Hallam-Baker, Phillip; www-xkms-ws@w3c.org
Subject: RE: XKMS



Regarding the first question, the answer might be both. Including just the
service URL in the response does not prevent an attacker from replaying a
previous response. A nonce (e.g. random value) sent in the request and
included in the response would prevent replay. An unfortunate consequence is
that using a nonce prevents the server from caching and reusing responses.
Though a nonce might not be necessary if one were to rely on the validity
period included in a response.

Likewise, including just a nonce (e.g. random value) does not prevent an
attacker from redirecting to another service port.  An attacker would just
redirect the same request (with the same nonce) to another service port.
Including the URL of the requested service seems to help this particular
situation. But as I've mentioned before, it's probably also a good idea to
include something like the hash of the original request in the response.
That way, if a client (with no ASN.1 capabilities) sends a Validate request
with an X.509 certificate, and KeyValue returned in the response, they can
confirm that the KeyValue returned actually corresponds to the cert they
requested. Otherwise an attacker might replace the certificate included in
the request. 

I have to think some more about the second question. 

Mike 


> -----Original Message----- 
> From: Stephen Farrell [ mailto:stephen.farrell@baltimore.ie
<mailto:stephen.farrell@baltimore.ie> ] 
> Sent: Tuesday, November 27, 2001 5:18 AM 
> To: Rich Salz 
> Cc: Blair Dillaway; Hallam-Baker, Phillip; Mike Just; 
> www-xkms-ws@w3c.org 
> Subject: Re: XKMS 
> 
> 
> 
> All, 
> 
> I'd tend to agree that the URL level "trust" model is the thing to go 
> with for xkms. 
> 
> Two further questions:- 
> 
> 1. Is there a specific issue with preventing replay of a 
> reponse from a 
> different service URL (but the same responder key etc.), or, 
> is there a 
> general issue with correlating requests and responses? That 
> is, is the 
> fix likely to be alongs the lines of "include the service URL 
> in a signed 
> response" or "include a random value in the request and that 
> same value 
> in the corresponding response" 
> 
> 2. Could anyone who disagrees with using service URLs as 
> "trust selectors" 
> or who thinks we *need* to specify a finer-granularity of 
> something (whether 
> in request or response) please speak up in the next couple of days? 
> 
> Stephen. 
> 
> Rich Salz wrote: 
> > 
> > > You wouldn't actually need to have a different WSDL 
> description per URL. 
> > 
> > No, you don't HAVE to have them; I was putting too much on 
> the "private" 
> > notation made in the current spec about the service URL. 
> > 
> > I'd expect someone who was providing an outsourced service 
> would want to 
> > keep each binding in a separate file, but that's just a guess. 
> > 
> > > Either suggested approach for handling multiple trust 
> models would work. 
> > > I think the real issue is whether the folks planning to build such 
> > > services believe one of them makes their life simpler.  I 
> tend to favor 
> > > the URL model, but admit this view is based on fairly 
> limited thinking 
> > > about how I might want to deploy such a system. 
> > 
> > Same here. 
> > 
> > > I can't imagine clients trying to deal 
> > > dynamically with what trust models are supported by a 
> given service. 
> > > Going to web page to get info on supported trust models 
> (like current 
> > > CPS docs for CAs) seems adequate to me. 
> > 
> > Agreed. 
> >         /r$ 
> > -- 
> > Zolera Systems, Your Key to Online Integrity 
> > Securing Web services: XML, SOAP, Dig-sig, Encryption 
> > http://www.zolera.com <http://www.zolera.com>  
> 
> -- 
> ____________________________________________________________ 
> Stephen Farrell                                          
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716 
> 39 Parkgate Street,                     fax: +353 1 881 7000 
> Dublin 8.                mailto:stephen.farrell@baltimore.ie
<mailto:stephen.farrell@baltimore.ie>  
> Ireland                             http://www.baltimore.com
<http://www.baltimore.com>  
>