Re: XML DSIG for authentication

[Prasad Yendluri <pyendluri@webmethods.com>]

Hi Krishna,

Krishna Sankar wrote:

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

Are we divorcing ebXML MS totally and expect this to run on any SOAP complaint protocol
including ebMS? Sekhar's description refers to ebXML header and its use of ds:Signature element.
So, I take we are still scoping for ebMS as the primary TRP right?

Also AFAIK BEEP is like HTTP over which we typically layer ebXML MS (SOAP) etc.

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

Yes, the APIs are in the scope for next phase. Also, Sekhar was proposing this as 2.0 item.
Hence it seemed good to influence ebMS rather than devise a scheme that ebMS may or may night
end-up aligning with. IMO the mechanism of how where dsigs get incorporated into the message
format should come from MS with ebRS defining the semantics and requirements over and above it.
I mean things like using the authentication information to
resolve roles as well etc.

Like you usually say my two yens..

>         Am I rambling or are these genuine issues ?

Both, I guess ..  :)

> cheers
>

Regards, Prasad

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