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

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 12 Jul 2006 10:16:11 -0400

> we disagree.

And it doesn't seem that likely that further discussion will get
us to agreement.

So it seems we have two options here.  

    1) Mike's proposal.

    2) A rule that says that the DS has to accept the security
       flavors that the MDS accepts and no others, mod some
       short synchronization delay when the set is changing,
       and that it is the job of implementations including any 
       storage management protocol to make it so.

My opinion is that 1) is clearly superior to 2), but that 2) is
workable, if that's where the working group consensus winds up.

We know where Andy and I stand on this and I presume Mike also 
favors his own proposal. What about the rest of the working group?  

-----Original Message-----
From: William A.(Andy) Adamson [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 9:40 AM
To: Noveck, Dave
Cc: William A.(Andy) Adamson; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [nfsv4] issue 40: pNFS: DS and MDS with different security
mechanisms in use

> > > 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.
> 
> > 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.
> 
> Yes, but one of the reasons that you might not turn on integrity is 
> its cost.
> 
> Not turning on integrity is a perfectly valid choice, and if it 
> weren't, then
> v4 should not support any security flavors that don't provide 
> integrity but we haven't done that.
> 
> In mike's example, we have someone who is turning on integrity, not 
> because of worries about bit rot but worries about somebody 
> deliberately modifying the data.  He has a right to that and he should

> have a right to dispense with what, when the physical network setup 
> makes that desirable, from his point of view.
> 
> What Mike has proposed, makes it also possible for him to 
> independently use integrity when going to the metadata server, and I 
> think that flexibility is good even though people can do silly things 
> with it.

if you don't want the cost of integrity, the don't mount with it turned
on!
sheese....

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

you've got to be kidding. if you're turning on krb5p for data, which is
SLOW, 
why would you care if metadata has integrity instead of privacy, you're 
already slow!
this has nothing to do with the case you presented (more security on the
data 
channel), and everything to do with a lessening of the security on the
data 
channel compared to the metadata channel.

> 
> > 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.
> 
> Strictly speaking, it is not the same notion.

correct. and when it comes to security, strictly speaking is basically
the 
only way to speak.

> It can't be because v4.0
> doesn't have the DS/MDS distinction.  But the privacy/integrity used
in
> each
> particular instance does match the NFSV4.0 notion.  I don't see the
> collision you are talking about. 

this proposal lets you mount with privacy, and have I/O with no
security. so 
you can claim to have security, yet have none.

> NFSV4.0 allows you to have filesystems
> exported with both kerberos-integrity and AUTH_SYS.  You get integrity
> in only some of the cases.  Every day people export filesystem
allowing
> AUTH_SYS for some some set of clients and other not.  Some of those
> combinations make sense and some don't.  The point is the protocol
does
> not enforce good practice but allows a range of choices.
> 
> It seems to me that if you are willing to accept less security from 
> client A because of network considerations, then it also seems
> reasonable
> to allow it from the combination of client A and DS B because of 
> similar considerations.

there is no reason not to put the MDS on the same network as the DS.

> 
> > 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!
> 
> But is it a concrete accurate statement?
> 
> I think we need to have a definitive list of what ops are valid to the

> DS, and whether it includes SECINFO_ON_NAME as Mike's proposal would
> imply, there are certainly more than three.
> 
> You have to be able to do PUTFH to do the others.
>  
> Now that sessions are mandatory, you have to be able to do SEQUENCE.
> 
> so you also have to be able to create a client-id and create a 
> session.  You probably also need to be able to destroy a session.
> 
> Even though DS's can't have locks, I think we have a possiblity of
> DS's that can be MDS for other file systems.  This probably means that
> a give client instance might not have information to be sure that the
> server knows it has no locks, so I think ti may be that the client
> may have to have the ability to do RECLAIM_COMPLETE.
> 
> Anyway, I think the definitive list has yet to be written.
> 
> > > NFSv4.0 does allow different security flavors for different
replicas
> 
> > > 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.
> 
> It's not an identical situation but there are similarities.  The 
> critical similarity is that the client is typically accessing a 
> different server.
> 
> > 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.
> 
> I disagree.  The issue with the blocklayout is that the storage
protocol
> does not (or might not be thought to) provide the requisite security
> features, i.t. those mandated by v4.0.  Here we have no such issue.
> Since the storage protocol is v4, we meet those requirements. 

yes, but what is being proposed is not v4. it is not the case in v4 that

metadata uses RPCSEC_GSS and data uses AUTH_SYS.

>  Those
> requirements do not mandate use of any particular level of security.
> You can use AUTH_SYS, but you must implement support for kerberos.
> That remains the way things are in pNFS with or without Mike's
proposal.
> The server may mandate use of particular flavors and there is nothing
> in v4.0 security requirements that I know of that would not allow the
> server to be selective about that except that he has to be able to 
> communicate his requirement to the client.  Given the way the pNFS
> file variant works, he can communicate separate security requirements
> for DS and MDS and so he might as well be allowed to.  
> 
> > 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.
> 
> For the files variant, the only thing that I think would consititute 
> a lessening is allowing DS's not to implement kerberos (nobody has 
> suggested that), or to ignore permissions, ACL's, etc (and nobody 
> suggested that either).

