Re: [secdir] Secdir early review of draft-cel-nfsv4-rpc-tls-02
Chuck Lever <chuck.lever@oracle.com> Tue, 19 March 2019 16:54 UTC
Return-Path: <chuck.lever@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DD7128CF2; Tue, 19 Mar 2019 09:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 9kxmI4iNKJoe; Tue, 19 Mar 2019 09:54:38 -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 428DC131106; Tue, 19 Mar 2019 09:54:35 -0700 (PDT)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2JGsAOG182979; Tue, 19 Mar 2019 16:54:31 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-2018-07-02; bh=Urfl3xyTjnDHl7hF3XinuFQqtgORL1tCkDbpf2sXabM=; b=Mkqo+x75l9R/YGwvEMo6udUzGy/s+WBkMg6Pr8GB4uN1hg7teu0Oj8FaLHZEpAsmmiwj D0SUthMByG9c2vCdiy3V7T00ZCaTUTMIRvL406umVWWXqskqdWE+guNwYiwky83CDXdf xQTSxdxQxghSGzvCx5hweJ648PF3f7+hwIaoxM1R9ahvpn5e3hEdJTxzGUBu4jW23kWr zHNwHZNgzQ8HYGqpqZ1gOTtGBnaDfSDqhKtGSEJw56k+gg81KfUfjcpfq35aRWezoJ91 nncsMPJgK9ar9BRVtHv1NaUOMxBaNmh4nhpTfFTk2v66wy0jlGuzQVHOZq+6C+ZoROvX ZQ==
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2r8ssrdwy4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Mar 2019 16:54:31 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x2JGsPNd031259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Mar 2019 16:54:25 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2JGsOSC004586; Tue, 19 Mar 2019 16:54:24 GMT
Received: from [100.66.188.10] (/198.214.85.110) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 19 Mar 2019 09:54:24 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <155293906683.26184.494210804985115598@ietfa.amsl.com>
Date: Tue, 19 Mar 2019 11:54:24 -0500
Cc: secdir@ietf.org, ietf@ietf.org, draft-cel-nfsv4-rpc-tls.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <60B01F34-8041-4A6A-8479-6F19F9BFCDBE@oracle.com>
References: <155293906683.26184.494210804985115598@ietfa.amsl.com>
To: Alan DeKok <aland@deployingradius.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9200 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903190124
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/jnHC6yJ3njMhUYp1QI_OtxTseVI>
Subject: Re: [secdir] Secdir early review of draft-cel-nfsv4-rpc-tls-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Tue, 19 Mar 2019 16:54:41 -0000
> On Mar 18, 2019, at 2:57 PM, Alan DeKok via Datatracker <noreply@ietf.org> wrote: > > Reviewer: Alan DeKok > Review result: Not Ready > > I think that the document is fairly good, but could use additional > text. Alan, thank you for your comments. We will review the RADIUS documents and try to integrate these comments into the next revision of draft-cel-nfsv4-rpc-tls. One question below: > 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 > themselves. > > 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 > discussion. > > 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: > > 4.3.2 > > ... 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. It is true that the RPC protocol is unchanged (except for the addition of AUTH_TLS). However, I'm not clear what triggered your comment. Can you expand a bit? > 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. > > -- Chuck Lever
- [secdir] Secdir early review of draft-cel-nfsv4-r… Alan DeKok via Datatracker
- Re: [secdir] Secdir early review of draft-cel-nfs… Chuck Lever
- Re: [secdir] Secdir early review of draft-cel-nfs… Alan DeKok