From: Rick Macklem <rmacklem@uoguelph.ca>
To: Thomas Haynes <loghyr@primarydata.com>, Olga Kornievskaia
 <aglo@citi.umich.edu>
CC: "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] New wording of Security Section for Flex Files
Thread-Index: AQHTBOJTubmEu3G57EqvOqsgsMtAEKJoh0CAgAdGdgCAABDDgIAAGPyAgAFQjwCAA3LeAIAACpDN
Date: Fri, 4 Aug 2017 21:41:29 +0000
Message-ID: <YTXPR01MB01898E7371F1E3A4E9D75E40DDB60@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
References: <9E3B8A6F-E27C-4A65-A0F7-6E0275B0616A@primarydata.com>
 <20170728022333.GI58771@kduck.kaduk.org>
 <CAN-5tyG9cE9JhccW7Fnho10jVE-5YnpoArZ=3DZuz79dFFD9sQ@mail.gmail.com>
 <CADaq8jc=K5f4cia-jFKjDMAtNhZntFE+Xa0=Lb=LSXOy+sc7Ww@mail.gmail.com>
 <37BF354D-CF56-4A1C-B391-8565F0E38E72@primarydata.com>
 <CAN-5tyH-j937PPA=nRSA5iEHOTKynryQjwfKui9dgVdZa3oQrQ@mail.gmail.com>,
 <CAFAFD9C-DF89-4867-8880-1EA43FD4095F@primarydata.com>
In-Reply-To: <CAFAFD9C-DF89-4867-8880-1EA43FD4095F@primarydata.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: uoguelph.ca does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="windows-874"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2017 21:41:29.4326 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/kZJ8inOILi0o9rn91_A8rnL4rjs>
Subject: Re: [nfsv4] New wording of Security Section for Flex Files
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>,
 <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>,
 <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Aug 2017 21:41:36 -0000

Well, first I'll mention that fattr4_owner and fattr4_owner_group don't
seem to be defined anywhere (not in the RFCs such as 5661 I grep'd).
Presumably, they are strings, so you can define anything you want in them,
can't you?

Having said that. I think all you should do is say "if support of RPCSEC_GS=
S
is required, tight coupling needs to be used".
I think Olga suggested this in her first post on the topic?

If someone really wants to support RPCSEC_GSS/Kerberos for a loose
coupled pNFS server, let them figure out exactly how to do it and
write that up at that time. (I believe it might be possible, but doubt
anyone will actually implement it. Just like no one implements security
mechanisms other than Kerberos.)

rick
________________________________________
From: nfsv4 <nfsv4-bounces@ietf.org> on behalf of Thomas Haynes <loghyr@pri=
marydata.com>
Sent: Friday, August 4, 2017 4:43:29 PM
To: Olga Kornievskaia
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] New wording of Security Section for Flex Files

Hi,

I=92m going to top post to keep the focus on the problem at hand.

In a nutshell, Olga is correct that we are not going to be able to secure l=
oosely coupled flex files.
The removal of =93opaque_auth=94 prevents this from occurring.

And while I have a bastardized approach using RPCSEC_GSSv3 structured privi=
lege assertions,
like we did for SSC - see Section 4.9.1. in RFC 7862, I think a better appr=
oach is to
document the failure of securing loosely coupled flex files v1 and create a=
 flex files v2
which addresses a minor change in the XDR to:

(a) Fix the stateid issue for loosely coupled NFSv4.x
(b) Fix this issue for =93opaque_auth=94 - which includes the issues raised=
 by Olga at the end of
her email.

As to how we go about that, I see two scenarios:

(1) We produce a single standards track document with a request for:

     +-----------------------+-------+----------+-----+----------------+
     | Layout Type Name      | Value | RFC      | How | Minor Versions |
     +-----------------------+-------+----------+-----+----------------+
     | LAYOUT4_FLEX_FILES    | 0x4   | RFCTBD10 | L   | 1              |
     | LAYOUT4_FLEX_FILES_v2 | 0x6   | RFCTBD10 | L   | 1              |
     +-----------------------+-------+----------+-----+----------------+

(2) We produce two standards track documents, the first for LAYOUT4_FLEX_FI=
LES
and the second much smaller document which would have a normative
reference to the first and encompass LAYOUT4_FLEX_FILES_v2. It would
have the delta XDR and the new required text.

What I am approaching the WG for is consensus on which approach to take. Fo=
r
me, the first is less administrative headache and the second preserves a mu=
ch
cleaner separation of the minor versioning.

Oh, and in case it is not clear, I am very appreciative of Olga=92s review =
in
getting me to see the flaw in this document.

Thanks,
Tom


On Aug 2, 2017, at 9:03 AM, Olga Kornievskaia <aglo@citi.umich.edu<mailto:a=
glo@citi.umich.edu>> wrote:



On Tue, Aug 1, 2017 at 3:59 PM, Thomas Haynes <loghyr@primarydata.com<mailt=
o:loghyr@primarydata.com>> wrote:

On Aug 1, 2017, at 11:29 AM, David Noveck <davenoveck@gmail.com<mailto:dave=
noveck@gmail.com>> wrote:

> Is stating that an out-of-band scheme
> is used satisfies the "MUST" of semantics for managing security?

Probably not, but the "MUST" can always be changed to a "SHOULD" :-)

The problem is deeper here.   The job of a standards-track document that de=
fines a protocol or layout type is to clearly tell the implementer what mus=
t be done to implement the protool or layout type.  Despite the possble iss=
ues with the specificity of any of these three possible alternatives, the b=
ig problem is the fact that there is more than one.  If the client and  MDS=
 do not pick the same one, or they do and that one is not fully specfied, t=
