Re: [urn] secdir review of draft-martin-urn-globus-02

[Catherine Meadows <[e-mail]>]

Hi John:

I’ve looked through 2141bis, and and several of the documents it cites, in particular, RFC 6943, “Issues in Identifier Comparisons for Security Purposes” and RFC 6793, "Privacy Considerations for Internet Protocols”.
The following is a list of the
information I think should be in the Security Considerations Section of that document, based on my understanding of 2141bis and URN’s in general.  That understanding is imperfect,
so I welcome your feedback.  Please let me know if any of the assumptions I made are incorrect, or if I am missing anything.

Cathy


As I understand it, URNs are similar to URLs except: 1) they don’t give necessarily give any information on how to access a resource 2) they are assigned in separate “namespaces”, where a namespace is identified by a unique prefix, and 3) they are persistent, even when the object being identified is no longer present. Also, there may be tighter controls on the issuing of URN’s than URL’s.  For example, URNs in a given namespace
could be generated and assigned by a central authority, or a central authority and some trusted partners.

Since URNs are similar to URLs, they present many of the same security challenges.  On the other hand, some of the features unique to URNs can provide mitigation against security
problems, and in some cases prevent them altogether.  So I think it would be very useful for the Security Considerations Section to list the major security issues and mitigations.  The security
issues may be not be unique to URNs, but the mitigations may be.

As far as I can tell, there are two main security issues that can arise when using URNs.  One is if URNs are used for security decisions.  For example, an entity contacting a resource identified by an
URN might be willing to give certain information to it based on the URN used to identify it.  In this case, URNs should be authenticated, but even this will not be sufficient unless other issues are taken into
account, in particular:

1.  False positives or negatives when determining whether URNs are equal to could lead, e.g. to an elevation of privileges attack in which in which an attacker uses a low-privilege URN which is confused with a high privilege URN. Such a vulnerability is particularly probmatic when the attacker himself can choose the URN, and intentionally chooses an URN that can be confused with a high-privileged URN. An example
in which an attacker takes advantage of inconsistent canonicalizers at two different organizations is given in Section 2.2 of RFC6943.   rfc2141bis, in section 6.4, talks about the security and privacy template and
gives the consequence of producing false negatives and false positives as one of the possible issues.   But nothing  is said about this in the Security Considerations Section about this issue, beyond a reference to
6.4.   However, I believe that it would be appropriate to have more discussion in the Security Considerations section about the measures that  could be taken to mitigate against this, e.g. having URNs within a namespace generated and assigned by a central authority, so that an attacker could not deliberately choose an ambiguous URN, equivalence checking algorithms that minimize false positives and negatives, etc.  BTW, I notice that
2141bis recommends the minimization of false negatives, but not false positives (as far as I can tell, this is not discussed in a security context, however).  Can you tell me what the reason for this is?

2.  There is a similar attack, also mentioned in RFC 
6943,  in which an attacker chooses a resource identifier that is not ambiguous to an equivalence checker but is to a human looking at it in a human-readable format.  This can (and has ) for example been used to gather password information from users.   It is mentioned in rfc2141bis, in Section 3.2, when it is noted that symbols in different fonts, although they may be clearly distinguishable to a machine equivalence checker, may be easily confused when displayed in human-readable form. Again, this is something I think should be mentioned in the Security Considerations section, again with suggestions for possible mitigations:  central generation of and assignment of URNs within a namespace, rules preventing URNs that are easily confused when in human readable form (e.g. rules governing the use and placement of non-ASCII characters), etc.

3. Another problem  mentioned in RFC 6943 is security problems arising from expired identifiers that are reassigned.  If there are portions of the network
that have not gotten the news yet, this could result in elevation of privileges of the current resource identified by the URN.  Since URNs are intended to be
persistent, that is not a problem for them.   It might be worth mentioning that this should not be an issue for URNs because URNs can’t be reassigned.



The second issue is privacy issues involving URNs.  For example, if an URN can be used to assist in contacting a resource, this may raise privacy issues.
In some cases, simply being careful about distributing URNs may not itself be enough, and issues such as potential vulnerability to, e.g., directory harvesting of URNs should also be addressed.
I don’t have any specific.

RFC 6943 also raises the issue of denial of service that could result from inconsistent canonicalization of URI’s.  It’s not clear to me how an attacker would take effective advantage of this however
(or maybe it’s just that there are so many more effective ways of achieving denial of service.

I also think the Security Considerations Section should reference RFC’s 6943 and 6793, but should not stop there; it should also discuss how they apply to URN’s and what the mitigations are.
and mitigations described above.





WRT RFC 1737: that Security Considerations Section reads

Applications that require translation from names to locations, and
   the resources themselves may require the resources to be
   authenticated. It seems generally that the information about the
   authentication of either the name or the resource to which it refers
   should be carried by separate information passed along with the URN
   rather than in the URN itself.

That recommendation is still relevant, but stops short of addressing the other
issues described above.  Also, as noted above, RFC’s 6943 and 6793, which were not available when RFC 1737 was written, give useful information
on this topic and should be cited.  






Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: [phone]
fax: [phone]
email: [e-mail] <mailto:[e-mail]>
> On Feb 18, 2016, at 2:01 PM, John C Klensin <[e-mail]> wrote:
> 
> 
> 
> --On Thursday, February 18, 2016 11:33 -0500 Catherine Meadows
> <[e-mail]> wrote:
> 
>> Sure, John, I'll be happy to take a look at 2141bis and get
>> back to you all.  If I get an opinion to you by sometime next
>> week, is that soon enough?
> 
> Yes, sometime next week would be great.  I wish the volume of
> comments on the WG list were such that I could make an argument
> for tomorrow (or yesterday), but it hasn't been.
> 
> thanks,
>   john
> 
> 
>