[ebxml-msg] authentication policies/model in CPA/MSH

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

[NOTE: This is somewhat related IssueID 117.]

 

I am reviewing the latest draft of tye CPA/CPP spec and I'm pleased to see that we have

broken down the TransportSecurity into its corresponding TransportClientSecurity and

TransportServerSecurity components.

 

However, I'm concerned about the current definition of SecurityDetailsRef. While the

TrustAnchor element will be used to specify all the Trusted CA Roots that an end-point

may be able to use to validate a SSL certificate chain is signed by a trusted issuer,

an important authentication policy that we need to be able to satsify is that only

mutually trusted parties should be to connect via their target MSH's.

 

To give a concrete example, I'm not sure if usage of trusted anchors is sufficient to satisfy

the above requirement of ensuring that trust-worthy ebXML sending party (or sending MSH) can

only communicate over the required transport (e.g., HTTPS) with receiving party (or receiving

MSH) if and only if sending party's client certiifcate is issued by a trusted CA. E.g.,

the receiving party may have in its trust anchor Verisgn Global Server Roots. That means

that the receiving MSH will end up trusting any client certificate from the sending party

(sending MSH) provided its issued by Verisign Global Server. W/o some access control

and trust policy the receiving MSH could be exploited with DOA attacks.

 

So, how do we provide an option for ebXML implmentors to support transport

level access control to ebXML MSH for the above SSL mutual authenticaiton

scenario? Do we inclue this in the CPP or assume that it is local server confguration

detail?

 

My suggestion is that we enhance the SecurityDetailsRef to support TrustedClients

in additions to TrustedAnchors. We may even consider a broadening the notion of

TrustedClients in the sense of TrustedSites, meaning that we allow configuration of domain

level trust between 2 MSH, which can be used to prevent, to some extent, DOA at

the transport/site level.

 

E.g.,

 

        <element name="SecurityDetails">
                <complexType>
                        <sequence>
                                <element ref="tns:TrustAnchors" minOccurs="0" maxOccurs="unbounded"/>> 

                                <element ref="tns:TrustedClients" minOccurs="0" maxOccurs="unbounded"/>>
                                <element ref="tns:SecurityPolicy" minOccurs="0" maxOccurs=unbounded"/>>
                                <any namespace="##other" processContents="lax" minOccurs=unbounded"/>>
                        </sequence>
                        <attribute name="securityId" type="ID" use="required"/>
                </complexType>
        </element>
        <element name="TrustClients">
                <complexType>
                        <sequence>
                                <element name="TrustedClientCertificateRef" type="tns:CertificateRef.type" maxOccurs="unbounded"/>
                        </sequence>
                </complexType>
        </element> 

 

 

If we do not have some kind of Client Trust Policy for transport level authentication factored into

the CPA/CPP, then I believe ebXML implementors will need to include that type of a behaviour

in their MSH site level configurations anyway. There has been some discusion in the MSH

on non-persistent authorization (Sectuin 4.1.4.8), but it seems to imply that such authorizations

are done out-of-scope of CPA/CPP, i.e., via local (SSL/TLS) transport configurations.

 

Also, it may be helpful, on a higher-level, to include discussion of how authentication events

at the transport level, message level, and document levels provide an end-to-end authenticated

message/document exchanges between 2 parties using MSH.

 

thanks,

Zahid