- From: Srinivas, Davanum M <Davanum.Srinivas@ca.com>
- Date: Sat, 12 Mar 2005 14:15:49 -0500
- To: "Rich Salz" <rsalz@datapower.com>, <public-ws-addressing@w3.org>
- Message-ID: <87527035FDD42A428221FA578D4A9A5B055EBCCD@usilms24.ca.com>
Hi Rich,
My head is spinning...thanks for the great post.
"The previous paragraph is perhaps the key to this whole message.
It details a lot of work. It will be hard for implementors to get
it right. It is not currently supported by any toolkits that I am
aware of."
Question #1: If we add the wsa:Security, will it make it automatically usable with current toolkits? (or) will it just show everyone how to implement this (if they read our spec and make changes to their existing toolkits)?
Question #2: Are there changes we can make that will make this scenario work with existing toolkits? (i guess not, if it were you would not have had to write this long email. right? :)
thanks,
dims
-----Original Message-----
From: public-ws-addressing-request@w3.org on behalf of Rich Salz
Sent: Sat 3/12/2005 12:54 AM
To: public-ws-addressing@w3.org
Cc:
Subject: trust model and epr security
I promised Marc Hadley that I'd provide a worked example of signed
EPR data. In order to avoid getting drowned in angle brackets,
let me provide a semi-worked example here.
There are three parties involved:
Target server
EPR minter
Client
Since the WG is not defining an EPR service, the actual communication
with the EPR-minter is out of scope. For simplicity, let's assume
that entities use SOAP over HTTPS.
Namespace prefixes used below:
tns,yatns -- random application namespaces
ds -- XMLDSIG namespace (w3c spec)
wsse, wsu -- WS-Security and its utility namespace
When the Target-server registers with the EPR minter, it includes
a refp that it wants all clients to use. Let's call it an
Affiliate. Since the server generates the refp, and is the only
party who has to verify it, it will use an HMAC signature with a
key that only it knows. In order to do this, the following two
elements are provided to the EPR minter for it to pass back.
<tns:Affiliate tns:id='affil'>Amazon-1234</tns:Affiliate>
<ds:Signature>
<ds:SignedInfo>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
<ds:Reference URI='#affil'>
...
</ds:Reference>
...
</ds:SignedInfo>
<ds:SignatureValue>...</ds:SignatureValue>
<ds:KeyInfo><ds:KeyName>
Name of Server Secret Key
</ds:KeyName></ds:KeyInfo>
...
</ds:Signature>
The EPR minter may include other refp's. They may come from the
minter itself, or they may come from third parties. The minter
and the server do not share a key, but the server does know the
X.509 Distinguished Name of the minter, and the server trusts the
corporate CA. It has a copy of the CA's certificate (or public
key) that it got via a trusted out of band channel. This means the
server can build a "trust chain" that lets it trust refps signed
by the EPR minter.
For example, the minter could add a "chargeback" element, specifying
who the server should charge for the service. Therefore the minter
will add the following two elements:
<yatns:ChargeBack wsu:id="cb">
4033 - Travel/Entertainment
</yatns:Chargeback>
<ds:Signature>
<ds:SignedInfo>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI='#cb'>
...
</ds:Reference>
...
</ds:SignedInfo>
<ds:SignatureValue>...</ds:SignatureValue>
<ds:KeyInfo><ds:X509Data><ds:X509Certificate>
...base64 cert...
</ds:X509Certificate></ds:X509Data></ds:KeyInfo>
...
</ds:Signature>
An interesting question now comes to mind. Who knows that the two
attributes -- /tns:Affiliate@tns:id and /yatns:ChargeBack@wsu:id --
are attributes of type ID?
The client now contacts the EPR minter, and gets an EPR back.
The above four elements -- tns:Affiliate, ds:Signature,
yatns:ChargeBack, and the second ds:Signature -- get packed into
wsa:ReferenceParameters. "Trusting" the minter, and making sure
the data hasn't been modified, is out of scope.
The client is now going to use the EPR to contact the server
via SOAP. So it turns those refps into SOAP headers. It adds a
"wsa:isReferenceParameter" attribute. The original signers must
make sure that their signatures explicitly exclude that attribute.
The same issue comes about if refps can be targeted. The
signatures above would most likely do this by including an XPath
transform asa ds:Transform element inside the ds:Reference element.
The client now wants to sign its message and all headers. How can
it identify the two refp's? An XPath expression pointing to
the element by QName within the SOAP Header is possible (I think
xml->infoset->xml/xpath model preserves all the necessary info),
but awkward. Most toolkits will want to add or use an ID attribute.
The only safe thing (from a loosely coupled approach) is for
the client to add its own ID attributes. If the client is using
WS-Security, it might recognize any existing wsu:id attribute;
note that one of the refp's above does so. The server-provided
refp uses a private ID attribute because nobody else can verify
its element (lacking the key).
The client creates its message; note that it added a
/tns:Affiliate@wsu:id attribute. The server and minter must make
sure that their signatures allow this. For example, the XPath
transform would probably explicitly exclude all attributes. I can
show an example of this if desired.
Here is the message with the EPR/SOAP binding performed:
<SOAP:Envelope>
<SOAP:Header>
<tns:Affiliate tns:id='affil' wsu:id='n1' wsa:isReferenceParameter='true'>
Amazon-1234
</tns:Affiliate>
<yatns:ChargeBack wsu:id="cb" wsa:isReferenceParameter='true'>
4033 - Travel/Entertainment
</yatns:Chargeback>
<ds:Signature>...first signature...</ds:Signature>
<ds:Signature>...second signature...</ds:Signature>
<!-- See below -->
</SOAP:Header>
<SOAP:Body wsu:id='Body'>
<myns:foo>
...
</myns:foo>
</SOAP:Body>
</SOAP:Envelope>
The client now adds a WS-Security SOAP header and its own digital
signature that covers the entire message (including the other SOAP
headers shown above). For simplicity, only the security header is
shown below:
<wsse:Security>
<wsse:BinarySecurityToken EncodingType="wsse:Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#x509v3">
...client's certificate, in base64 encoding...
</wsse:BinarySecurityToken>
<ds:Signature>
<ds:SignedInfo>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI='#cb'>...</ds:Reference>
<ds:Reference URI='#n1'>...</ds:Reference>
<ds:Reference URI='#Body'>...</ds:Reference>
...
</ds:SignedInfo>
<ds:SignatureValue>...</ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#mycert"/>
</wsse:SecurityTokenReference>
</ds:X509Certificate></ds:X509Data></ds:KeyInfo>
...
</ds:Signature>
</wsse:Security>
When the server receives the message it will have to do its "standard"
WS-Security processing. In addition, it will have to look for any other
ds:Signature elements and process them to. In order to make sure that
everything was properly signed, it will have to track down the ds:Reference
elements and match up the URI attributes with the nodes and make sure
that the right items appear; it will also have to make sure that they
were signed by the right entity (a chargeback element signed by the
client isn't to be trusted, e.g.)
The previous paragraph is perhaps the key to this whole message.
It details a lot of work. It will be hard for implementors to get
it right. It is not currently supported by any toolkits that I am
aware of.
In a previous message, I proposed that a wsa:Security element be added
to the EPR. I can revise this message to show where the elements get
shuffled around, if there's interest. I won't do it here because
this message is already very long.
/r$
--
Rich Salz Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
Received on Saturday, 12 March 2005 19:15:50 UTC