[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Comments on S2ML 0.8a
Hi, I have a few comments and questions on the S2ML specification, version 0.8a It seems to me that one of the major differences between 0.8a and 0.7a is the introduction of scoped name assertions. Having only just read 0.7a, I was about to post a comment to the list concerning the need for a stronger (cryptographic) coupling between entitlements and name assertions. Clearly folks have started thinking the same thing as is evidenced by the discussion of name theft and impersonation in the introduction to section 4.2 I was going to suggest using public keys for scoping (similar to the ideas in SPKI and SDSI). However, I struggled to understand the text in 4.2.1. When I read the first paragraph it seemed that the public key contained in the holder element was the issuer of the name. "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? 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? 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. 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? I have one minor comment on some details. On page 15 in section 4.3 the draft has a paragraph (quoted below) which talks about separing out policy driven authentication components. I couldn't really understand what this was trying to say. Again possibly an example would help. \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} -- Nigel Edwards <nigel_edwards@hp.com> tel: +44 (0) 117 3128490 (HP telnet 3128490) Mobile/Cell: +44 (0) 7785 385 314 (From USA for Cell phone dial: 011-44-7785-385-314) http://www.e-speak.hp.com/ http://www.hp.com/security/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC