Return-Path: X-Original-To: nfsv4@ietfa.amsl.com Delivered-To: nfsv4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D5B129B03 for ; Wed, 2 Aug 2017 09:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0Kzpi5cJFRB for ; Wed, 2 Aug 2017 09:03:36 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315BF131BBF for ; Wed, 2 Aug 2017 09:03:36 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id d145so29595224qkc.2 for ; Wed, 02 Aug 2017 09:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ke3F5Tphq1xzvOyrbcdKEB32L5gIw9QLSxJJxfPKsuY=; b=e62uEgM1pxWb0tCdgVN4xJ+6A5A2STNkHX2pqlhQ7mC5Ja4rOrLrwYADaXLq/Y3Zzh u+W+xtGzHU6gnT/FoR6s+IhBc7/+k7vCgImei+Mtanlp7pBzzSuajvWzBF6xMAaQgY4M EbrYtYL20WHX5MBi1W1rfJLi+EXZCFnzE/9L7swNsK5/W1FXCx8NhPeWnWo347Yq6pok dVaf2V3L/3TfaFTLk4GvE9ENpy+isS5bHCNyHfyA7hcXKm1LnLSmohX2r9fdJo1t+V8I zF910REObm4tYI1HsvReuWEx4A4609XJRgy2EbURnyB8dx9CD6Vwa3KiapJHUuWZktlj QfBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ke3F5Tphq1xzvOyrbcdKEB32L5gIw9QLSxJJxfPKsuY=; b=SkcEFkC3Eh6R0hJ0KL3vNwLuFQc7RYmVkmWzXGmHgTDg2cyWpT6jJXQM2sTQhN5W0A won4wtNJ0530fk/cOwFsAlmepHPzNJ3AOuRy2t7E42KKQQMITFzBH+gjFYlNT7TRT5Fo Mp75juM/TzEbYHiR8qfV/l4VDcZsOsIISPDzFDB0+UcKvT5CztNTRvtO/PbCExHtEof5 YfduCSrZ276moqGwWZPH20IlKzh3LcJvWFrZYgpK739Gnh2b/nT8KZeXmAu3V0f10RJL TycT3LNbZ0zmz+xWPixdxmB0/s3ZShhS27ADP8zVN7S2OWLzybIkWju+pGbMbQbnHhl9 TiSQ== X-Gm-Message-State: AIVw1122iHts+d14nhFRXNz8awlcnbadPfjTLa4p3edpMb2+Qo273tS6 qdM29/wM0YNYUnT4Z6UR2KALnLuuTg== X-Received: by 10.55.161.23 with SMTP id k23mr29176308qke.345.1501689815118; Wed, 02 Aug 2017 09:03:35 -0700 (PDT) MIME-Version: 1.0 Sender: olga.kornievskaia@gmail.com Received: by 10.12.186.159 with HTTP; Wed, 2 Aug 2017 09:03:34 -0700 (PDT) In-Reply-To: <37BF354D-CF56-4A1C-B391-8565F0E38E72@primarydata.com> References: <9E3B8A6F-E27C-4A65-A0F7-6E0275B0616A@primarydata.com> <20170728022333.GI58771@kduck.kaduk.org> <37BF354D-CF56-4A1C-B391-8565F0E38E72@primarydata.com> From: Olga Kornievskaia Date: Wed, 2 Aug 2017 12:03:34 -0400 X-Google-Sender-Auth: KDeJx6hqQtw2UdvtPnaLIz0wkf8 Message-ID: To: Thomas Haynes Cc: Dave Noveck , Benjamin Kaduk , "nfsv4@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0606f4fe39200555c767a4" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 16:03:38 -0000 --94eb2c0606f4fe39200555c767a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 1, 2017 at 3:59 PM, Thomas Haynes wrote: > > On Aug 1, 2017, at 11:29 AM, David Noveck 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 > defines a protocol or layout type is to clearly tell the implementer what > must be done to implement the protool or layout type. Despite the possbl= e > issues with the specificity of any of these three possible alternatives, > the big problem is the fact that there is more than one. If the client a= nd > MDS do not pick the same one, or they do and that one is not fully > specfied, they will not nteroperate. If that is the case, then the > document is not ready. > > I think the treatment of security with tight coupling is sufficiently > clear to implement from and has been for a while. With regard to securit= y > for loose coupluing, what you have is essentially a promise to provide a > specfication at some later date. I don't think the IESG is going to be O= K > with that. > > You have focusing on it being plausible in the sense of convincing people > that this can be done > (i.e. that a definition along these lines can be produced) which it can, > but 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 aw= ay > from being there. > > > The problem isn=E2=80=99t that we are pushing off a specification to a la= ter 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=E2= =80=99s > approach: > > Semi-relatedly, I forget exactly how much trust/coupling there is suppose= d > 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 > details > of how the mds gets the storage device=E2=80=99s keytab are up to the > implementation > (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=E2=80=99t like that approach. > I think you would agree that implementations frequently find issues with this spec. But yes, all the previous specs when ahead prior to full implementations. 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 problems. 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 synthetic identity. Metadata server gets a flexile layout request. It, at some point, constructs 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 data 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 client would request a service ticket for the specified identity. Well in that case, the client would need to provide the password for the synthetic identity. 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 synthetic identity. Initially, in some earlier drafts of the spec the creds was "opaque_auth" but it's not no longer there so I don't see a way of passing the service ticket, encrypted session key. So I think if you want to pass the service ticket back, then you need to add the "opaque_auth" back to the structure? Ok now, we are just passing them back, how are we going to protect against replay attacks? typically there is a challenge response. So perhaps require that LAYOUTGET is always done with krb5i/p? Also on the (linux) client side I would suspect you won't be able to use standard krb5 libraries to deal with the processing the "service ticket". You might have issues getting the gssd given that the identity inside the ticket 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 LAYOUTGET much be done with krb5i/p. (c) as suggested by Ben, issue "service tickets" and explicitly specify what is being passed back, need to dig out the Kerberos spec and write out how the "synthetic identity" information is fitted 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 database 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 constructed. 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 does 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. --94eb2c0606f4fe39200555c767a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 1, 2017 at 3:59 PM, Thomas Haynes <loghyr@primarydata= .com> wrote:

