|
[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
|