we disagree.

> 
> 
> 
> -----Original Message-----
> From: William A.(Andy) Adamson [mailto:[email-masked]] 
> Sent: Tuesday, July 11, 2006 12:53 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nfsv4] issue 40: pNFS: DS and MDS with different
security
> mechanisms in use
> 
> > 
> > 
> > --- "William A.(Andy) Adamson" <[email-masked]> wrote:
> > 
> > > 
> > > 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????
> > 
> > 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.
> 
> 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.
> 
> 
> > 
> > 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.
> 
> yes, but we _can_ tell that both are stronger than no privacy!
> 
> > 
> > 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.
> 
> 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.
> 
> > 
> > > 
> > > 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?
> > 
> > NFSv4.0 does allow different security flavors for different replicas

> > 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.
> 
> > 
> > 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.
> 
> 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!
>  
> > 
> > > 
> > > 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.
> > 
> > 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.
> 
> > 
> > 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.
> 
> 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.
> 
> > 
> > > 
> > > 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.
> > 
> > /etc/exports is an implementation thing.
> 
> ok
> 
> > 
> > > 
> > > 
> > > to me, this simply adds complexity with little or no value. please

> > > give some 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.
> 
> 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
> 
> > 
> > 
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nfsv4
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4

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

---

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

>        storage management protocol to make it so.

actually, what exists now is not #2, which says nothing about negotiation. 
what exists now is

      3) there is no security negotiation with the DS. the whatever            
              security flavour has been negotiated with the MDS is used to the 
DS.

my opinion is that 3) is clearly superior to 1), or 2).

as far as synchronization delay, it exits in all three proposals - because no 
proposal suggest that individual DS's can have different security flavors, so 
changing the DS security flavor => sync delay.

-->Andy

---

From: Mike Eisler <[email-masked]>
Date: Wed, 12 Jul 2006 09:55:39 -0700 (PDT)

> favors his own proposal. What about the rest of the working group?  

I favor (1) but can accept (2). My worry is not so much
flexibility of use, but flexibility of
implementation. The more requirements we put on
synchronizing MDS and DS state, the higher the barrier to
implementation.  At least with SECINFO_NO_NAME, the DS
has a ready made protocol for asking the MDS what the security
tuple should be.

If we do (2) it should be made clear that there will
be unbounded lags when the secinfo tuple
is updated on the MDS. Again, I am against mandating
complex protocols among MDS and DSes.

I have created issue 89  
   The list of NFSv4.1 operations a file-based DS MUST 
   access has to be specified

> be

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 12 Jul 2006 10:46:24 -0400

> favors his own proposal. What about the rest of the working group?  

I don't care, but.... Could secinfo_no_name made optional to implement
on the data servers?

Mixed-flavor support is likely to be a low priority, so secinfo will be
unnecessary on most data servers.  OK, so it's not that hard to
implement, but in the interests of keeping data servers as simple as
possible it'd seem best not to require mandatory features of them unless
it's strictly necessary.

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 12 Jul 2006 21:38:23 -0500

> has a ready made protocol for asking the MDS what the security

I think that Mike's proposal to provide flexibility seems prudent.

Mike has enumerated one of the reasons in that the hardware 
capabilities of the various components of the server may vary.
And it may even vary between the DSes themselves.  So having
flexibility in configuration may make sense in large configurations
such that the management tools at the server provide a reasonable
way to manage the additional complexity of the MDS and DS interaction.

My second reason is more related to the DS supporting SECINFO_NO_NAME.
The scenario would be that an exports security flavor is changed while
it is actively being access.  The client should be able to reestablish
interaction with the DS via the use of SECINFO.

I also agree with Mike that it be best to make the SECINFO_NO_NAME
(and possibly other operations) mandatory to implement to reduce
the complexity that optional behavior brings to both client and server
implementations.

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Thu, 27 Jul 2006 16:34:12 -0700 (PDT)

I'm declaring rough consensus on this issue, which is to allow
the DSes and MDS to have different security mechanisms (i.e. different
results from SECINFO and SECINFO_NO_NAME. The chairs can overrule my
declaration, but in the mean time, as co-editor I'm made the 
edits as originally proposed.

Regarding the sub-issue around the set of operations DSes MUST
support, I've made this edit:

  When using the layout's filehandle, the client MUST only issue 
  BIND_BACKCHANNEL, BIND_CONN_TO_SESSION, CREATESESSION, COMMIT, 
  DESTROYSESSION, NULL, READ, WRITE, PUTFH, SECINFO_NO_NAME, 
  SET_SSV, and SEQUENCE operations to the storage device 
  associated with that filehandle.