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
>