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]
> 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
> 
> -- 
> ____________________________________________________________
> 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
> Ireland                             http://www.baltimore.com
>