[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Comments on S2ML 0.8a
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC