[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Comments on S2ML 0.8a
Hi Prateek, Thanks for your response. I am still worried about the strength of using URIs for compound assertions. Let me try to elaborate below. Regards, Nigel. > > 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. What I am trying to do is to explore the boundaries of the system and understand what it depends on. As I understand it, compound assertions do make use of URIs and are therefore depend on the the particular URI being used. URIs can he http URLs, but I don't think HTTP URLs work. So the question is what kind of URIs will work? To take an example consider an entitlement that will grant put/post access on the S2ML spec. This entitlement is linked with the following URI in the <DependOn> element to a Name Assertion: http://www.foo.com/PrateekMishra Both the Name Assertion and Entitlement are cryptographically bound to their issuer (i.e. signed). Suppose there is another entitlement that will grant read access to the S2ML spec. This entitlement is linked to the following URI for a Name Assertion: http://www.foo.com/NigelEdwards If somebody manages to hack the web server and switch the objects at http://www.foo.com/PrateekMishra and http://www.foo.com/NigelEdwards then the system has broken. Similarly if sombody breaks the DNS system to fool a host into wrongly resolving www.foo.com, the system might also break. I believe it is possible to come up with URI schemes that are not vulnerable to the above problems, possibly by including a hash of the the object to which the URI is pointing as part of the URI scheme. > > 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. > > I think it's OK if AzRequest and AzResponse documents are exchanged over a secure session (e.g. HTTP/SSL) in which it is possible to match request-reply pairs and the documents are ephemeral - never stored for future use. However, if these documents are stored and linked via URIs, then unless I am missing something, the security of the system is dependent on the robustness of the URI scheme, as discussed above.
Powered by eList eXpress LLC