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 05:54:15 UTC