RE: Note on current restricted scope of [ebxml-cppa] authenticati onpolicies/model in CPA/MSH

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

>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.
 
 
I'm concerned Transport Security Policy is including informatioon about
Trusted CA
issuers (as part of TrustedAnchors) and not TrustedClients, which means that
transport
security information is incomplete w.r.t. capturing of relevant
authentication policy 
information. In the specific example of SSL mutual authentication (for which
the CPA/CPP 
spec has included relevant TransportClientSecurity and
TransportServerSecurity 
components) between 2 colloborating parties' MSHs if we will exploit from
the CPA/CPP's
TrustAnchor, i.e., Trusted CA Roots information, then we should also be able
to
maintain TrustedClient or TrustedDomains information.
 
In my original suggestion of including TrustedClient information in the
SecurityDetails
element:
 
 
        <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> 
 
 
the intention is that we validate the incoming client cert chain using
TrustedAnchors and
then validate that incoming client is trusted using the TrustedClients or
TrustedDomains
of the receiver. This is a simple DN level authorization. If we decide not
to include any 
TrustedClient element in the SecurityDetails, i.e., such trust policy info
will not be available in
the CPA, then we will need to atleast point that out that as a system
configuration step of 
the receiving MSH such authentenctication policies will need to be enforeced
via local 
adminsteration of the transport system, e.g., web server. TrustedClient or
TrustedDomain 
scope could be applicable to botuh Transport and Message level security.
E.g.,
some discussion needs to be added to Sections 1.2.3 (Opperational Policies
and
Constraints) and/or 4.1.4.8 (Non-Persistent Authorization).
  
>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'm particpating SAML group which definitely needs to be applied to ebXML
messaging.
I believe we have had some discussions about this before in this group.
 
However, I think we should separate out the layers of authentication events
and
include a general section in the ebXML Messaging specification that spells
out
the Authentication Mode for Messge Exchanges. For example, I propose
addition in the ebXML Messaging spec something along the following:
 
=============================================================
ebXML Authenticated Message Exchange Model
ebXML Messaging system supports:
 
1) Transport-level authentication (e.g., SSL mutual authentication for HTTPS
transport option)
2) Message-level authentication
3) Document-level authentication
 
SSL certificate based mutual authentication is applicable to transport level
security (e.g.,
over HTTPS) to verify trustworthy connection sessions between ebXML
parties's sending and receiving
transprot systems (MSHs), for example over the HTTPS protocol.
 
Digital Signature over the ebXML message and/or explicit application of SAML
based 
Credential is applicable to the message level security in support of
authentication
of message originating party. Both of these may be used independent of
transport security 
and can provide application level authorizations.
 
Document-level authentication provides capabilities to verify the identities
of document
originators, which may or may not be the same principals as message
originators.
===============================================================
 
 
Obviously, the lack of a concrete transport independent authentication and
authorization scheme being employed in ebXML seems to be the root problem
here.
 
---Zahid
 
 

-----Original Message-----
From: Dale Moberg [ mailto:dmoberg@cyclonecommerce.com
<mailto:dmoberg@cyclonecommerce.com> ]
Sent: Thursday, January 17, 2002 4:06 PM
To: Ahmed, Zahid; ebxml-msg@lists.oasis-open.org
<mailto:ebxml-msg@lists.oasis-open.org> 
Cc: CPPA
Subject: Note on current restricted scope of [ebxml-cppa] authentication
policies/model in CPA/MSH 


 
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.