On Aug 1, 2017, at 11:29 AM, David Noveck <davenoveck@gmail.com> wrote:

> Is stating that an o= ut-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. =C2=A0 The job of a standa= rds-track document that defines a protocol or layout type is to clearly tel= l the implementer what must be done to implement the protool or layout type= .=C2=A0 Despite the possble issues with the specificity of any of these three possible alt= ernatives, the big problem is the fact that there is more than one.=C2=A0 I= f the client and =C2=A0MDS do not pick the same one, or they do and that on= e is not fully specfied, they will not nteroperate.=C2=A0 If that is the case, then the document is not ready.

I think the treatment of security with tight coupling = is sufficiently clear to implement from and has been for a while.=C2=A0 Wit= h regard to security for loose coupluing, what you have is essentially a pr= omise to provide a specfication at some later date.=C2=A0 I don't think the IES= G is going to be OK with that. =C2=A0

You have focusing on it being plausible in the sense o= f convincing people that this can be done
(i.e. that a definition along these lines can be produ= ced) which it can, but I think the IESG is going to want you to show them t= hat 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=E2=80=99t that we are pushing off a specificati= on to a later date, but rather that the security is implementation specific= . The client and MDS are forced to pick the same one.

Section 1.7.1 RFC 5661 is quite clear that:

=C2=A0 =C2=A0As with previous versions of NFS, the External Data Repre= sentation
=C2=A0 =C2=A0(XDR) and Remote Procedure Call (RPC) mechanisms used for= the NFSv4.1
=C2=A0 =C2=A0protocol are those defined in [2] and [3].=C2=A0 To meet = end-to-end
=C2=A0 =C2=A0security requirements, the RPCSEC_GSS framework [4] is us= ed to extend
=C2=A0 =C2=A0the basic RPC security.=C2=A0 With the use of RPCSEC_GSS,= various
=C2=A0 =C2=A0mechanisms can be provided to offer authentication, integ= rity, and
=C2=A0 =C2=A0privacy to the NFSv4 protocol.=C2=A0 Kerberos V5 is used = as described in
=C2=A0 =C2=A0[5] to provide one security framework.=C2=A0 With the use= of RPCSEC_GSS,
=C2=A0 =C2=A0other 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= =E2=80=99s approach:

