RE: Correlation/Protection (Was: Re: XKMS)

Regarding Stephen's question as to what needs to be digested (and returned
in the response), it might not need to be the "entire request". For example,
for a <Validate> request, it may be sufficient to return a hash on the
<Query>. Based on Phil's write-up, this hash could be included with the
request as well (but verified by the server) but I don't think it needs to
be. In any case, we need to decide whether the requestor needs to be able to
dynamically indicate what should be hashed, or just statically define in the
spec (I prefer the latter as I believe Phill indicated as well).

Moving the digests to the SOAP header sounds fine so long as SOAP security
is used. Aren't we still going to define the option of including, for
example, an XML DSig element as part of the XKMS response. To me, this
indicates that any such hash would have to be included in the XKMS response.

Another point based on Phill's write-up. I may have misinterpreted the
description, but in case I didn't, I don't think that authenticated requests
(on their own) do anything to prevent the alteration of the request.
Consider Alice that sends a signed request to Bob.  Carol intercepts and
signs a different request for Bob. Unless the authenticated response from
Bob includes some reference to the request (e.g. a hash of it's relevant
information, or an indication of the sender's name) then Carol can
successfully substitue portions of Alice's request. 

Mike 




> -----Original Message-----
> From: Hayes, Mark [mailto:Mhayes@verisign.com]
> Sent: Wednesday, November 28, 2001 11:38 AM
> To: 'www-xkms-ws@w3c.org'
> Subject: RE: Correlation/Protection (Was: Re: XKMS)
> 
> 
> From an implementation point of view I think it would be much 
> better to move
> any such digests to a SOAP header, even if the SOAP header 
> must be defined
> by the XKMS spec for this version.  Then in the future the 
> implementation
> would change from one type of SOAP header to another rather 
> then changing
> the contents of the body.  Same applies to transaction IDs.
> 
> mark
> 
> > -----Original Message-----
> > From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
> > Sent: Wednesday, November 28, 2001 8:17 AM
> > To: 'stephen.farrell@baltimore.ie'; 'www-xkms-ws@w3c.org'
> > Subject: RE: Correlation/Protection (Was: Re: XKMS)
> > 
> > 
> > The same thought (digest of the request) had occurred to me 
> > simultaneously,
> > only I was typing up the note. The nice feature of that 
> > approach is that it
> > makes it much harder for a pinhead to code the interface in 
> > the wrong way so
> > that there is an implicit dependence on the authenticity of 
> > the request.
> > 
> > I think that the scope of the digest would be the body of the 
> > SOAP message.
> > i would like to see the idea raised at some point to the 
> > level of a general
> > SOAP security mechanism since the problem is pretty general.
> > 
> > 	Phill
> > 
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@verisign.com
> > 781 245 6996 x227
> > 
> > 
> > > -----Original Message-----
> > > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> > > Sent: Wednesday, November 28, 2001 5:05 AM
> > > To: 'www-xkms-ws@w3c.org'
> > > Subject: Correlation/Protection (Was: Re: XKMS)
> > > 
> > > 
> > > 
> > > (Changed the subject line to split two threads.)
> > > 
> > > I'd be a bit worried that digesting the entire message would 
> > > run into proxying/SOAP wrapping issues.
> > > 
> > > Do we need to be a bit more specific about what's digested?
> > > 
> > > Stephen.
> > > 
> > > 
> > > > Mike Just wrote:
> > > > 
> > > > That sounds like a good idea. One might argue that XKMS 
> > > already has the <Respond> element for
> > > > returning elements sent as part of the request but 
> > > <Respond> doesn't cover items such as the
> > > > Transaction ID and the service URL.  Phill's 
> > > <SigningContext> element (from
> > > > 
> > > http://lists.w3.org/Archives/Public/www-xkms-ws/2001Nov/0065.h
> > > tml) would add these items. However,
> > > > <Respond> doesn't return additional elements such as 
> > > <KeyId> that might be sent as part of a
> > > > <Query>. It seems safest to allow the return of the hash of 
> > > the entire request (or else someone
> > > > will likely break/attack any partial solution).
> > > > 
> > > > As for how the client requests this, maybe it could be 
> > > another <Respond> option; something like
> > > > <Respond>
> > > >         RequestReference
> > > > </Respond>
> > > > which would return an XMLDSig reference element computed 
> > > over the entire client request.
> > > > Phill's <SigningContext> would still be required I believe; 
> > > at least for the service URL (unless
> > > > we decide to include this as part of the request schema 
> as well).
> > > > 
> > > > (I might have thought that it would be mandatory to include 
> > > the RequestReference for the most
> > > > secure operation, but if the session were protected by TLS, 
> > > for example, then some correspondence
> > > > between the request and response would already be provided. 
> > > The spec would have to indicate these
> > > > security issues/options of course.)
> > > > 
> > > > Mike
> > > > 
> > > > > -----Original Message-----
> > > > > From: Rich Salz [mailto:rsalz@zolera.com]
> > > > > Sent: Tuesday, November 27, 2001 11:53 AM
> > > > > To: Mike Just
> > > > > Cc: 'www-xkms-ws@w3c.org'
> > > > > Subject: Re: XKMS
> > > > >
> > > > >
> > > > > That makes sense -- the server can return an element 
> > > XMLDSIG Reference
> > > > > element for the client request -- but how can the client 
> > > indicate it
> > > > > wants that? Or is that left as a quality of 
> > implementation issue?
> > > > >       /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
> > > 
> > 
> > 
>