hey will not nteroperate.  If that is the case, then the document is not re=
ady[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif].

I think the treatment of security with tight coupling is sufficiently clear=
 to implement from and has been for a while.  With regard to security for l=
oose coupluing, what you have is essentially a promise to provide a specfic=
ation at some later date.  I don't think the IESG is going to be OK with th=
at.

You have focusing on it being plausible in the sense of convincing people t=
hat this can be done
(i.e. that a definition along these lines can be produced) which it can, bu=
t I think the IESG is going to want you to show them that it has been done =
(i.e. that the definiton has been arrived at), and you are a ways away from=
 being there.


The problem isn=92t that we are pushing off a specification to a later date=
, but rather that the security is implementation specific. The client and M=
DS are forced to pick the same one.

Section 1.7.1 RFC 5661 is quite clear that:

   As with previous versions of NFS, the External Data Representation
   (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4.1
   protocol are those defined in [2] and [3].  To meet end-to-end
   security requirements, the RPCSEC_GSS framework [4] is used to extend
   the basic RPC security.  With the use of RPCSEC_GSS, various
   mechanisms can be provided to offer authentication, integrity, and
   privacy to the NFSv4 protocol.  Kerberos V5 is used as described in
   [5] to provide one security framework.  With the use of RPCSEC_GSS,
   other mechanisms may also be specified and used for NFSv4.1 security.

Note that nothing is stated as to how the TGT are constructed, so Ben=92s a=
pproach:

Semi-relatedly, I forget exactly how much trust/coupling there is supposed
to be between the data and metadata servers/operators in this scheme.
In particular, if the metadata server is sufficiently trusted that it can
have a copy of the data server's kerberos credentials (the nfs/ keytab),
then there is quite a lot of flexibility, since the metadata server can
literally construct an arbitrary ticket and encrypt it to "itself" (i.e.,
the data server's keytab).  But I don't know whether it's appropriate
to mention this example in the document or not.

meets the requirements of RFC 5661 and the loosely coupled model. The detai=
ls
of how the mds gets the storage device=92s keytab are up to the implementat=
ion
(just as how the storage device gets the keytab in the first place).


We could wait until the first implementation and then make that a standard,=
 but I
don=92t like that approach.

I think you would agree that implementations frequently find issues with th=
is spec. But yes, all the previous specs when ahead prior to full implement=
ations. And that's why we have versions, right? It'll be fixed later.

I'm thinking like an implementor and I have questions that cause me problem=
s. Let's for the moment assume that metadata server will be running on the =
same machine as the normal KDC and have access to the principals database. =
To construct these tickets you need a new service as it will not be a part =
of the (existing) KDC. Let's assume it is practical.

Let's talk about of the fact that user doesn't know the password for the sy=
nthetic identity.

Metadata server gets a flexile layout request. It, at some point, construct=
s a service ticket  (session key, "synthetic identity", ... )encrypted with=
 data server's key. It needs to encrypt the "session key" with the client's=
 TGT key so that the client can then use the service ticket against the dat=
a server. How doest the client gets this ticket?

In normal kerberos, the client would initiate request for a service ticket.=
 But here the client doesn't know the "synthetic identity" ahead of time.  =
And even if the intent is that once the ffds_owner is returned, then the cl=
ient would request a service ticket for the specified identity. Well in tha=
t case, the client would need to provide the password for the synthetic ide=
ntity. But he doesn't know the password so that's not going to work. So at =
this point we can't use normal kerberos to get a service ticket for the syn=
thetic identity.

Initially, in some earlier drafts of the spec the creds was "opaque_auth" b=
ut it's not no longer there so I don't see a way of passing the service tic=
ket, encrypted session key. So I think if you want to pass the service tick=
et back, then you need to add the "opaque_auth" back to the structure? Ok n=
ow, we are just passing them back, how are we going to protect against repl=
ay attacks? typically there is a challenge response. So perhaps require tha=
t LAYOUTGET is always done with krb5i/p?

Also on the (linux) client side I would suspect you won't be able to use st=
andard krb5 libraries to deal with the processing the "service ticket". You=
 might have issues getting the gssd given that the identity inside the tick=
et doesn't "match" the running identity of the user (I'm not 100%sure here)=
. *i understand that this comment is really implementation specific and not=
 specs job*

Having said all that, I still feel like we are proposing an "SPKM" security=
 here. It will not be practical and later on would be removed. I'd say AUTH=
_SYS or GSSv3 should be used.

And if you still want to keep Kerberos then I guess I'm proposing (a) add "=
opaque_auth cred" back to the ff_data_server_4 and (b) require that LAYOUTG=
ET much be done with krb5i/p. (c) as suggested by Ben, issue "service ticke=
ts" and explicitly specify what is being passed back, need to dig out the K=
erberos spec and write out how the "synthetic identity" information is fitt=
ed into those Kerberos structures. I feel that you need to do this because =
the spec isn't use standard Kerberos so can't just say see Kerberos spec.  =
(d) explicitly specify that metadata must have access to the principal data=
base for the non-synthetic client and the storage servers.

I wonder is "opaque_auth" the right structure? I think the spec defines it =
upto 400bytes. Is that sufficient to capture service ticket + the encrypted=
 stuff for the client. I dunno.

You mentioned that RFC5661 doesn't state anything as to how TGT are constru=
cted. That's only true because it states the Kerberos v5 and cites the spec=
 is used. This proposal does not follow Kerberos v5 spec -- the proposal do=
es not engage in KRB_AP/REP sequence which is what kerberos is -- and thus =
i feel it must specify what goes into the service ticket.