Re: Comments on S2ML 0.8a

["Mishra, Prateek" <pmishra@netegrity.com>]

1. 

+++++++

"The Holder element is introduced to provide within Name Assertions the

public key of the actor binding the name assertion to a payload using a

signature."

When I saw the phrase "the actor binding the name assertion", I assumed

that this was the issuer of the name assertion. Howver later text in

4.2.1 seem to suggest the holder field is the subject's public key. I am

confused. May be an example (or examples) would help resolve my

confusion?

++++++++
 
As you have suggested, there is a need to bind a name assertion to a
payload,
or, to somehow scope its use. Section 4.2.1 notes two use-cases for scoped
name assertions:
    "Two patterns of use are noted for scoped name assertions. In the first,
a subject (typically an end-user) without a   private/public key pair
presents credentials for authentication to a server together with a payload
for further processing. In this case, only the server can bind the resulting
name assertion to the payload by use of the server private key and must
include the server public key in the generated name assertion Holder
element. In this case, there is an assumption that the server is trusted and
can act on behalf of the user. 

In the second, a subject presents credentials to a server and receives a
name assertion which includes the subject public key in the returned name
assertion Holder element. The subject may now bind the name assertion to a
payload and submit the signed package directly to other servers. In this
case, there is no need to make an assumption that the server will act on
behalf of the user. "

I guess that in the first case, the server receiving the user credentials
could also be the name assertion issuer. 
But that is a specialization of the first case, not an extension of it. In
general, we do not assume that a name
assertion issuer would necessarily have any interaction with payloads.
 
 
2.
++++++++++++++++++++++

It is quite possible that I misunderstand the usuage model (and/or scoped
assertions), but I still think the binding between various S2ML fragments
that might appear in different documents may not be strong enough. I don't
see problems arising, if these fragments are exchanged through secure
channels and contents never disclosed. However, if the fragments are stored
in documents for later use, I can see problems

arising. The example entitlement on page 13 in the beginning of section

4, shows a URI to link the entitlement to a name assertion. If somebody

manages to put a resource up with the same URI problems will arise. John
Linn mentioned IP and DNS level spoofing in his posting a few days ago

in the context of the HTTP binding for 0.7a. I think the above may be
vulnerable to similar problems.

I guess the general question is: is a URI sufficiently secure link for
compound assertions to work?

++++++++++++++++++++++
 
One strong requirement in the specification is that each assertion has
a unique identifier associated with it (the <ID> element). This unique
identifier happens
to be a URI. There is no sense of location or binding to an actual web page
or anything
of that type associated with URIs. The <DependsOn> element from p.13,
Section 4, refers
to the unique identifier of an name assertion. Given that all assertion
elements must be
a cryptographically bound to an issuer, I see no security vulnerability
here.
 
3.
 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I am also worried about the linkage between AzResponse and AzRequest. Again
a URI is used to make the linkage, and the authorization question is not
repeated in the AzResponse. I think this could be made stronger by including
the question element from AzRequest in AzResponse.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

Similar to the comment above, Request and Response pairs carry unique <ID>s.
Further, each
Response message carries a <InResponseTo> element describing the <ID> of the
corresponding
<Request> message. The URI in question is precisely the <ID> element of the
Request. The
specification suggests that Request and Response elements be authenticated
and
secured using standard techniques tho' it does mandate the use of signing. 

 

4.

++++++++++++++++++++++++++++++++++++++++++

 

The HTTP binding suggests using the hash of URI as the SenderIdentifer

and also AssertionIdentifier. Presumably this is because of a concern

over the length of URIs that might appear in headers. This seems to

assume a model of closely coupled sites: one in which the URIs of the

sending site are already known in advanced. Thus the hash is sufficient

to identify the sender to whom the request for the assertion needs to be

sent. Is it possible to support more dynamic scenarios in which sending

sites might not be known in advance?

+++++++++++++++++++++++++++++++++++++++++++++++++

You are correct, the draft presumes that the sending site is known in
advance. The
framework in S2ML 0.8a assumes that there is a static trust relationship
between the actors that 
has been somehow configured or agreed upon in advance. It is certainly
possible to
weaken this assumption but it would also be good to have some use-cases to
support
such an extension. 

5.

+++++++++++++++++++++++++++++++++++++++++++++++++++

\begin{quote}

"For the case when the authentication service is invoked with public key

credentials, it MUST be used to complement existing authentication protocols
based on SSL or

document signature verification (XML-SIG, S/MIME). The intent here is to
separate out a

policy-driven component of authentication into a separate service which can
be shared, for example, by all servers in a web farm. It should not be
viewed as a replacement for existing authentication protocols."

\end{quote}
++++++++++++++++++++++++++++++++++++++++++++++++++++++

The concern here is the following: we are treating login credentials and
public-key
credentials in a parallel fashion. In the first case, validating login
credentials constitutes
a complete authentication step; in the second, determining public key
validity is only part of an authentication step
(e.g., SSL involves a  challenge-response step, S/MIME requires signature
verification). 
I am trying to highlight this distinction through the use of MUST in the
above statement. The statements
that follow provide some justification of the value of such a credential
validation service.

 

- prateek mishra