Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 01 April 2020 15:28 UTC

Return-Path: <magnus.westerlund@ericsson.com>
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 D19EF3A110C; Wed, 1 Apr 2020 08:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 9JM6qpaW1stq; Wed, 1 Apr 2020 08:28:31 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70054.outbound.protection.outlook.com [40.107.7.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4AC3A118E; Wed, 1 Apr 2020 08:28:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZEfree05JC7uRcYFhsOElC7rGMEja9gYfJzLuFW/CYSVcCRvRa/r3ugEiqJNzd9wdrUY+mUbFQIKhIvtz7r+giQ3EKTEY6IrdaJgI6VDcdmY7rlwREX1dfq1rZ+O9B9VmsWDm/7Z017ohMbH5vD77YIFtocDHMA3ALtvOWL5W4NGh82uTB7b11l6FxwQmX+2F3wE/WnZn1ndmciR7oqJ3C77Bvbra66wlIvkKRA1wIEnI6FszaYBG83CMIxhjn79gtuqi5jzniubmGBD7k/zVF71QTIEp0xMwF+XEd+5xF7LNgntzC8ct3CGfj8AlHtUOCeDL8/sxoK7pO9Uh1QuVw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OX0wAOftg891UNnBQtqX9FOPX7D3ubPLNpZagAaogVc=; b=AyyXsz3DG0UUCETAv9dfvZrc5PMU9t9jMnmSL74VRjK5zjFo9nQUzMm8Md0CnYKTRQqKBHgTiDMW9xW0mPNbZyXzbu32u+tqVQtuf/63Nu+YFN1uGuK9Bz20b+KinOKSCwnrFZLW3eJR1u6Z6fotIjywjo/XfEEn2tIKUR8FstyYYpfzyuo131RmHwdXNlG0QJ7nGu7EyTJC5tsf8stR6s2/JLERGhylFZ8VMe7u1a/xiNl+Mpl8NXJ/Xz561Eem5kGH+R1XNup6zA0HceXkPrUyb+fJAxtBTWEOiYH8LQu4eSyNd3hfk6SVa/hkqy81gOYlBw7BXbAa295p/89IBQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OX0wAOftg891UNnBQtqX9FOPX7D3ubPLNpZagAaogVc=; b=ZxQb/VzFBpEWADc66ZtDmIHBU0EZfrfalwubL2ze9etwixQPdRMgmcJrcyy0z0sCls39cvEnx4mei+RWDKJs2aV/8b5SjG3xLpwHzYuNvMZR5q8n9eaTv4vVuTUd3TYPeML9JSmNLecnsMPo22uxifnMj2PqWUmMW8QPDGKZoZ0=
Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com (52.134.8.30) by VI1PR0702MB3726.eurprd07.prod.outlook.com (52.134.1.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.13; Wed, 1 Apr 2020 15:28:21 +0000
Received: from VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::4109:db16:5948:85dd]) by VI1PR0702MB3775.eurprd07.prod.outlook.com ([fe80::4109:db16:5948:85dd%4]) with mapi id 15.20.2878.014; Wed, 1 Apr 2020 15:28:21 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "davenoveck@gmail.com" <davenoveck@gmail.com>, "magnus.westerlund=40ericsson.com@dmarc.ietf.org" <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
CC: "draft-ietf-nfsv4-rpc-tls@ietf.org" <draft-ietf-nfsv4-rpc-tls@ietf.org>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls
Thread-Index: AdYH+TZCYEUSPG/KThqZ8Tp9CcZenQAJM2MAAAcJ/4A=
Date: Wed, 01 Apr 2020 15:28:21 +0000
Message-ID: <75dfc771da57f0eb4e3baa24cb78cb386efc51ff.camel@ericsson.com>
References: <VI1PR0702MB3775838FD12AB8A89392C17B95C90@VI1PR0702MB3775.eurprd07.prod.outlook.com> <CADaq8jfHkUf3Z58_eq5ODOUge6FPzGida4O6WxEjk1kGVAnQig@mail.gmail.com>
In-Reply-To: <CADaq8jfHkUf3Z58_eq5ODOUge6FPzGida4O6WxEjk1kGVAnQig@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [158.174.118.23]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b3ac9ce4-b970-4730-a144-08d7d6514fc9
x-ms-traffictypediagnostic: VI1PR0702MB3726:
x-microsoft-antispam-prvs: <VI1PR0702MB37267C3B65FBCA776298396095C90@VI1PR0702MB3726.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03607C04F0
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0702MB3775.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(376002)(366004)(136003)(346002)(39860400002)(81156014)(81166006)(8936002)(36756003)(66574012)(2906002)(30864003)(71200400001)(186003)(26005)(66476007)(66446008)(478600001)(5660300002)(64756008)(66946007)(66556008)(966005)(86362001)(66616009)(76116006)(91956017)(4326008)(6486002)(6506007)(54906003)(6512007)(8676002)(99936003)(44832011)(2616005)(316002)(110136005)(99106002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: D/gxYvka86qF7OjUPkffmYa+i9iQz76ytB5GMWsbb6B/j4Io5wo8zTgT+ssHMYsJn4NgWNTEQ+Mte3LHxRPSEiNyOt/dbhX20IwgDzDC+xWHjI9I11PIQ0ExS26pK8UAPlbw5GVOhZ3HL7lxDLpEqTj8UKH3t6fAF7yy1hRVlv3q/QKPSyD61jQtqm/RBqI6K/JZj/K33j8sQ5DG3SYFA+qt/Krx+GdOBwSWXf1V/JYanQl3y2ojtsLtBq4E52fPoW8h3hgHe08/iJiIMUy6HYNkayDSD33Vo18DB8/FI/bEBf/dZEoK6vtD9z8Pafrxr2OVTL6ldHFQqX7970HxRyzkUTvXEX3wv6nHQUs7bcWz7joyW16BQVATbvvbEnqGc2dOh64MjXAjwpHXnxr4mtJfyGKkVViu+I/qsXAS/+dL1HcyHZ6UXAIP+5maY4IyBVdhoezqoI3is0X7HP/uWcyzSCqIrwj+MpTLw8UmD2g+BcWoyNB91817qN3Sn32dqlFQaWTHrhDexZIVumDfuYh/59aAEdGP/Q4DRAYiIQti9wRRHbY5/4l11WK4O+kf
x-ms-exchange-antispam-messagedata: LM30xNDBeR4iCSw5RwhafMYcONYJfWn7c5V626tkBJajU+JUX74HX/4h1XeEsoaqV1KA3RCwKI6vgrKreAN6KarNLwmDfxGeEj298Y0Z+GBIXlngdZ17kdCZ3JfTHJ+sMIe7tz+pfvKiVX1uLmWnBw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-hh1vpq8O41BOjKEQS/7T"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b3ac9ce4-b970-4730-a144-08d7d6514fc9
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 15:28:21.3664 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0rQQYW2uJRbzKA93R5430W5JHpD52klkWmOvoYsZ0rUrWQ8TZ+KMQX1/ok/+4vHLlOlNko8V6NrpTGysSkMuEG21XJFiyB6F+2qLsglq9SY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0702MB3726
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/r_N4bu-DXQ_uhSxNpCSA3zky9Ck>
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 01 Apr 2020 15:28:35 -0000

Hi,

Please see inline.

On Wed, 2020-04-01 at 08:06 -0400, David Noveck wrote:
> 
> 
> On Wed, Apr 1, 2020, 4:27 AM Magnus Westerlund <
> magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote:
> > NFSv4 WG,
> >  
> > Sorry my AD review took longer time than it was supposed to. Anyway here are
> > my comments. And as usual I am not an expert on NFS or RPC.
> > True but you noticed something important (re channel binding) that the
> > members of the working group, more knowledgeable about RPC, did not notice.
> 
> 
> > So don’t hesitate to push back or educate me with relevant context if what I
> > comment appears to be just strange.
> 
> We're used to AD'S sounding strange to us.
>  Its clear you have issues with some of the strange things we say.
> >  
> >  
> >  
> >  2. Section 3:
> >  
> >    Note also that the NFS community uses the term "privacy" where other
> >    Internet communities use "confidentiality".  In the current document
> >    the two terms are synonymous.
> 
> But it doesn't say what this common meaning is :-(

So RFC 4949 says the following: 

   $ privacy
      1. (I) The right of an entity (normally a person), acting in its
      own behalf, to determine the degree to which it will interact with
      its environment, including the degree to which the entity is
      willing to share its personal information with others. (See:
      HIPAA, personal information, Privacy Act of 1974. Compare:
      anonymity, data confidentiality.) [FP041]

      2. (O) "The right of individuals to control or influence what
      information related to them may be collected and stored and by
      whom and to whom that information may be disclosed." [I7498-2]

Shirey                       Informational                    [Page 232]
RFC 4949         Internet Security Glossary, Version 2       August 2007

      3. (D) Synonym for "data confidentiality".

      Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym
      for "data confidentiality" or "data confidentiality service",
      which are different concepts. Privacy is a reason for security
      rather than a kind of security. For example, a system that stores
      personal data needs to protect the data to prevent harm,
      embarrassment, inconvenience, or unfairness to any person about
      whom data is maintained, and to protect the person's privacy. For
      that reason, the system may need to provide data confidentiality
      service.

      Tutorial: The term "privacy" is used for various separate but
      related concepts, including bodily privacy, territorial privacy,
      personal information privacy, and communication privacy. IDOCs are
      expected to address only communication privacy, which in this
      Glossary is defined primarily by "data confidentiality" and
      secondarily by "data integrity".

      IDOCs are not expected to address information privacy, but this
      Glossary provides definition 1 for that concept because personal
      information privacy is often confused with communication privacy.
      IDOCs are not expected to address bodily privacy or territorial
      privacy, and this Glossary does not define those concepts because
      they are not easily confused with communication privacy.


You also have to consider the threats from pervasive monitoring on privacy as
discussed in https://datatracker.ietf.org/doc/rfc7258/


> 
> >  
> > Can this usage of privacy be avoided.
> 
> Not totally. A lot of it is embedded in existing hard-to-update documents.
> 

Yes, but there are 14 mention of privacy in this document. These should be
possible to change to say either confidentiality or encrypted depending on what
is actually intended to be said. 

> >   
> > 3. Section 4.1:
> >  
> >   <CODE BEGINS>
> > enum auth_flavor {
> >            AUTH_NONE       = 0,
> >            AUTH_SYS        = 1,
> >            AUTH_SHORT      = 2,
> >            AUTH_DH         = 3,
> >            AUTH_KERB       = 4,
> >            AUTH_RSA        = 5,
> >            RPCSEC_GSS      = 6,
> >            AUTH_TLS        = 7,
> > /* and more to be defined */
> >    };
> > <CODE ENDS>
> >  
> > In this particular case it might not be a major issue, but it is recommended
> > that not put the numbers from the IANA registry into to the document until
> > it has been assigned to the document.. In cases where one need a number for
> > testing during development, one can in many registries actually issue an
> > early assignment.
> >  
> > To me the right way of doing this table would have been to replace the 7 on
> > the AUTH_TLS line with a [IANA_TBA]. And add an RFC-editor note in this
> > section, and the necessary IANA sub-section requesting assignment. And if an
> > number would have been needed for the implementation an early assignment
> > request could have been done,
> 
> This was needed but wasn't done then.
> 
> >  then converted to a permanent one using the IANA section.
> 
> Not sure what our options are now, given the wide use of 7.

So the above is what I recommend that the WG uses in the future. In this case,
add an IANA section and specifically request this to be assigned value 7 as that
has been used in the implementations. 

> 
> >  
> > 5. Section 4.2.1:
> >  
> >    A TLS-capable RPC implementation uses
> >    GSS channel binding to determine when GSS integrity or privacy is
> >    unnecessary.  See Section 2.5 of [RFC7861] for details.
> >  
> >    RFC 7861 Section 2.5 says:
> >  
> >    2.5.  RPCSEC_GSS_BIND_CHANNEL Operation
> >  
> >    RPCSEC_GSSv3 provides a channel-binding assertion that replaces the
> >    RPCSEC_GSSv2 RPCSEC_GSS_BIND_CHANNEL operation.
> >  
> >    The RPCSEC_GSS_BIND_CHANNEL operation is not supported on RPCSEC_GSS
> >    version 3 handles.  If a server receives an RPCSEC_GSS_BIND_CHANNEL
> >    operation on an RPCSEC_GSSv3 handle, it MUST return a reply status of
> >    MSG_ACCEPTED with an accept_stat of PROC_UNAVAIL [RFC5531].
> >  
> > I don't see how the details in 2.5 provides an answer to how each peer can
> > determine that TLS Is present by using the GSS channel binding.
> > I don't either.
> > Maybe this is understandable by someone that understands GSS in detail. 
> 
> And maybe not.
> 
> >  
> >  Howeverr, I think some more details are needed.
> 
> The alternative, which I do not recommend, is to update the sentence to say
> "See Section 2.5 of [RFC7861] to be totally mystified" :-)
> 
> I think the place to start in addressing this is to consider what existing
> implementations do about this issue.


