Subject: [nfsv4] [FedFS] NSDB draft changes for review

From: James Lentini <[email-masked]>
Date: Wed, 16 Dec 2009 15:54:07 -0500 (EST)

At last weeks meeting, I was assigned an action item to draft 
recommendations on how to generate a referral based on FSL 
information.

I've written up a proposal in a new section of the NSDB draft, Section 
2.4.3 "Generating A Referral from Fileset Locations", and included it 
with other changes queued up for the NSDB draft.

A new version of the NSDB draft is here:

 http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-protocol-04bis.txt

and a diff against the -04 version is here:

 http://jlentini.users.sourceforge.net/draft-ietf-nfsv4-federated-fs-protocol-rfcdiff.html

(the real changes start on page 6)

Included in this set of changes are the following:

 1. The proposed text on generating a referral in Section 2.4.3

 2. A synchronization of the examples with the requirements 
    document (see page 12).

 3. updated text on how to identify and locate an NSDB (more on this 
    below)

 4. small text updates to synchronize with the RFC-Editor's 
    suggestions for the requirements specification (capitalization 
    changes in the glossary, etc.)

With regards to 3, my co-authors and I have drafted updated text on 
how to identify and locate an NSDB.

Previously an NSDB was identified by either an IPv4, IPv6, or DNS 
name. After careful consideration, we believe that an NSDB should only 
be identified by a DNS name for the following reason (page 17, line 
42):

    FSNs are immutable and invariant. The attributes of an FSN,	
    including the fedfsNsdbName, are expected to remain constant.	
    Therefore, a fedfsNsdbName SHOULD NOT contain a network address, such	
    as an IPv4 or IPv6 address, as this would indefinitely assign the	
    network address.

We've discussed resolving the DNS name using SRV RRs. The idea of 
using SRV RRs to locate LDAP services has been discussed by the IETF 
in the past. I've provided some background on this topic below [1]. 
The summary is that the IETF has not standardized a way to to locate 
LDAP services using SRV RRs. As a result, many LDAP clients and APIs 
require an LDAP service to be identified using a traditional DNS host 
name.

The above results in both standardization issues and implementation 
impediments to requiring the use of SRV RRs to locate NSDBs.

These text updates are intended to clarify the format of an NSDB name 
and define the DNS name resolution process in a way that is compatible 
both with today's format for identifying an LDAP service and future 
extensions, such as an SRV RR format, should they arise.

As always, comments and suggestions are welcome.

I will allocate time in tomorrow's FedFS weekly meeting to discuss 
these changes.

-james

----

[1] Background on LDAP and DNS SRV RRs

Some LDAP implementations use SRV RRs for locating directories. For 
example, SRV RRs can be used to locate an Active Directory domain 
controller and OpenLDAP commands (see ldapsearch(1)) can lookup 
specially formatted LDAP URIs using SRV RRs. However, these uses are 
all non-standard.

RFC2782, which defines the SRV RR format, uses LDAP in its examples. 
RFC2782 states:

  Note: LDAP is chosen as an example for illustrative purposes only,
  and the LDAP examples used in this document should not be considered
  a definitive statement on the recommended way for LDAP to use SRV
  records. As described in the earlier applicability section, consult
  the appropriate LDAP documents for the recommended procedures.

The "applicability section" of RFC2782 states:

  In general, it is expected that SRV records will be used by clients
  for applications where the relevant protocol specification indicates
  that clients should use the SRV record. Such specification MUST
  define the symbolic name to be used in the Service field of the SRV
  record as described below. It also MUST include security
  considerations. Service SRV records SHOULD NOT be used in the 
  absence of such specification.

Therefore, the LDAP examples in RFC2782 are not standard and any use 
of SRV RRs with LDAP would need to be defined in a separate RFC. 
Unfortunately, no such RFC exists.

A long expired individual I-D describing the use of SRV RRs with LDAP 
was written in 1999:

https://datatracker.ietf.org/idtracker/draft-armijo-ldap-locate/

and was replaced by a WG I-D in that also expired:

