[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: XML DSIG for authentication
One of the deliverables that was planned for ebXML Registry 2.0 was > 2. Application of XMLDSIG to Registry use cases (data integrity, authentication) (Sekhar) I would like to focus on the issue of use of XMLDSIG for authentication. The use cases for authentication are Use Case 5 and Use Case 6 which are basically: Use Case 5 : Authentication of Registry Client to Registry Operator. Use Case 6 : Authentication of Registry Operator to Registry client. I did not include these use cases in the "Use of XML DSIG in ebXML Registry" document that I sent around earlier today because I was not clear on how to handle the above cases (or the assumptions that need to be made). Here is a way to handle the cases. Authentication can be done at several layers. It was pointed in the conference call that authentication should be based on "message level authentication" not other layers. For e.g. there should be no reliance on transport level authentication. Assuming this is the case, here is how I think we can deal with the above cases. Use Case 6: ----------- A Registry Client could authenticate a Registry Operator as follows: 1. sending a message to Registry Operator 2. Receving a signed response from the Registry Operator - the response being signed by the Registry Operator. 3. Registry Client validates the signature of the Registry Operator. 4. If the validation succeeds then the Registry Operator is authenticated. Note that the Registry Operator cannot be authenticated until a message is sent. However, a Registry Client may want to authenticate the Registry Operator before the first message is sent. To solve the above chicken and egg problem, I would like to make the following assumption: At least as per V1.0 spec, the first operation that a Registry Client performs would be a call a method in the "RegistryService" interface. This could be (getObjectManager() or getQueryObjectManager()). or someother call in V2.0. If the response is not signed by correctly by the registry, then this call would fail. Then the security sensitive operations such as submitting content would be aborted. So in summary, the assumptions are: 1. the first message to the Registry is not a security sensitive operation. 2. if the signature validation fails in this first message, then the Registry is not authenticated. Further security sensitive operations should not be made. 3. If the signature validation succeeds then the Registry is authenticated. With the above assumption, nothing special needs to be done to handle this use case. Use Case 5 =========== The way this is currently handled is that a Registry Client is authenticated if the validation of Registry Client's signature succeeds. Note that this does not protect against a replay attack but that has already been determined to be out of scope. Comments ? -- Sekhar
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC