[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-msg] RE: Note on current restricted scope of [ebxml-cppa]authenticati on policies/model in CPA/MSH
>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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC