[secdir] Secdir early review of draft-cel-nfsv4-rpc-tls-02

Alan DeKok via Datatracker <noreply@ietf.org> Mon, 18 March 2019 19:57 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA05A12798C; Mon, 18 Mar 2019 12:57:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alan DeKok via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: ietf@ietf.org, draft-cel-nfsv4-rpc-tls.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alan DeKok <aland@deployingradius.com>
Message-ID: <155293906683.26184.494210804985115598@ietfa.amsl.com>
Date: Mon, 18 Mar 2019 12:57:46 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/gs4hmxMb0AkMDdUpWPfUOIo6oOk>
Subject: [secdir] Secdir early review of draft-cel-nfsv4-rpc-tls-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2019 19:57:47 -0000

Reviewer: Alan DeKok
Review result: Not Ready

I think that the document is fairly good, but could use additional

It would a good idea for the authors to review RFC 6614 (RADIUS over
TLS) and RFC 7360 (RADIUS over DTLS).  Those documents both "patch"
RADIUS to allow for TLS / DTLS transport.  The RADIUS bits are perhaps
uninteresting, but it is useful to learn from previous approaches to
patching legacy protocols.

e.g. Section 1 of RFC 7360 says:

   The DTLS protocol does not add reliable
   or in-order transport to RADIUS.  DTLS also does not support
   fragmentation of application-layer messages, or of the DTLS messages

It may be worth using similar text in this document.  Also, Section
2.1 of RFC 7360 clarifies that the standad does not change anything
existing in the legacy protocol, but adding a DTLS layer may affect PMTU:

   We note that the DTLS encapsulation of RADIUS means that RADIUS
   packets have an additional overhead due to DTLS.  Implementations
   MUST support sending and receiving encapsulated RADIUS packets of
   4096 octets in length, with a corresponding increase in the maximum
   size of the encapsulated DTLS packets.  This larger packet size may
   cause the packet to be larger than the Path MTU (PMTU), where a
   RADIUS/UDP packet may be smaller.  See Section 5.2, below, for more

RFC 7360 also mandates support for particular TLS cipher suites, which is
lacking from this document.  I suggest adding text to address this issue.

There may be other TLS / DTLS issues in the RADIUS documents which apply here.

For this document:


   ... However, once encryption of the
   transport connection is established, the server MUST NOT utilize TLS
   identity for the purpose of authorizing RPC requests.

It may be worth reiterating that the protocols are independent.
i.e. This document does not define the *combination* of TLS and RPC,
so much as RPC carried over TLS.  The underlying RPC protocol is
largely unaware of the encapsulating TLS information.

Section 5:

   ... In circumstances where
   the users on that NFS client belong to multiple distinct security
   domains, it may be necessary to establish separate TLS-protected
   connections that do not share the same encryption parameters.

IMHO that's not a "may be necessary", but a hard requirement.  And the
last bit of that sentence should be clearer.  The users will each have
their own encryption credentials and profiles, I suspect.

Section 5.1:

   Therefore, the RECOMMENDED deployment mode is that both servers and
   clients have certificate material available 

Perhaps "configured and used" is better than "available".  An
certificate which is "available" may, in fact, be unused.