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,

	I also faced the same problems designing security in V1.0 :o( From my
limited knowledge, there is no session requirement till now. All registry
operations are atomic and any context would be carried in the message and
managed by the client. i.e. the registry server never needs to have any
session associated with a user. The best one can do is to return a session
token to the client which the client manages actively i.e. the session token
would be a parameter in the call !

	BTW, good document. I am working on XML Signature for SAML and plan to
model my doc on yours. I also might bug you with some questions on XML
Signature.

	Sanjay/Sekhar, if you folks have any strong ideas or issues to be aware of
on XML signature (and SAML) pl let me know.

cheers

  |-----Original Message-----
  |From: Sekhar.Vajjhala@Sun.COM [mailto:Sekhar.Vajjhala@Sun.COM]
  |Sent: Thursday, September 20, 2001 2:10 PM
  |To: Patil, Sanjay
  |Cc: regrep-security@lists.oasis-open.org
  |Subject: Re: XML DSIG for authentication
  |
  |
  |
  |"Patil, Sanjay" wrote:
  |>
  |> 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??
  |>
  |> thanks,
  |> Sanjay Patil
  |
  |Sanjay,
  |
  |Your understanding is exactly right. The solution would work
  |only if there was a Session. However, I wasn't making an assumption
  |about there being a session. I was thinking that the session
  |existed because of the sequence of calls i.e.
  |
  |1. first RegistryInterface() would be called. This is not a
  |   security sensitive operation.
  |
  |2. Further calls would be made on the methods on the Object
  |   obtained from the RegistryInterface() operation and so on.
  |   So this operation must be to the Registry in step 1 and
  |   not some other Registry.
  |
  |Am I missing something ?
  |
  |Sekhar
  |
  |>
  |-----------------------------------------------------------------
  |-----------
  |> ------------------------------
  |> IONA
  |> 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
  |> 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>
  |
  |--
  |Sekhar
  |
  |----------------------------------------------------------------
  |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