So it appears some new text is required here then. 

> 
> >  
> > 13. Requirement on implementation
> >  
> > Should this document actually update any or all of the versions of NFS 4 to
> > mandate implementation support?
> 
> No.  I think we are trying to move in a direction in which there are fewer,
> ideally one, document to look at to tell you what you have to do to implement
> a minor version.  This document defines an RPC-level facility and should not
> reach up the stack in that way. 

Ok, that is a good point. I think it can be part of an answer. I do see the
point, and likely we have to work threw the updates of RFC 5531 in this area. 

> 
> > Fromm the WG's perspective doesn't it make sense to start demand
> > implementation support.
> 
> We don't want to "demand" things and be ignored.  I think we can, without
> demanding it, encourage it's use.
> 
> > The mechanism is clearly opportunistic in its establishment, however the
> > goal here needs to be to get support in as many places is as possible.
> 
> Yes.
> 
> > Thus, sending a clearer signal that NFS 4.x servers and client are expected
> > to support this should be sent.
> 
> I think we can figure out how to send a clearer signal.

Good!

> 
> 
> > If not can you clarify what the concerns are? Because we are going to get
> > this question again in the IESG evaluation.
> >  
> > To me the reasonable plan towards always used transport security (something
> > I expect the full updates, for example of NFS v4.1 to require) is to require
> > implementation but not usage now. Then next step to require its usage.
> 
> Maybe I'm getting upper and lower case mixed up but I don't see that you can
> reasonably update the specification of a particular minor version, in a way
> that defines a significant number of existing implementations as non-compliant 
> post facto.

