[ebxml-msg] Note on current restricted scope of [ebxml-cppa]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] Note on current restricted scope of [ebxml-cppa]authentication policies/model in CPA/MSH




From: Dale Moberg <>
To: "Ahmed, Zahid" <>, 
Date: Thu, 17 Jan 2002 17:05:39 -0700









 
Zahid Admed writes:
 " 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 certifcate is issued by a trusted CA.  "
 
Thanks for raising 
some questions. I am responding to the first part of your 
message here.
I hope to respond to the 
remainder of your proposals soon. I will take your 
concern
with "only mutually 
trusted parties should be able to connect" to be a concern 
with
authentication/authorization and not a literal concern 
with preventing abuse of 
connecting (DOS type 
concerns).
 
The TrustAnchors and the 
correlative certificates provide a means to reach 
agreements
for interoperable 
PKI operations (such as signing, key exchange, and transport 
authentication)
where certificate 
validity/trust is typically checked. At present, we are attempting to 
meet the
explicit suggestions of 
the ebXML Security group, and are not delving into larger 
areas
of PKI trust management 
(like CRL checking policies). So we are attempting to allow 
an
agreement to be made 
where both parties can tell that the certificate-checking 
side
can validate the 
certificate of the certificate using side ( the signer's cert for 
signatures,
the key exchange cert of 
the receiver for digital envelopes, etc.). That is about all 
we
aspire to at this point 
in introducing the SecurityDetails. So we would agree, the 
details
are surely not detailed 
enough to express all nuances subject to agreement 
involving
PKI management policies. 
We do think that we can promote PKI 
interoperability
by being able to 
configure systems so that certificates can be chained to 
root
during validity checks. 
(We will allow agreements to use self signed 
certificates,
and this will be done by 
augmenting TrustAnchors during CPA formation to 
include
the self-signed 
certificate ...)
 
You are also right 
in noting that specifying trust anchors does not in itself constitute a 
complete
authentication policy-- 
it is at best a component of the authentication 
policy.
Explicit checks on the 
DN, issuer serial number, etc might be used to check 
identity.
And identity might be 
variably mapped (ACLs) to resources depending on 
service,
action, 
role, and other parameters. Those more elaborate authorization issues 
are not things
treated in the current 
maintenance version. We are waiting to review 
specs
of other groups before 
taking on authentication or authorization. 

Agreements on 
credentials for username/password tokens will need to use 

encryption,  for 
example, so we are waiting on xml encryption being 
available.
The SAML and XACML 
groups may eventually produce specs usable 
for
some security policy 
expressions. So we are in a way avoiding 
getting 
into too much
detail here while 
some other supporting specs get finished. 

 
I will try to respond to 
your constructive suggestion in a separate message. 













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

--

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


  









Powered by eList eXpress LLC