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


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

Powered by eList eXpress LLC