[Go-essp-tech] [esg-node-dev] Re: Question on P2P and signing of registry docs

Tue Jun 7 04:52:53 MDT 2011

Hi Estani, I agree and thanks for providing some more clarity.

Gavin, the question to ask is, does any of your Hessian message payload need to persist beyond the immediate web service call or does it contain information asserted about nodes other than the sender?  If the answer is yes, then the information needs to be signed.

As to the registry document, XMLSec provides the simplest most clean solution in this case.  The signature(s) can be contained within the registry document envelope so you have a self-contained object which has
 * registry information about any number of nodes
 * the associated signatures to enable you to verify the information asserted by the different authoring parties (nodes)

These two together are independent of the underlying transport.  - We want this.

As Neill mentioned, there's a common Java package that implements the XMLSec spec.  It has an API so you can treat it as a black box and not be concerned with the inner workings of signature and XML canonicalisation.

Cheers,
Phil

From: Estanislao Gonzalez <gonzalez at dkrz.de<mailto:gonzalez at dkrz.de>>
Organization: DKRZ
Date: Tue, 7 Jun 2011 12:00:21 +0200
To: "Gavin M. Bell" <gavin at llnl.gov<mailto:gavin at llnl.gov>>
Cc: Philip Kershaw <philip.kershaw at stfc.ac.uk<mailto:philip.kershaw at stfc.ac.uk>>, "go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>" <go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>>, "esg-node-dev at lists.llnl.gov<mailto:esg-node-dev at lists.llnl.gov>" <esg-node-dev at lists.llnl.gov<mailto:esg-node-dev at lists.llnl.gov>>
Subject: Re: [esg-node-dev] Re: Question on P2P and signing of registry docs

Hi,

Maybe I got everything wrong, so please correct as required. I don't think the problem is about the "payload" itself, but more about securing what each node asserts about themselves. So very abstractly seen we *want* to have this:

_channel [SSL secured]
 _payload - [non secured xml or whatever the manager uses to connect nodes in the p2p]
  _nodeA_services [xmlsec signed by nodeA]
  _nodeB_services [xmlsec signed by nodeB]
  _nodeC_services [xmlsec signed by nodeC]

So that you can't play with the assertions performed at nodeA unless you crack it's private key. The weak link is probably the SSL connection, but as Phil mentioned you will just falsify one Node at most... to falsify all of them it means you can break RSA (or whatever we use) so probably you should better be targeting banks than us :-)

XMLsec is, AFAIK, just a way of signing an xml file (or in our case part of a file) and embedding the signature in it. The certificates I'd assume are centrally signed so only the CA should be trusted (as I said, this certificates does not require to be the ones used in the ssl connection). So you might trust any node it gets a CA signed cert not found in the CA's CRL (I hate acronyms, sorry for that).

Thanks,
Estani

Am 07.06.2011 00:39, schrieb Gavin M. Bell:
Hi,

By the way, to date I am still ignorant about xmlsec, however, I think it may be worth knowing that the xml that is sent around from client to server is not just xml but the payload of an encapsulating transfer object.  Indeed we can/should secure this payload, but I thought that this would be good information to have to better contextually set the parameters w.r.t. what we are trying to achieve.  So, at the moment the salient question perhaps would be, how do we secure the xml content, a separate mechanism from the xml transport?  I hope xmlsec is orthogonal w.r.t. transport.  (pardon my momentary lack of knowledge of xmlsec).

Yes, Philip we should try to use something separate just for this bit of functionality... I agree... cleaner.

On 6/6/11 1:38 AM, philip.kershaw at stfc.ac.uk<mailto:philip.kershaw at stfc.ac.uk> wrote:

ESGF is already using XMLSec but you have probably not realised ;)  Luca has used it to sign the SAML assertion set in the node session cookie.  This code is part of the Java OpenSAML library.  For the registry it would be cleaner to use the separate underlying XMLSec implementation.   I will ask Neill (unless he's reading this) as he will probably know.

Phil

From: "Gavin M. Bell" <gavin at llnl.gov<mailto:gavin at llnl.gov><mailto:gavin at llnl.gov><mailto:gavin at llnl.gov>>
Date: Thu, 2 Jun 2011 09:58:42 -0700
To: Philip Kershaw <philip.kershaw at stfc.ac.uk<mailto:philip.kershaw at stfc.ac.uk><mailto:philip.kershaw at stfc.ac.uk><mailto:philip.kershaw at stfc.ac.uk>>
Cc: "go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu><mailto:go-essp-tech at ucar.edu><mailto:go-essp-tech at ucar.edu>" <go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu><mailto:go-essp-tech at ucar.edu><mailto:go-essp-tech at ucar.edu>>, "esg-node-dev at lists.llnl.gov<mailto:esg-node-dev at lists.llnl.gov><mailto:esg-node-dev at lists.llnl.gov><mailto:esg-node-dev at lists.llnl.gov>" <esg-node-dev at lists.llnl.gov<mailto:esg-node-dev at lists.llnl.gov><mailto:esg-node-dev at lists.llnl.gov><mailto:esg-node-dev at lists.llnl.gov>>
Subject: Re: Question on P2P and signing of registry docs

Indeed,

Okay... so interested parties should 'sit down' and hash this out (pun intended) :-).
If you think XMLSec is the way to go, and you have documentation that you feel would be particularly helpful to getting up to speed on it, please send it out.

And ofcourse we want to *keep it simple*, whatever we do.

P.S.
Now that we are going to be in crypto land, we need to simultaneously get the ball rolling on any export issues so by the time we are done implementing the legal eagles have sorted that stuff out as well so we don't get stymied later.

On 6/2/11 2:18 AM, philip.kershaw at stfc.ac.uk<mailto:philip.kershaw at stfc.ac.uk><mailto:philip.kershaw at stfc.ac.uk><mailto:philip.kershaw at stfc.ac.uk> wrote:

However, this p2p scenario inevitably brings in to play the need for
digital signature.  The key issue is that when I pass a registry document,
to another peer I assert information about myself but also information
about other peers too.

So, we all trust each other so what's the problem?  Imagine a node is
compromised and then look at the consequences.

1) Without signature.  I with the compromised cert can modify my own
registry doc but I can also assert any rubbish I like about anyone else's
2) With signature.  I can modify my own registry entry but much as I might
want to, I can't modify anything about anyone else's because they're all
signed.

--
Gavin M. Bell
Lawrence Livermore National Labs
--

 "Never mistake a clear view for a short distance."
               -Paul Saffo

(GPG Key - http://rainbow.llnl.gov/dist/keys/gavin.asc)

 A796 CE39 9C31 68A4 52A7  1F6B 66B7 B250 21D5 6D3E

--
Gavin M. Bell
Lawrence Livermore National Labs
--

 "Never mistake a clear view for a short distance."
               -Paul Saffo

(GPG Key - http://rainbow.llnl.gov/dist/keys/gavin.asc)

 A796 CE39 9C31 68A4 52A7  1F6B 66B7 B250 21D5 6D3E

--
Estanislao Gonzalez

Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany

Phone:   +49 (40) 46 00 94-126
E-Mail:  gonzalez at dkrz.de<mailto:gonzalez at dkrz.de>
-- 
Scanned by iCritical.