Semi-relatedly, I forget exactly how much trust/c= oupling 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).=C2=A0 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 mode= l. The details
of how the mds gets the storage device=E2=80=99s keytab are up to the = implementation
(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 stan= dard, but I
don=E2=80=99t like that approach.=C2=A0
<= br>
I think you would agree that implementations frequently find = issues with this spec. But yes, all the previous specs when ahead prior to = full implementations. And that's why we have versions, right? It'll= be fixed later.

I'm thinking like an implemen= tor and I have questions that cause me problems. Let's for the moment a= ssume that metadata server will be running on the same machine as the norma= l KDC and have access to the principals database. To construct these ticket= s you need a new service as it will not be a part of the (existing) KDC. Le= t's assume it is practical.

Let's talk abo= ut of the fact that user doesn't know the password for the synthetic id= entity. =C2=A0

Metadata server gets a flexile layo= ut request. It, at some point, constructs a service ticket =C2=A0(session k= ey, "synthetic identity", ... )encrypted with data server's k= ey. It needs to encrypt the "session key" with the client's T= GT key so that the client can then use the service ticket against the data = server. How doest the client gets this ticket?

In = normal kerberos, the client would initiate request for a service ticket. Bu= t here the client doesn't know the "synthetic identity" ahead= of time.=C2=A0 And even if the intent is that once the ffds_owner is retur= ned, then the client would request a service ticket for the specified ident= ity. Well in that case, the client would need to provide the password for t= he synthetic identity. But he doesn't know the password so that's n= ot going to work. So at this point we can't use normal kerberos to get = a service ticket for the synthetic identity.=C2=A0

Initially, in some earlier drafts of the spec the creds was "opaque_a= uth" but it's not no longer there so I don't see a way of pass= ing the service ticket, encrypted session key. So I think if you want to pa= ss the service ticket back, then you need to add the "opaque_auth"= ; back to the structure? Ok now, we are just passing them back, how are we = going to protect against replay attacks? typically there is a challenge res= ponse. So perhaps require that LAYOUTGET is always done with krb5i/p?
=

Also on the (linux) client side I would suspect you won= 't be able to use standard krb5 libraries to deal with the processing t= he "service ticket". You might have issues getting the gssd given= that the identity inside the ticket doesn't "match" the runn= ing identity of the user (I'm not 100%sure here). *i understand that th= is comment is really implementation specific and not specs job*
<= br>
Having said all that, I still feel like we are proposing an &= quot;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 t= hen I guess I'm proposing (a) add "opaque_auth cred" back to = the ff_data_server_4 and (b) require that LAYOUTGET much be done with krb5i= /p. (c) as suggested by Ben, issue "service tickets" and explicit= ly specify what is being passed back, need to dig out the Kerberos spec and= write out how the "synthetic identity" information is fitted int= o those Kerberos structures. I feel that you need to do this because the sp= ec isn't use standard Kerberos so can't just say see Kerberos spec.= =C2=A0(d) explicitly specify that metadata must have access to the princip= al database for the non-synthetic client and the storage servers.=C2=A0

I wonder = is "opaque_auth" the right structure? I think the spec defines it= upto 400bytes. Is that sufficient to capture service ticket + the encrypte= d stuff for the client. I dunno.=C2=A0

=
You mentioned that RFC5661 doesn't sta= te anything as to how TGT are constructed. That's only true because it = states the Kerberos v5 and cites the spec is used. This proposal does not f= ollow Kerberos v5 spec -- the proposal does not engage in KRB_AP/REP sequen= ce which is what kerberos is --=C2=A0and thus i feel it must specify what g= oes into the service ticket.=C2=A0
--94eb2c0606f4fe39200555c767a4--