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 14:37:39 -0400

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

The difference bettwen 3) and 2) are that:

    2) says that when the client does this (uses that flavor 
    with the DS), it must work, eventually, while 3) says
    nothing about the subject.

    2) says the DS must not accept additional flavors if the client 
    does attempt them, while 3) leaves this possiblity open.

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

I'm surprised particularly as you concerned about the security 
implications of a DS accepting other flavors.  I don't see
why you think it is superior to allow this.

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

I thought Mike's proposal was if you get a WRONGSEC from the
DS you ask the DS and then use that and it should work bar
yet another switch in flavor.  I don't think there is a
synchronization delay per se.

-----Original Message-----
From: William A.(Andy) Adamson [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 11:04 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

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

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

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