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

From: Catherine Meadows <[email-masked]>
Date: Wed, 17 Feb 2016 16:49:03 -0500

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This draftt describes a Uniform Resource Name (URN) namespace that is used by the Globus software-as-a-service provider
for naming persistent resources.  The main requirement is that these identifiers which will persist in external systems, and which must
be identifiable as references to Globus entities.  The draft specifies the syntax, and describes mechanisms for enforcing uniqueness.  In particular, URNs
may not be reassigned.  

In the Security Considerations section, the authors refer the reader to RFC’s 1737 and 2141.  The security considerations in RFC 1737 refer to authentication mechanisms
which are outside the scope of the document.  The recommendations of RFC 1737, however, may require more attention.  Its Security Considerations section runs as follows:

This document specifies the syntax for URNs.  While some namespaces
   resolvers may assign special meaning to certain of the characters of
   the Namespace Specific String, any security consideration resulting
   from such assignment are outside the scope of this document.  It is
   strongly recommended that the process of registering a namespace
   identifier include any such considerations.

The draft does not propose any special meanings for characters in the Namespace Specific String,
but I think it would be good to add a sentence in the Security Considerations Section mentioning this stipulation,
and pointing out that it does not apply in your case because no such spacial meaning is proposed.

I consider this document Ready With Nits.

Cathy

is being proposed, 
Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: [email-masked] <mailto:[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Feb 2016 10:34:58 -0500

Cathy,

(Barry and/or Alexey, please see the "p.s" below.)

Your review of the above document was copied to the URNBIS WG
mailing list, I think due to an AD decision that the WG should
look at new URN NID registration requests to help inform its
work going forward.   In that light...

--On Wednesday, February 17, 2016 16:49 -0500 Catherine Meadows
<[email-masked]> wrote:

>...
> In the Security Considerations section, the authors refer the
> reader to RFC's 1737 and 2141.  The security considerations
> in RFC 1737 refer to authentication mechanisms which are
> outside the scope of the document.  The recommendations of RFC
> 1737, however, may require more attention.  Its Security
> Considerations section runs as follows:
>  
> This document specifies the syntax for URNs.  While some
> namespaces    resolvers may assign special meaning to certain
> of the characters of    the Namespace Specific String, any
> security consideration resulting    from such assignment are
> outside the scope of this document.  It is    strongly
> recommended that the process of registering a namespace

The successor to RFC 2141, draft-ietf-urnbis-rfc2141bis-urn
("2141bis" below), has, at least IMO, a much more comprehensive
view of character and character code considerations than 2141 or
1737.  I (and I assume the WG) would appreciate your taking a
look at that, partially on the theory that you might draw the
short straw for reviewing a successor on IETF LC and it is far
easier to have a discussion and make changes before that stage
is reached (at least some of us believe that the current version
is the next-to-last before WG Last Call), but specifically to
address two questions.

(1) RFC 1737 is a 21+ year old Informational document.  URNs
have evolved considerably since then.   Do you think its
Security Considerations (or other) sections are sufficiently
outdated that 2141bis should explicitly update 1737 to deprecate
that section and point people to newer documents?

(2) More generally, do you think the Security Considerations
section of 2141bis are adequate?  If not, what changes would you
propose or issues you would recommend addressing?  You probably
should read the introductory material in 2141bis before
answering because it explains some constraints that may be
relevant.

>...

best,
    john

p.s. Barry, Alexey, I don't think the above has any significant
impact on draft-martin-urn-globus-02, so have not copied this
note to the IESG.  If you disagree, feel free.   That said, I
think that normative references to 1737, especially in
conjunction with the sort of handwaving in the Security
Considerations section of the present draft, are a bad idea and
should be discouraged for the reasons implied above.  I don't
know whether I would recommend it or not, but, if the issue
Cathy raises are significant enough, it would be possible to
approve this draft with a normative pointer to 2141bis, let the
registration go forward, but then let this document sit in the
RFC Editor queue until 2141bis is ready for publication.

---

From: Catherine Meadows <[email-masked]>
Date: Thu, 18 Feb 2016 11:33:59 -0500

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?

Cathy

Catherine Meadows
> On Feb 18, 2016, at 10:34 AM, John C Klensin <[email-masked]> wrote:
> 
> Cathy,
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Feb 2016 08:58:09 -0800

> RFC Editor queue until 2141bis is ready for publication.

I would not like to have this registration be dependent upon the
publication of 2141bis, however imminent we think that might be.  On
the other hand, the actual registration is done at IESG approval, and
doesn't wait for RFC publication, so maybe that's good enough.

Better, though, might be to think about what security considerations
actually need to be in this document, and to put them in, and not rely
on pointers.  We've been doing many, many URN namespace registrations
with security considerations that just point to 2141, and I can't
really imagine why this one is any different.

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Feb 2016 14:00:25 -0500

--On Thursday, February 18, 2016 08:58 -0800 Barry Leiba
<[email-masked]> wrote:

>> p.s. Barry, Alexey, I don't think the above has any
>> significant impact on draft-martin-urn-globus-02, so have not
>> copied this note to the IESG.  If you disagree, feel free.
>> That said, I think that normative references to 1737,
>> especially in conjunction with the sort of handwaving in the
>> Security Considerations section of the present draft, are a
>> bad idea and should be discouraged for the reasons implied
>> above.  I don't know whether I would recommend it or not,
>> but, if the issue Cathy raises are significant enough, it
>> would be possible to approve this draft with a normative
>> pointer to 2141bis, let the registration go forward, but then
>> let this document sit in the RFC Editor queue until 2141bis
>> is ready for publication.
> 
> I would not like to have this registration be dependent upon
> the publication of 2141bis, however imminent we think that
> might be.  On the other hand, the actual registration is done
> at IESG approval, and doesn't wait for RFC publication, so
> maybe that's good enough.

That is exactly what I was thinking.  Whether it is a good idea
to hold the published document is a separate question and one
I'm happy to leave to the IESG's judgment.

> Better, though, might be to think about what security
> considerations actually need to be in this document, and to
> put them in, and not rely on pointers.  We've been doing many,
> many URN namespace registrations with security considerations
> that just point to 2141, and I can't really imagine why this
> one is any different.

Indeed.   And, depending on how Cathy feels about this one, I'd
actually be happier if the pointer to 1737 was dropped and that
the globus document simply referenced 2141 and supplied whatever
other information is needed explicitly.   A reference to 2141bis
is a plausible alternative, IMO, but that gets tied up with the
issue above.

    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Feb 2016 14:01:43 -0500

--On Thursday, February 18, 2016 11:33 -0500 Catherine Meadows
<[email-masked]> 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

---

From: Catherine Meadows <[email-masked]>
Date: Wed, 24 Feb 2016 15:07:57 -0500

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
> On Feb 18, 2016, at 2:01 PM, John C Klensin <[email-masked]> wrote:
> 
> 
>