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

[Nicolas Williams <[e-mail]>]

On Wed, Dec 16, 2009 at 03:54:07PM -0500, James Lentini wrote:
>  3. updated text on how to identify and locate an NSDB (more on this 
>     below)
> 
> [...]
> 
> 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.
> 
> [...]

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?

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

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.


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

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