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

Chuck Lever <chuck.lever@oracle.com> Sat, 27 June 2020 17:29 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 310283A0858; Sat, 27 Jun 2020 10:29:55 -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 bzjOs4JC-TYn; Sat, 27 Jun 2020 10:29:53 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 865623A0854; Sat, 27 Jun 2020 10:29:53 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05RHSWaf080421; Sat, 27 Jun 2020 17:29:51 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=731V/LJyeLT6ma83S/28a3K+CWeObptsMCzBTfq/Huk=; b=KGYclOJSfQX3C4rHAn85v03IDUYRUowneaAYtEHsR0oPny2Q9k59a/pA/trK+Wty019u bX1VfEMg6NSxx5ywNtDLl6kAsfPfQncuf/tNja2h9v0uolhrt4UOjmuuK41AiE3EzyK+ +asRDmRs/SYyfQwbIxKGl5FqlL529IgRjMZnz7w3aQKbkIrg2T6efsN84b6XkzSeD6F9 4NFuTHHHJXalD6BDytLRn80L64CfLTWTMhxUj8KEu8Amop/x5HDV6+bBLGVxgrfeucIs nO+sdLtB4XHSOMwWi6Y/qvLS85RWlka62APlvhZ/88dd4cx0jXUKTxWurlR7MhHHaRyl ew==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 31wwhr9d3f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 27 Jun 2020 17:29:51 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05RHERCa157497; Sat, 27 Jun 2020 17:27:50 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 31wwx18jkj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 27 Jun 2020 17:27:50 +0000
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 05RHRmsi009620; Sat, 27 Jun 2020 17:27:49 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 27 Jun 2020 10:27:48 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <159311856977.23665.6882641799899154823@ietfa.amsl.com>
Date: Sat, 27 Jun 2020 13:27:47 -0400
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org, David Noveck <davenoveck@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <797483BA-93B2-45AC-B2BC-044E905F40C9@oracle.com>
References: <159311856977.23665.6882641799899154823@ietfa.amsl.com>
To: Martin Duke <martin.h.duke@gmail.com>
X-Mailer: Apple Mail (2.3445.104.14)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9665 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 suspectscore=0 adultscore=0 mlxscore=0 spamscore=0 bulkscore=0 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006270125
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9665 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 phishscore=0 priorityscore=1501 clxscore=1015 cotscore=-2147483648 mlxscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 bulkscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006270126
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/MZ6fg5KjtrGlsj9ga33JJwaAcVU>
Subject: Re: [nfsv4] Martin Duke'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: Sat, 27 Jun 2020 17:29:55 -0000

Hi Martin-

Thank you for your comments.


> On Jun 25, 2020, at 4:56 PM, Martin Duke via Datatracker <noreply@ietf.org> wrote:
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This presumably a trivial fix but I think it's important enough to be a DISCUSS:
> 
> I think the document needs some discussion of the security properties of TLS1.3
> early data over TCP, if only to refer to Section 8 of RFC 8446 (replay) and
> mention that it is not forward-secure, unlike the rest of the payload.

We could extend the first paragraph of Section 7, as follows:

OLD:

7.  Security Considerations

   One purpose of the mechanism described in the current document is to
   protect RPC-based applications against threats to the confidentiality
   of RPC transactions and RPC user identities.  A taxonomy of these
   threats appears in Section 5 of [RFC6973].  Also, Section 6 of
   [RFC7525] contains a detailed discussion of technologies used in
   conjunction with TLS.  Implementers should familiarize themselves
   with these materials.

NEW:

7.  Security Considerations

   One purpose of the mechanism described in the current document is to
   protect RPC-based applications against threats to the confidentiality
   of RPC transactions and RPC user identities.  A taxonomy of these
   threats appears in Section 5 of [RFC6973].  Also, Section 6 of
   [RFC7525] contains a detailed discussion of technologies used in
   conjunction with TLS.  Implementers should familiarize themselves
   with these materials.

   Once a TLS session is established, the RPC payload carried on TLSv1.3
   is forward-secure. However, implementers need to be aware that replay
   attacks can occur during session establishment. Remedies for such
   attacks are discussed in detail in Section 8 of [RFC 8446].


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for this draft. I fully support bringing TLS into more use cases of
> this type.
> 
> Some comments:
> Sec 1.
> "Moreover, the use of AUTH_SYS remains common despite the adverse effects that
> acceptance of UIDs and GIDs from unauthenticated clients brings with it.
> Continued use is in part because:
> 
> Per-client deployment and administrative costs are not scalable. Administrators
> must provide keying material for each RPC client, including transient clients.
> Host identity management and user identity management must be enforced in the
> same security realm. In certain environments, different authorities might be
> responsible for provisioning client systems versus provisioning new users."
> 
> The text above says that something is still in use because..., and then
> mentions two things that are bad. I think the two items are supposed to refer
> to GSS?

Indeed, they do.

NEW:

   Moreover, the use of AUTH_SYS remains common despite the adverse
   effects that acceptance of UIDs and GIDs from unauthenticated clients
   brings with it.  Continued use is in part because:

   *  Per-client GSS deployment and administrative costs are not
      scalable.  Administrators must provide keying material for each
      RPC client, including transient clients.

   *  GSS host identity management and user identity management must be
      enforced in the same security realm.  In certain environments,
      different authorities might be responsible for provisioning client
      systems versus provisioning new users.


> Sec 4.2 This sure looks like normative text, so s/must not/MUST NOT "...
> utilize the remote TLS peer identity for RPC user authentication"

This paragraph formerly had MUST NOT, but was rewritten to address this issue:

  https://github.com/chucklever/i-d-rpc-tls/issues/5

There was a concern that the existing statement was not specific enough to make
it a compliance requirement. In particular, some implementations do want to use
the peer identity for access control decisions, though not on a per-user basis.

I'm open to some change here, but I'd like to hear suggestions about wording
to make the new compliance statement more actionable.


> Sec 5.1.2 Similarly, s/should/SHOULD "...employ ConnectionIDs of at least 4
> bytes in length."

No objection to using SHOULD.


--
Chuck Lever