[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: XML DSIG for authentication
Prasad, You are absolutely right. This is a generic problem, and needs to be solved generically. There are really two solutions for this problem. 1. Challenge-response: RC challenges RO and vice versa. (as Sekhar as described in detail). Note that the goal here is to make sure that RO has the private key that it claims it has. (btw, in Sekhar's solution, the call to RegistryService should include a message *specified* by RC that RO needs to sign - may be Sekhar implied this). The problem is, as Sanjay has noted, the need for a session that allows for challenge-response to take place at the beginning of the session. We don't have the notion of a session with registry as noted by Krishna. 2. Transport level authentication: This solution defines the problem away from messaging layer. From a practical point of view, this solution will work, at least when SSL is used between RC and RO. Team, I propose that we revisit our earlier decision of "not depending" on transport layer authentication and say that peer authentication is assumed to be done by the transport layer (say, SSL). We can qualify this assumption by saying that this decision may be revisited when Registry transactions have the notion of a session. Comments? Regards, -Suresh -----Original Message----- From: Prasad Yendluri [mailto:pyendluri@webmethods.com] Sent: Thursday, September 20, 2001 5:13 PM To: Sekhar.Vajjhala@Sun.COM Cc: regrep-security@lists.oasis-open.org Subject: Re: XML DSIG for authentication Sekhar (et al), This seems to be a problem that should be fed into and perhaps belongs in the messaging service and not something specific to the Registry alone. That is in general Parties A and B would like to authenticate each other and make sure the contest exchanged between them is trusted / authentic etc. The registry specific use cases can be fed into the messaging service effort. Something to consider as MS is going through revision simultaneously. Best regards, Prasad Yendluri -------- Original Message -------- Subject: XML DSIG for authentication Date: Thu, 20 Sep 2001 16:27:58 -0400 From: sekhar vajjhala <sekhar.vajjhala@Sun.COM> Reply-To: Sekhar.Vajjhala@Sun.COM Organization: Sun Microsystems To: regrep-security@lists.oasis-open.org 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 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC