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:]
Sent: Thursday, September 20, 2001 7:22 PM
To: Damodaran, Suresh; 'Prasad Yendluri';
Cc:
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:]
|Sent: Thursday, September 20, 2001 5:07 PM
|To: 'Prasad Yendluri';
|Cc:
|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:]
|Sent: Thursday, September 20, 2001 5:13 PM
|To:
|Cc:
|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 <>
|Reply-To:
|Organization: Sun Microsystems
|To:
|
|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>
|