https://datatracker.ietf.org/idtracker/draft-ietf-ldapext-locate/

The later was reviewed by the IESG between 2002 and 2004. The IESG had 
concerns, including that the format would only allowed for one LDAP 
service per domain. This was a concern I had raised on using SRV RRs 
to locate NSDBs.

No proposals on this have been made since 2004.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Dec 2009 16:02:21 -0600

On Wed, Dec 16, 2009 at 03:54:07PM -0500, James Lentini wrote:
> [...]
> [...]

I'll go read the updates, but do note that identifying more than one
server by a single FQDN (i.e., via an A RRset, for IPv4) creates a
security problem: how to authenticate the server if we know it by an
alias rather than by a canonical name (or a name that's trivially
canonicalized)?

SRV RRs do solve that problem, at the cost of having to trust DNS
(which, without DNSSEC, isn't all that trustworthy).

In other words, if we'll use FQDNs only, rather than domain names
resolved to FQDNs via SRV RRs, to identify NSDBs then we'll need a
procedure by which NFSv4 servers can securely learn the canonical names
of NSDB servers.

Let me sketch some possibilities:

Without SRV RRs:

 - The ADMIN client tells the NFSv4 server the FQDN of 1 NSDB server for
   a given NSDB service.  The client also tells the NFSv4 server how to
   authenticate that NSDB server (e.g., by passing to the NFSv4 server
   the NSDB server's cert, or a TA for it, ...).

 - The NFSv4 server connects to the given NSDB server and does a
   specific search for replicas of the NSDB, learns their names and any
   relevant authentication information (e.g., their certificates), and
   stores that locally.  This is done both, on first contact, as well as
   on subsequent contacts so as to learn of new replicas / "unlearn"
   retired replicas.

   It's easy to find replicas: just read the NSDB's rootDSE's altServer
   attribute.  It's not so easy to find their certificates: LDAP does
   have a schema for storing certs in the directory, but the altServer
   attribute doesn't tell you the DN of an object where you could look
   for a certificate attribute -- altServer gives you URIs, not DNs.
   I'll ask around see if I can find out how to do this reliably.

   (Of course, if we pass TAs in the ADMIN protocol then the TA for one
   NSDB server should suffice to validate all of its replicas' certs.
   One more reason why passing TAs helps.)

With SRV RRs:

 - Well, you already know this.  Use SRV RR lookups to resolve a domain
   name to a set of NSDB canonical FQDNs.

Ugly alternative:

 - Let the ADMIN client tell the NFSv4 server all of an NSDB's servers
   and authentication information.  This is hard because the user would
   have to know this, and this is not self-updating.

Any others?

> Unfortunately, no such RFC exists.

I have a slightly different take, which is: the NSDB is a protocol that
is based on LDAP, but can, indeed must, differ from LDAP in such details
as service discovery, therefore...

...It is entirely appropriate for this WG to define a discovery
procedure for NSDB services.  Implementation-wise this means that
implementors would have to implement NSDB service discovery separatly
from LDAP APIs used to actually access the NSDBs.

I.e., defining an SRV RR for the NSDB and corresponding discovery
procedure isn't hard!  Nor does it depend on there being an LDAP
discovery procedure.

> No proposals on this have been made since 2004.

LDAP can be used for _many_ purposes.  Some operating systems use it for
name services (think RFC2307bis+ schemas).  But applications can use
LDAP for entirely different purposes.  Therefore any generic LDAP
service discovery scheme would have to allow for discovery of LDAP
services specific to a given application/use.  See above comments.

Nico
--

---

From: James Lentini <[email-masked]>
Date: Thu, 17 Dec 2009 15:03:08 -0500 (EST)

> alias rather than by a canonical name (or a name that's trivially

Could you be more specific about the types of configurations you are 
concerned about? CNAME records? something else? 

What is a "trivially canonicalized" name?

> SRV RRs do solve that problem, at the cost of having to trust DNS

As you mention, trusting DNS requires DNSSEC. DNSSEC is not 
universally deployed; it might be too onerous for some.

> (which, without DNSSEC, isn't all that trustworthy).

Agreed.
 
> procedure by which NFSv4 servers can securely learn the canonical names

An NSDB Service is comprised of one or more NSDB Nodes.

Are you are considering how to authenticate the individual NSDB nodes? 

If so, is that capability necessary? The NSDB Service is administered 
by a single entity. Why is it necessary for the NSDB Service to use 
different authentication information for each NSDB Node?

>    I'll ask around see if I can find out how to do this reliably.

I'll be interested to hear what you find.

>  - Well, you already know this.  

Could you describe this in detail?

The SRV record might point to multiple FQDNs that identify different 
NSDB Nodes. This seems like the same situation as above; the 
fileserver won't be familiar with these FQDNs.

>    Use SRV RR lookups to resolve a domain

I'll have to think about this. 
 
> as service discovery, therefore...

NSDB service discovery and LDAP discovery could be different. However, 
it is not a requirement that they MUST be different.

> procedure for NSDB services.  

Maybe. An NSDB is an LDAP Directory and LDAP service discovery likely 
isn't in scope.

> Implementation-wise this means that implementors would have to 
> implement NSDB service discovery separatly from LDAP APIs used to 
> actually access the NSDBs.

That is a big hurdle to place on implementations. 

> procedure isn't hard!  Nor does it depend on there being an LDAP

We've discussed viewing the NSDB as a dedicated FedFS service versus 
an LDAP service before. I'm uncertain of where you stand on this 
issue. Previously, you argued that a well known suffix of o=fedfs was 
unacceptable because it would prevent the use of deployed LDAP 
instances as NSDBs. As a result, we added the NCE concept. We've also 
discussed the benefits of using existing LDAP client software be used 
to manage an NSDB. Clearly, existing LDAP client software would not be 
familiar with a new service discovery mechanism for NSDBs.

> services specific to a given application/use.  See above comments.

See my comments above about viewing an NSDB as an dedicated FedFS 
service or a LDAP service.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 17 Dec 2009 14:18:24 -0600

> concerned about? CNAME records? something else? 

An NSDB server's cert might only authenticate its canonical FQDN and not
any aliases.  In that case there's no way to match the given alias (the
one used in the DNS lookup) to the canonical name in the cert unless
you're using DNSSEC.

You could require that NSDB servers have certs with subjectAltNames for
their NSDB service alias name.  But that only works if you're using
CA-issued NSDB server certs, as opposed to self-signed certs.

> What is a "trivially canonicalized" name?

One that is missing something that is trivially known from context.
E.g., a non-FQDN for which you know the missing labels from context.

> An NSDB Service is comprised of one or more NSDB Nodes.

Therein lies the rub.

> Are you are considering how to authenticate the individual NSDB nodes? 

And how to discover them.

> different authentication information for each NSDB Node?

Yes, yes, and because you're using LDAP, which constrains you to using
TLS and/or SASL.  You could have all NSDB servers share a single
certificate and private key, I suppose, but that presents some problems
(this is not a common deployment).  You couldn't do that for Kerberos,
so how you discover the NSDB replicas securly is still relevant.

> fileserver won't be familiar with these FQDNs.

As long as you trust DNS and there's a PKI for the NSDB certs then
you're set.  You wouldn't even have to trust DNS if the PKI is either
solely for that NSDB service or if we require the presence of an
extended key usage (EKU) value indicating that a cert is usable for NSDB
service.

> it is not a requirement that they MUST be different.

Well, obviously not.  Who's going to require that?  (Also, LDAP doesn't
have a discovery mechanism.)  This is a matter for _this_ WG to decide,
not for another WG to decide.

> Maybe. An NSDB is an LDAP Directory and LDAP service discovery likely 

I strongly disagree.

> That is a big hurdle to place on implementations. 

I don't agree.  DNS SRV RR lookup code already exists in all
implementors' stacks, almost certainly.

> familiar with a new service discovery mechanism for NSDBs.

Even if you run a single directory for NSDB and other purposes you can
still have distinct discovery mechanisms for each use of that directory.

Nico
--