OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-security message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: XML DSIG for authentication

Sekhar, good wrietup. One comment ...
The solution that you have outlined for use case 6
probably makes one more assumption ..
   After authenticating the Registry Operator by the first
   non business sensitive interaction, further interactions
   are guaranteed to be with the same Registry Operator by
   means of some persistent Session. i.e. it is necessary that
   a Session be established by the first interaction for creating
   sufficient context for authenticating further interactions.
Is my understanding correct??

Sanjay Patil
Total Business Integration (TM) 
Phone: 408 350 9619                                 http://www.iona.com

-----Original Message-----
From: sekhar vajjhala [mailto:sekhar.vajjhala@Sun.COM]
Sent: Thursday, September 20, 2001 1:28 PM
To: regrep-security@lists.oasis-open.org
Subject: XML DSIG for authentication

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

Note that the Registry Operator cannot be authenticated until a message
sent. However, a Registry Client may want to authenticate the Registry
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
or someother call in V2.0.

If the response is not signed by correctly by the registry, then this
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 
2. if the signature validation fails in this first message, then 
   the Registry is not authenticated. Further security sensitive
   should not be made.
3. If the signature validation succeeds then the Registry is

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 ?


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