Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

Chuck Lever <chuck.lever@oracle.com> Tue, 07 July 2020 17:45 UTC

Return-Path: <chuck.lever@oracle.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 A2DD53A07E0; Tue, 7 Jul 2020 10:45:01 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=oracle.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 m9KsiS0gm0Xa; Tue, 7 Jul 2020 10:44:59 -0700 (PDT)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 A6FDF3A07D6; Tue, 7 Jul 2020 10:44:59 -0700 (PDT)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 067HQcYA136639; Tue, 7 Jul 2020 17:44:56 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2020-01-29; bh=i08W55D8II78I7qjYpiUTcZGPJuzRFopDExUSYvp0rQ=; b=tuGCYCuR3UEfggWvBrBMGkWinHnE4zLvTQRfO0GNRygE1ZeYkZZ+Govh9zrvjVquEGj3 lOGOiXzFSPFpZ/aPCxKsXRy1DZ3DRiWcUodOmr0puj3NPg9y5JSA+sU4W5bI3BBe1EI5 wd+n5uyjADhWcZ9a73ELU4LcwHWDkTJMKgwPM1GuM1b9TTCUgKrzj2u5hgruaLFH5SBo a9OjWHqPsCZelj1H9svuQqVuurddiY9IHHsJaJM8uigE23Wmjmq6HT2DS2XB6lLGCrNp d8cekqRK5s+vgJtwS1K6CKdFQLc4stnWjrwkj6Q91rYl+ZSJa41vjHvjfdDH1XX+Ica6 2A==
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 323sxxt9b5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 07 Jul 2020 17:44:56 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 067HT4PN056064; Tue, 7 Jul 2020 17:42:56 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 324n4rjnvw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 Jul 2020 17:42:56 +0000
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 067Hgqip015728; Tue, 7 Jul 2020 17:42:52 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Jul 2020 10:42:52 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <159409225571.12966.1097397622994927028@ietfa.amsl.com>
Date: Tue, 7 Jul 2020 13:42:51 -0400
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <029E1A1C-A4AF-4F1F-8231-5ED8C26D8687@oracle.com>
References: <159409225571.12966.1097397622994927028@ietfa.amsl.com>
To: Roman Danyliw <rdd@cert.org>
X-Mailer: Apple Mail (2.3445.104.14)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9675 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 mlxlogscore=999 spamscore=0 adultscore=0 malwarescore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007070120
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9675 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxlogscore=999 bulkscore=0 impostorscore=0 adultscore=0 cotscore=-2147483648 phishscore=0 priorityscore=1501 clxscore=1015 malwarescore=0 suspectscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007070120
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/kRc1lKHwFElkYGwhQWxDo3f4lvg>
Subject: Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
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: Tue, 07 Jul 2020 17:45:02 -0000

Hi Roman-

This reply addresses COMMENTs regarding Section 7.

> On Jul 6, 2020, at 11:24 PM, Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** Section 7.3.  Per “… it is RECOMMENDED that when AUTH_SYS is used, every RPC
> client should present authentication materials to RPC servers …”, is this the
> same thing as saying that when AUTH_SYS is used a mutual authentication
> TLS-scheme is RECOMMENDED?  I concur with this approach.  I would just
> recommended saying that explicitly.

Possible replacement:

OLD:

   In light of the above, it is RECOMMENDED that when AUTH_SYS is used,
   every RPC client should present host authentication material to RPC
   servers to prove that the client is a known one.  The server can then
   determine whether the UIDs and GIDs in AUTH_SYS requests from that
   client can be accepted.

NEW:

   In light of the above, when AUTH_SYS is used, the use of a TLS mutual
   authentication mechanism is RECOMMENDED to prove that the RPC client
   is known to the RPC server.  The server can then determine whether
   the UIDs and GIDs in AUTH_SYS requests from that client can be
   accepted.


> ** Section 7.4.  Is there a reason not to use normative language in this
> section?  Specifically, RECOMMENDED for the first bullet and SHOULD for the
> second.

The reason not to use normative language is merely that we believe there are
no interoperability ramifications for choosing not to follow the suggestions.
Combined with the changes made to address your DISCUSS:

OLD:

   RPC-over-TLS implementations and deployments are strongly encouraged
   to adhere to the following policies to achieve the strongest possible
   security with RPC-over-TLS.

   *  When using AUTH_NULL or AUTH_SYS, both peers are required to have
      DNS TLSA records, keys with which to perform mutual peer
      authentication using one of the methods described in Section 5.2,
      and a security policy that requires mutual peer authentication and
      rejection of a connection when host authentication fails.

   *  RPCSEC GSS provides integrity and privacy services which are
      redundant when TLS is in use.  These services should be disabled
      in that case.

NEW:

   RPC-over-TLS implementations and deployments are strongly encouraged
   to adhere to the following policies to achieve the strongest possible
   security with RPC-over-TLS.

   *  When using AUTH_NULL or AUTH_SYS, both peers are RECOMMENDED to
      have DNS TLSA records, keys with which to perform mutual peer
      authentication using one of the methods described in Section 5.2,
      and a security policy that requires mutual peer authentication and
      rejection of a connection when host authentication fails.

   *  RPCSEC GSS provides integrity and privacy services which are
      redundant when TLS is in use.  These services SHOULD be disabled
      in that case.


--
Chuck Lever