[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]authentication policies/model in CPA/MSH
Zahid Ahmed writes: " 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 fromthe CPA/CPP's TrustAnchor, i.e., Trusted CA Roots information, then we should also be able to maintain TrustedClient or TrustedDomains information." The CPA itself binds the two parties into a relationship, and trust (supported by PKI sub agreements) is part of the overall documented agreement. In other words, when client side SSL authentication is agreed to, the certificate used by the client is referenced in the CPA. The TrustAnchors are also listed, and in a workable agreement, the client SSL certificate must validate with respect to the anchors (for economy, the TrustAnchor in a CPA may be only the one(s) relevant to certificate validity of the correlative certificate. It seems to me that the proposed "TrustedClient" element may already be covered/handled by the element with type CertificateReference.type. This certificate is the specific one to be used in the PKI operation agreed to in the CPA. So this cert. is one of the trusted client ones. (At any rate, the requirement for Transport security was that there should be ways to indicate a Server cert, a client cert, the TAs for the server cert, and/or the TAs for the client cert. The path for the CertificateRef.type element should be a sibling to the SecurityDetailsRef. Remember, though, that in the CPA, the TAs "go with" the CertificateRef on the other PartyInfo's corresponding element. I believe, or more accurately, I hope that the explanatory text explains this.) Let me know if you have something completely different in mind. The notation is hopefully no more complex than what is being represented. I certainly agree that we have a lot of tacit and inexplicit items connected with security, authentication, and authorization. The exact checking procedure(s) to be used and the access permissions (ACLs) associated with these SSL client checks are not yet documented and so are implementation dependent. In a way, that is even true when we come to digital signatures (ebMS XMLDsig signatures). That is, ebXML specifications do not explicitly mention what ACLs get tickled when the message signature checks out (nor even all the checks involved); presumably enough rights are granted to get the payload to the application destination somehow. It might be worth mentioning all the checks that "might" be made: there might be a check that the certificate used in the ebMS signature is one approved for the service, action, cpaid, and "from" values. Otherwise, a signature could be valid, the cert chain valid, the certificate one that is _a_ "TrustedClient" cert, but still a renegade approved user could be trying to spoof a request by pretending to be another user in the "from", cpaid and other fields. (or trying to make a request for a response that was not yet agreed to). I am not certain how risky this threat is, and it would be pretty easy to track down a plausible suspect once the problem gets detected!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC