[Nsi-wg] Validating URNs in NML

[Henrik Thostrup Jensen]

Hi

(there is tl;dr at the end).

When an NSA retrieves a topology, it has to ensure that the topology does not
overwrite any existing topology entities - either accidentally or by purposely
injecting identifiers to overwrite topology entities from other topologies (id
clash). This is an important issue as soon as an NSA dynamically retrieves
topologies, as they can no longer be manually verified.

The identifier used in NML is the id attribute of XML elements, has the
following structure:

urn:ogf:network:nordu.net:2013:opaque

Such a URN can (roughly) be split into three parts:

1: urn:ogf:network
2: nordu.net:2013
3: opaque

For more details on the URN construction see GFD.202.

One is not allowed to interpret URNs as such, however I believe this is
concerns the opaque part. The first part is static, and we can largely ignore
it here. However the second part (called ORGID in GFD.202 is very important).
It is composed of two parts, a domain name, and a year (can be also year+month,
or year+month+day).

In order to prevent injection/override of topology entities, an NSA should only
be allowed to create ids that fit its organization and relevant domain names.
I.e., only NORDUnet should be allowed to publish identifiers with the nordu.net
domain name (which NORDUnet of course owns). To integrate with existing
security infrastructure this means matching the host name in the X509.
Furthermore regular URL - certificate matching still applies. Say I publish a
topology in the following URL:

https://nsi.nordu.net:9443/NSI/topology/nordu.net:2013.xml

The host name in the URL is "nsi.nordu.net" and hence the host name in
certificate must be "nsi.nordu.net" as well. Furthermore the topology entities
represented in the resource, must match with the certificate name, i.e., they
should start with urn:ogf:network:nsi.nordu.net:. Right now this is not the
case, it uses "nordu.net". This is actually an injection, but not a serious
one. It is possible to create some complicated rules to allow such a case,
however I strongly suggest going for simplicity and enforcing a strong 1:1
correspondence.

Similarly, the NSA urn id, must also adhere to this principle. This,
unfortunately, makes it impossible to host an NSA for which the identity does
not fit the certificate host name.

For the date part, extending the certificate part to hold for this is bit
tricky. If I use "2013", my certificate should of course be valid for some
range of the year 2013. However certificates have a limited lifetime, and are
usually only valid for 1-3 years. Once the certificate have rolled over, it is
no longer valid for any date in 2013, and hence the year part can no longer be
verified. A somewhat weird solution for this could be to keep the old
certificate and present it with the topology, however all security stacks will
(and should) reject such a certificate. It is possible to the check manually of
course, but this impractical, and a very bad idea. I cannot see any practical
way to validate the years in URNs, meaning they do not really add any value for
separating identifiers.

Summary:

1: The domain name in a NML topology id URNs must match the X509 host name
    A. This must hold for the NSA URN as well.
2: There is no practical way to enforce the year/date segment.

As a corollary of 1A, a single endpoint cannot host an NSA for an alternative
domain, without coming up with a rather convoluted security model.

--

Some further questions for the GFD.202 authors:

URNs are supposed to be persistent. Host names are not persistent. Why put them in there?

URNs are supposed to be location independent. Why put host names in there?


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet