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

MHonArc v2.5.2 -->
















ebxml-msg message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








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




From: "Ahmed, Zahid" <>
To: 
Date: Thu, 17 Jan 2002 14:03:58 -0800










[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
 

     












[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]


  









Powered by eList eXpress LLC