Subject: [nfsv4] issue 40: pNFS: DS and MDS with different security mechanisms in use

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Tue, 11 Jul 2006 10:09:08 -0400

a couple of comments:

0) what does it mean to choose krb5p with the MDS and get krb5 to the DS? 
krb5p means data privacy, yet it is exactly and only the data in this example 
that is _not_ private! this seems like false advertising! why should an MDS be 
able to claim to export a file system with privacy, and yet not encrypt the 
data! this dilutes the whole notion of security. what advantage do i as a 
client get from having krb5p on the metadata when the data has no privacy????

1) this is a change from NFSv4.0 which does not allow different security 
flavours on READ/WRITE/COMMIT from other operations. is this legal under the 
minor version rules? doesn't this lessen the notion of security?

2) if we are going to do this, then the DS secinfo_4 MUST be a subset of the 
MDS secinfo_4, including associated mount options. an example would be an 
export that uses sec=krb5 -o rw and sec=sys -o ro. the DS should not be 
allowed to export sec=sys rw.

3) if we are going to do this, then the differing DS security choices should 
be expressed in the MDS /etc/exports for all to see.

to me, this simply adds complexity with little or no value. please give some 
examples to show the value of this issue.

-->Andy

Add to section 16.7 Security Considerations

-----------

The methods for authentication,
integrity, and privacy for file layout-based
data servers are the same as that used
for metadata servers. Metadata and data servers
use ONC RPC security flavors to 
authenticate, and SECINFO and SECINFO_NO_NAME
to negotiate the security mechanism and services
to be used.

For a given file object, a metadata server
MAY require different security parameters
(secinfo4 value) than the data server.
For a given file object with multiple data servers,
the secinfo4 value SHOULD be the same across
all data servers.

If an NFSv4.1 implementation supports parallel
NFS and supports file layouts, then the
implementation MUST support the SECINFO_NO_NAME operation,
on both the metadata and data servers.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Tue, 11 Jul 2006 07:51:56 -0700 (PDT)

> client get from having krb5p on the metadata when the data has no

System administrators have the right to do apparently
stupid things. However I don't necessareily think that is stupid.
I might use krb5i for the MDS, and krb5
for the data, and put the MDS on an open network, and the DSes on
physically more secure networks.

BTW, building knowledge or assertions of the relative strength
of secinfo tuples is a lose.  Taking your example,
the the MDS krb5p protection might be using a ticket with a 
256 bit AES encryption type, but the DS krb5p protection might
be using single DES. Which one is higher protection? I can't
tell.

On the flip side, I might invert your example and use krb5p
for data, and krb5i for metadata; I may not care if file handles
are encrypted, but I may care if data is encrypted.

> minor version rules? doesn't this lessen the notion of security?

NFSv4.0 does allow different security flavors for different replicas
of the same file though, so I see a parallel here.

In any case, a client has to cope with this scenario even if we mandate
the MDS and DS use the same secinfo:

- client contacts MDS, is told to use secinfo X
- client contacts DS, uses secinfo X for a while
- server administrator changes secinfo from X to Y
- client now gets a NFS4ERR_WRONGSEC. Does the current
  spec say the client goes to the MDS to get the SECINFO, or
  the DS? If the latter, then the proposal for issue 40 is
  consistent with the trend the spec was taking.

> allowed to export sec=sys rw.

I don't understand the subset issue.

Keep something else in mind ... in many export models
I can do:

  exportfs -o sec=krb5,rw=netgroup1,sec=sys,ro=netgroup2

If a pNFS client has multiple interfaces, it is quite possible
the interface used to talk to the MDS is different than the
interfaces used to talk to the DSes. So the administrator, perhaps
by accident could have rw access to the MDS, and ro access to the
DS.

> be expressed in the MDS /etc/exports for all to see.

/etc/exports is an implementation thing.

> examples to show the value of this issue.

It may be more complex to coordinate secinfo5s across MDS and DSes.

If it is easier for a server to use one secinfo across the the 
server cluster, I expect servers will take that route. But
there will be customer pressure for relax that restriction.

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Tue, 11 Jul 2006 12:53:16 -0400

> physically more secure networks.

you're envisioning multi-homed clients mounting the MDS on one netgroup (with 
krb5i) and getting data from another netgroup (physically secure network).

you're right! system adminstrators have the right to do apparently stupid 
things! why not put the MDS on the secure network and be done with it?

hmm.

one of the reasons i would turn on integrity, is that i want to ensure that 
the data has not changed due to bit rot in the network. your example takes 
away that feature of integrity, diluting the notion of mounting with integrity.

> be using single DES. Which one is higher protection? I can't

yes, but we _can_ tell that both are stronger than no privacy!

> are encrypted, but I may care if data is encrypted.

that's all fine, except, it's not the notion of privacy/integrity that NFSv4.0 
has, and some combinations of MDS/DS secinfo most definiatly collide with 
NFSv4.0 security statements.

> of the same file though, so I see a parallel here.

hmm, i don't. different security flavors for different operations to an export 
is not the same as different security flavours to different exports.

