Re: XML DSIG for authentication

[Prasad Yendluri <pyendluri@webmethods.com>]

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