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

[James Lentini <[e-mail]>]

On Wed, 16 Dec 2009, Nicolas Williams wrote:

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

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

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?

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

I'll be interested to hear what you find.

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

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

I'll have to think about this. 
 
> > [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...

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

> ...It is entirely appropriate for this WG to define a discovery
> 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. 

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

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.

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

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