atom feed12 messages in org.oasis-open.lists.security-servicesRE: Comments on S2ML 0.8a
FromSent OnAttachments
Nigel EdwardsJan 9, 2001 3:20 pm 
Anders RundgrenJan 9, 2001 10:51 pm 
Anders RundgrenJan 9, 2001 11:20 pm 
Nigel EdwardsJan 10, 2001 1:23 am 
Karl BestJan 10, 2001 6:15 am 
Mishra, PrateekJan 11, 2001 2:49 pm 
Anders RundgrenJan 12, 2001 1:12 am 
Edwards, NigelJan 12, 2001 10:15 am 
Anders RundgrenJan 12, 2001 2:04 pm 
Edwards, NigelJan 15, 2001 4:43 am 
Edwards, NigelJan 15, 2001 5:11 am 
Anders RundgrenJan 15, 2001 6:34 am 
Subject:RE: Comments on S2ML 0.8a
From:Edwards, Nigel (Nige@hp.com)
Date:Jan 12, 2001 10:15:54 am
List:org.oasis-open.lists.security-services

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