RE: XML DSIG for authentication

[Krishna Sankar <ksankar@cisco.com>]

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>
  |