[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: XML DSIG for authentication
Krishana et al, Authentication is assumed before authorization, and therefore, you are right, if authentication fails, we can't guarantee any authz. I would treat authZ and authC as different problems, though. I am curious about the TRP API issue. Like to know more. Please post more info, if you know. Registry XMLDSIG Signatures are expected to ride on MSG - since that is the only messaging layer we can consider. Farrukh, it will be interesting to see RAWS implications. Cheers, -Suresh -----Original Message----- From: Krishna Sankar [mailto:ksankar@cisco.com] Sent: Thursday, September 20, 2001 7:22 PM To: Damodaran, Suresh; 'Prasad Yendluri'; Sekhar.Vajjhala@Sun.COM Cc: regrep-security@lists.oasis-open.org Subject: RE: XML DSIG for authentication Suresh et al, If I am correct, we would also be using the authentication information to resolve roles as well. It is not only a question of authC but also authZ. So assuming a secure wire might not solve the problem. Unless of course we should say that the APIs which would update/create/delete can be accesses only thru https. Then how would we prevent somebody changing somebody else's information ? As you know, UDDI's solution is to do authC and then return a session token. Prasad, come to think of it, I am not sure that this is a message level issue - for more than one reasons : 1) We cannot assume any particular msh, could be BEEP, ebXML, ... 2) There is no message level API which we (as in upper layers) can talk to - for example to get the authentication assertion (to correlate the userID with the registry userId) or even to find out if the user is authenticated. I had raised this long time ago with the then ebXML TRP and the reply was that they are working on an API layer. Am I rambling or are these genuine issues ? cheers |-----Original Message----- |From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com] |Sent: Thursday, September 20, 2001 5:07 PM |To: 'Prasad Yendluri'; Sekhar.Vajjhala@Sun.COM |Cc: regrep-security@lists.oasis-open.org |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> | |---------------------------------------------------------------- |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