I know that different groups have a  bit different views on how one consider
compliance when one have new RFCs that update old ones. From my perspective one
likely have to indicate the set of normative references + updates/replaced RFCs
for a particular compliance point. 


> 
> Adding  a new recommendation is different. Saying this "SHOULD" be implemented
> makes sense, as defined by RFC2119.  (Often "SHOULD" is used as a "MUST"
> without a whole lot of conviction. Sigh!).  In this context, the time to
> implement, test, and deploy support are valid reasons it might not be
> implemented but the text will need to explain clearly the unfortunate
> consequences for security.  

When it comes to SHOULD, I think a good way to think of it is as an MUST, but
with escape clauses. And it is good to be explicit on the escape clauses that
are considered acceptable. 



> 
> Regarding staging, we need to treat encryption and client authentication
> separately.  For encryption, If the client and server implement this, it will
> be used.  There is no need for two stages.  With regard to client
> authentication, not sure what we will do, given the issues about
> fingerprinting recently discussed on the list.  If those are satisfactorily
> addressed before draft-ietf-nfsv4-security is ready, it might make sense to
> recommend implementation by client and server, especially where use of
> AUTH_SYS is anticipated.  If they aren't, we might see if a phased approach
> makes sense.

Agree that TLS for encryption without client authentication is still
opportunistic unless one have the policies and the methods for determining that
encryption SHALL be used. I think that requirement needs to come at that next
steps. 

> 
> We will discuss this on 4/22 as part of the rfc5661bis effort.

Good, it is expected that the update will have a mandatory to implement and use
security solutions to achieve a modern expected security level. 

 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------