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

Chuck Lever <chuck.lever@oracle.com> Tue, 30 June 2020 13:59 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 72AC73A089B; Tue, 30 Jun 2020 06:59:46 -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 KJTF2D80HpyQ; Tue, 30 Jun 2020 06:59:44 -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 322603A08CA; Tue, 30 Jun 2020 06:59:44 -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 05UDvKUY140554; Tue, 30 Jun 2020 13:59:40 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=MwXS68LSw4083obeE92+VFEcF/HDVgNrsoU3QaaLwhY=; b=typIpKM3ftqmCzOiCgaJeUgb2afrrBdZEgjvAILefqrUfIxbjK1fRxYXasJJKQu7VgYE 4bOtwsL6DIz8FsCQc/n0Lpc6EHUFOmyc6p1ITTsa7PdKJniw0exYHiyd8eB0hDKIcRKA VIqMkr8KEMLbdngL2lw46+c45Quq/7sDqir0ptGsPqPTYzx5Ac+Ux2/+Hgy5xL+r81j6 ak7sCGX6I014FuKqX5FVspmYeTYV2i9DK3XxHr/Bpy6+stbaJ6kcbfT8K/7VB/loAMl2 IeIWZPHka21NsMANEfJOVM/Fdt90B9NHk8UVpdam1GUVGJF5/+UnuO1QTMO7X0cLA9Du bw==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 31ywrbjx24-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Jun 2020 13:59:40 +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 05UDqfKD013608; Tue, 30 Jun 2020 13:57:40 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 31xg13f2cc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Jun 2020 13:57:39 +0000
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 05UDvcd9001463; Tue, 30 Jun 2020 13:57:38 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 30 Jun 2020 13:57:38 +0000
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: <CAM4esxTnn5HCz6XKHEE5U31VhtptoUUfX1qhEZimm=-b1puq6g@mail.gmail.com>
Date: Tue, 30 Jun 2020 09:57:35 -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: <A2B9E84A-8DF2-43D9-8D28-C273437B9F01@oracle.com>
References: <159311856977.23665.6882641799899154823@ietfa.amsl.com> <797483BA-93B2-45AC-B2BC-044E905F40C9@oracle.com> <CAM4esxRCvw2vMwmcDS8NrZAvsJaY5U+QFV9o0R1O2mKpABdDhA@mail.gmail.com> <CAM4esxTnn5HCz6XKHEE5U31VhtptoUUfX1qhEZimm=-b1puq6g@mail.gmail.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=9667 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 bulkscore=0 mlxscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006300100
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9667 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 mlxlogscore=999 clxscore=1015 cotscore=-2147483648 priorityscore=1501 lowpriorityscore=0 malwarescore=0 mlxscore=0 adultscore=0 suspectscore=0 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006300101
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/iWFK2PGp4mM_mFH9WW1udsexiCU>
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: Tue, 30 Jun 2020 13:59:47 -0000

Hi Martin -

> On Jun 29, 2020, at 2:38 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> Oops, hit send too early.
> 
> In either of these modes, RPC user authentication is not affected by
>    the use of transport layer security.  When a client presents a TLS
>    peer identity to an RPC server, the protocol extension described in
>    the current document provides no way for the server to know whether
>    that identity represents one RPC user on that client, or is shared
>    amongst many RPC users.  Therefore, a server that wishes to
> authenticate clients in accordance with Section 7 of [RFC5531] MUST
> use an auth_flavor other than AUTH_TLS in a call message after the 
> TLS handshake is complete.
> 
> This suggestion is meant to be helpful and is non-blocking in my review.

It turns out the document already has such a compliance requirement
in Section 4.1:

   If an RPC client uses the AUTH_TLS authentication flavor on any
   procedure other than the NULL procedure, or an RPC client sends an
   RPC AUTH_TLS probe within an existing (D)TLS session, the RPC server
   MUST reject that RPC Call by setting the reply_stat field to
   MSG_DENIED, the reject_stat field to AUTH_ERROR, and the auth_stat
   field to AUTH_BADCRED.

I'm considering the following replacement, which is directly on point
with the discussion that led to the OLD text. It replaces the ambiguous
"must not".

OLD:

   In either of these modes, RPC user authentication is not affected by
   the use of transport layer security.  When a client presents a TLS
   peer identity to an RPC server, the protocol extension described in
   the current document provides no way for the server to know whether
   that identity represents one RPC user on that client, or is shared
   amongst many RPC users.  Therefore, a server implementation must not
   utilize the remote TLS peer identity for RPC user authentication.

NEW:

   In either of these modes, RPC user authentication is not affected by
   the use of transport layer security.  When a client presents a TLS
   peer identity to an RPC server, the protocol extension described in
   the current document provides no way for the server to know whether
   that identity represents one RPC user on that client, or is shared
   amongst many RPC users.  Therefore, a server implementation cannot
   utilize the remote TLS peer identity to authenticate RPC users.

There is an implication here that, if a server has other means to know
whether the client's TLS identity represents a specific RPC user, then
it is feasible to use that identity to authenticate that user. That's
why we removed the restrictive compliance language.


> On Mon, Jun 29, 2020 at 11:35 AM Martin Duke <martin.h.duke@gmail.com> wrote:
> All of these changes are satisfactory, thanks.
> 
> On the issue of  Sec 4.2:
> I am not knowledgeable about this, but how about:
> OLD:
>    In either of these modes, RPC user authentication is not affected by
>    the use of transport layer security.  When a client presents a TLS
>    peer identity to an RPC server, the protocol extension described in
>    the current document provides no way for the server to know whether
>    that identity represents one RPC user on that client, or is shared
>    amongst many RPC users.  Therefore, a server implementation must not
>    utilize the remote TLS peer identity for RPC user authentication.
> 
> NEW:
>    In either of these modes, RPC user authentication is not affected by
>    the use of transport layer security.  When a client presents a TLS
>    peer identity to an RPC server, the protocol extension described in
>    the current document provides no way for the server to know whether
>    that identity represents one RPC user on that client, or is shared
>    amongst many RPC users.  Therefore, a server that wishes to authenti
> 
> 
> 
> 
> 
> 
> 
> On Sat, Jun 27, 2020 at 10:29 AM Chuck Lever <chuck.lever@oracle.com> wrote:
> 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