>   consistent with the trend the spec was taking.

the MDS of course. only READ/WRITE/COMMIT are allowed to the DS. this is not 
only the trend that the pNFS spec is taking, this is a concrete statement!
 
> I don't understand the subset issue.

it was an attempt (perhaps not a good idea) to limit the choices for the DS 
secinfo.

do you think the protocol should allow krb5p on the mount, where the MDS 
secinfo has no mention of sec=sys, and allow sec=sys on the DS - so krb5p to 
MDS, sys to DS?

remember the discussions of security WRT pNFS blocklayout? and how, since SCSI 
has no security features, that there is a problem with the minor versioning 
rules - that the security features of NFSv4.0 must be upheld by the storage 
protocol? this was an IETF critique of the first pNFS draft, and is the issue 
i'm raising with this proposal.

> by accident could have rw access to the MDS, and ro access to the

in which case, under the current same secinfo for DS as MDS, writes will fail 
and the administrator (who did an apparently stupid thing) will fix it.

> /etc/exports is an implementation thing.

ok

> there will be customer pressure for relax that restriction.

and we will have to resist, and stay within the minor versioning rules which 
don't allow a lessening of NFSv4.0 features, including security.

-->Andy

---

From: Mike Eisler <[email-masked]>
Date: Wed, 12 Jul 2006 08:35:32 -0700 (PDT)

--- "William A.(Andy) Adamson" <[email-masked]> wrote:

> > > 0) what does it mean to choose krb5p with the MDS and get krb5 to
> the
> > > DS? 
> > > krb5p means data privacy, yet it is exactly and only the data in
> this
> > > example 
> > > that is _not_ private! this seems like false advertising! why
> should
> > > an MDS be 
> > > data! this dilutes the whole notion of security. what advantage
> do i
> > > as a 

That's one possibility. Another is a single interfaced 
client might be on a secure network which
has a router to the open network that has the MDS. 
 
> things! why not put the MDS on the secure network and be done with

Because the MDS might be on a legacy file server already
hosting NFSv4.0, NFSv3, CIFS, http, etc. Secure networks
are a scarcer resource than open networks. There will
probably be more deployed non-pNFS clients for a very long
time. So more ports will be non-pNFS for a very long time.
 
> away that feature of integrity, diluting the notion of mounting with

I might use inexpensive switches and routers for the open network, and
higher grade stuff for the closed network.
 
> yes, but we _can_ tell that both are stronger than no privacy!

krb5p (DES-CRC) is weaker than krb5 (aes-256) if my
attackers have built a DES cracker, and/or are just tampering with
the ciphertext. With such attackers, I'm better off with krb5
(aes-256).
The situation around a security tuple and not the tuple
itself is more important.

> NFSv4.0 security statements.

Which ones?
 
> > > flavours on READ/WRITE/COMMIT from other operations. is this
> legal
> > > under the 

And all operations to the MDS for the same file handle
will use the same security. The MDS and DS are two different 
NFS servers.

BTW, is it not the case that the MDS and each DS can return
a different file handle for the same file? Talk about
defiling sacred cows! Do you really want to get me started? :-)

With a different file handle, I can imagine all kinds of
interesting architectures, include data servers that put
all stripped files into a single per-DS volume. Having
multiple security flavores on a file system with the same
fsid for each file object is a total waste of energy. 
There's little security benefit.
 
> only the trend that the pNFS spec is taking, this is a concrete

Fair enough. It is really then up to pNFSers to decided if
they want to add support for a 4th operation, SECINFO_NO_NAME.
 
> > > 2) if we are going to do this, then the DS secinfo_4 MUST be a
> subset
> > > of the 
> > > MDS secinfo_4, including associated mount options. an example
> would
> > > be an 
> > > export that uses sec=krb5 -o rw and sec=sys -o ro. the DS should
> not
> > > be 

Yes. 

On the MDS it is a good idea is ancestor directories
have a super-set of export options of the descendent
directories, because it is hard to impossible for
clients to cope as they descend via LOOKUP and encounter
WRONGSEC errors. Between an MDS or DS, the superset versus
subset concept doesn't seem to apply.

> i'm raising with this proposal.

Well now that you bring up non-file-based layouts, a customer
will reasonably ask "why are you forcing my NFS-based DS to used
stronger authentication, but my non-NFS based DS can use
weaker authentication?"

There's no difference between AUTH_SYS and Fibre Channel when it
comes to security.

I agree that we should make it clear in the discussion of this
issue in the NFSv4.1 spec that allowing different security
tuples among MDS, and DSes creates a weakest link, and we
can recommend to end users that they not do that. We
can RECOMMEND to implementors that the system administrator's
UI by default uses the same security tuples across the MDS and
DSes.

> and the administrator (who did an apparently stupid thing) will fix

exportfs -o sec=krb5,rw=netgroup1,sec=sys,rw=netgroup3

Great, but he might not know to fix the above (or he does know,
and doesn't care). The point being that at the cost of adding some
virtual interfaces and IP addresses, the customer can do
what you do want us to disallow, and there is nothing we can
do to prevent it.