Subject: Re: [nfsv4] [FedFS] meeting agenda (10/1)

From: James Lentini <[email-masked]>
Date: Thu, 1 Oct 2009 09:55:42 -0400 (EDT)

On Wed, 30 Sep 2009, Nicolas Williams wrote:

> On Wed, Sep 30, 2009 at 06:19:41PM -0400, James Lentini wrote:
> > + Discuss Open Issues
> > 
> >   - Configurable NSDB port?
> > 
> >   - fedfsNfsPathname format
> > 
> >   - FSN format: <NSDB location, LDAP base DN, UUID>
> > 
> >   - NSDB location format: hostname or SRV RR?
> 
> Conveniently enough, the FSN format had better include the NSDB port #

The Admin protocol allows an optional port number to be included in 
the NSDB address.

> if SRV RRs are not in use, unless you wish to have a single alternative
> port number used throughout.  Yet another way in which SRV RRs help
> here.

We had a brief discussion about the use of non-standard LDAP ports two 
weeks ago. There was a question about how firewalls would interact 
with a non-standard port, but we didn't have time to fully discuss the 
issue then. I don't remember if anyone advocated requiring NSDBs to 
run on the standard LDAP port though.
 
> As a compromise, you could try SRV RR queries, then fallback on A
> RRsets, but I don't think that simplifies anything (it's not RRset
> administration that's the problem -- it's the code to do SRV RR queries
> that is).  We all already have SRV RR query code for other purposes, so
> I say just use SRV RRs.
> 
> Also, see my secdir evaluation of the requirements document: you may
> want to include optional authentication information in the FSN format:

Authentication information in the FSN format would not eliminate the 
PKI benefits that you described in the requirements document 
evaluation. In the event that the NSDB's or certification authority's 
keys are compromised, the certificate information must be invalidated. 
With or without an authentication token in the FSN, a fileserver 
concerned about this issue should validate the NSDB's certificate. 

We will include a full discussion of this subject in the Security 
Considerations section of the NSDB specification.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 1 Oct 2009 11:05:59 -0500

> run on the standard LDAP port though.

Firewalls are a relatively minor issue.  If you get a new port assigned
then it will be up to each NSDB operator to ensure that their firewalls
open that port.  Same thing if you allow configurable ports.  If
firewalls that limit the ports open for outbound connections are a
concern, then having a standard port would help.

> evaluation. In the event that the NSDB's or certification authority's 

Did you mean "would eliminate"?  But note that I intended for
authentication information in the NSDB name to be OPTIONAL.  It'd only
be used when an NSDB has a self-signed cert.

> concerned about this issue should validate the NSDB's certificate. 

Of course.

> Considerations section of the NSDB specification.

OK.

---

From: James Lentini <[email-masked]>
Date: Thu, 1 Oct 2009 17:03:56 -0400 (EDT)

On Thu, 1 Oct 2009, Nicolas Williams wrote:

> Did you mean "would eliminate"?  

No, I did mean "would not". I was pointing out that there are benefits 
to using a PKI (e.g. for checking certificate revocation) even if the 
FSN stored authentication information.

-james

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 1 Oct 2009 16:04:00 -0500

> FSN stored authentication information.

Most definitely.  And there are benefits to storing authentication
information (e.g., trust anchor references) even if you have a PKI,
particularly when you have many disjoint PKIs.

I highly recommend that optional authentication information be included
in the NSDB name or FSN format.

Nico
--

---

From: James Lentini <[email-masked]>
Date: Fri, 2 Oct 2009 11:15:00 -0400 (EDT)

On Thu, 1 Oct 2009, Nicolas Williams wrote:

> I highly recommend that optional authentication information be 
> included in the NSDB name or FSN format.

Yes, a fileserver needs a trust anchor for each NSDB it wishes to 
authenticate. Embedding the mechanisms for constructing trust 
relationships in the FSN requires all FSNs with a given trust anchor 
to be invalidated should that trust anchor be compromised. Separating 
the FSNs (pointers to one or more FSLs) and the trust anchor used to 
authenticate NSDBs (the services that "resolves" the FSN pointers) 
allows the later to be revoked without invalidating the former.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Oct 2009 10:49:09 -0500

> allows the later to be revoked without invalidating the former.

Invalidating trust anchors is _always_ a hard problem.  I believe
handling the invalidated FSN/FSL problem would not be harder than
handling invalidated TAs in the first place.  (Messages of the form "TA
x has been replaced with TA y" have to be propagated everywhere, and so
all servers will be able to replace old TAs appearing in FSNs/FSLs.)

Nico
--

---

From: James Lentini <[email-masked]>
Date: Fri, 2 Oct 2009 13:21:18 -0400 (EDT)

On Fri, 2 Oct 2009, Nicolas Williams wrote:

> Invalidating trust anchors is _always_ a hard problem.  

Agreed.

> I believe handling the invalidated FSN/FSL problem would not be 
> harder than handling invalidated TAs in the first place.  (Messages 
> of the form "TA x has been replaced with TA y" have to be propagated 
> everywhere, and so all servers will be able to replace old TAs 
> appearing in FSNs/FSLs.)

In some implementations the FSNs will be stored throughout the 
exported filesystem. If each FSN contains a TA, the process for 
invalidating the TA is more complicated than if the fileserver stores 
only a single instance of the TA.

-james

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Oct 2009 12:55:06 -0500

> only a single instance of the TA.

There's no need to update the on-disk representation of FSNs.  All you
need to do is store a history of "replace TA x with TA y" messages, and
do the replacements on demand, as needed.

---

From: James Lentini <[email-masked]>
Date: Fri, 2 Oct 2009 14:25:04 -0400 (EDT)

On Fri, 2 Oct 2009, Nicolas Williams wrote:

> There's no need to update the on-disk representation of FSNs.

I didn't say there was a need to do that. There are any number of ways 
the revocation of a TA could be accounted. The bottom line is that 
storing TAs in every FSN make the process more complicated.

> All you need to do is store a history of "replace TA x with TA y" 
> messages, and do the replacements on demand, as needed.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Oct 2009 13:27:58 -0500

> storing TAs in every FSN make the process more complicated.

Compared to the complexity of revoking TAs in the first place, no, I
don't agree.

And the fact that you might well have deployment scenarios involving the
use of self-signed certs for NSDBs (come on, you _know_ that there will
be deployers who will want that as the simplest deployment option), you
really do need optional authentication information in FSN/FSL names.

You could prohibit the use of self-signed certs.  You could mandate the
use of a uniform PKI namespace.  But that seems rather unrealistic to
me.

Nico
--

---

From: James Lentini <[email-masked]>
Date: Fri, 2 Oct 2009 16:27:08 -0400 (EDT)

> use of a uniform PKI namespace.  But that seems rather unrealistic to

Allowing the use of self-signed certs does not require them to be 
embedded in every FSN.

In addition to the complexity issues with embedding authentication 
information in FSNs, adding authentication information to the FSN 
increases FSN's total size which is also undesirable. Roughly how much 
data are you proposing be added to an FSN? Would it be fair to say it 
is around 1KB?

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Oct 2009 15:25:59 -0500

> Allowing the use of self-signed certs does not require them to be 

Technically the self-signed cert would either have to be in the NSDB
name (which is part of the FSN) or pre-shared.

> data are you proposing be added to an FSN? Would it be fair to say it 

See my previous comments about NSDB name compression by interning.