Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

Faibish.Sorin@dell.com Tue, 28 April 2020 12:54 UTC

Return-Path: <Faibish.Sorin@dell.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 AFB713A14AF for <nfsv4@ietfa.amsl.com>; Tue, 28 Apr 2020 05:54:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, 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=dell.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 C-xDJVOHbS-F for <nfsv4@ietfa.amsl.com>; Tue, 28 Apr 2020 05:54:10 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 EDA9C3A14AC for <nfsv4@ietf.org>; Tue, 28 Apr 2020 05:54:10 -0700 (PDT)
Received: from pps.filterd (m0170389.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03SCqOAh023478 for <nfsv4@ietf.org>; Tue, 28 Apr 2020 08:54:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=iH13J1caBjBk/2ARr5e37L4NRoTka3gLwwqt3ldw8jE=; b=xdHytAvHC4G05N5M8h7W5XFHrbS7sAPX7Byv5rpmbEw0Np2n91okUNKVqvkh/EUdSaQp hv/O8WYQ1TJL/WGa3eMbtaaJh/9tMFy6+uEIwJX6W7Cop8/pDnl483M9cU5O3jMt2/TV pvoDQipuBdRm0AQtSYOMc06Fcf3PP5bNyOB64ttbA8qqpC8DhI+RdYDshuQiWODV2Jgg kJ0XdpRYPpe0qsCvYjFjpbldt6mkEZrPCrUk9gD6I1Np5QFQPc2Os5YCDlKrB1Oj8rDC bHWgbFYOMni4zQ+WcCyiHnaanhgkYwG1uZM+sb3IjNOltYNkkYwaQleQEOalqq9eLPzm ng==
Received: from mx0b-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 30mh7m7b9s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <nfsv4@ietf.org>; Tue, 28 Apr 2020 08:54:10 -0400
Received: from pps.filterd (m0090350.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 03SCoepS089953 for <nfsv4@ietf.org>; Tue, 28 Apr 2020 08:54:10 -0400
Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by mx0b-00154901.pphosted.com with ESMTP id 30pm1crhgy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <nfsv4@ietf.org>; Tue, 28 Apr 2020 08:54:09 -0400
X-LoopCount0: from 10.166.132.152
X-PREM-Routing: D-Outbound
X-IronPort-AV: E=Sophos;i="5.60,349,1549951200"; d="scan'208";a="1550599466"
From: Faibish.Sorin@dell.com
To: chuck.lever@oracle.com, trondmy@gmail.com
CC: nfsv4@ietf.org
Thread-Topic: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls
Thread-Index: AdYH+TZCYEUSPG/KThqZ8Tp9CcZenQGzV2IAAAL5cwAAAEtAgAABZXsAAACq64AAAcUlAADsXEAAAG67XwAAjMK8gABUBYeAAA+uYIAAM8KPAAAAZcaAAAOJPwAABC0DAAAYYmUAABGAVYAAunYUgAALk2UAAAHPbQAAATGggAAKNfaAAADcioAAGMaS8A==
Date: Tue, 28 Apr 2020 12:54:07 +0000
Message-ID: <08d31d4ddc2f42faa9ea7b5462fd7463@x13pwdurdag1001.AMER.DELL.COM>
References: <VI1PR0702MB3775838FD12AB8A89392C17B95C90@VI1PR0702MB3775.eurprd07.prod.outlook.com> <FA2D661E-A787-4772-8F9D-A7594AE82F38@oracle.com> <CADaq8jciLWhL_FMmPcsdrVVS=9Gee8SYAsqi36H5v9iuNo7Pgw@mail.gmail.com> <E414F060-532B-4017-AC7E-5869884B2153@oracle.com> <e5796752c6204ffdd78503b1a9c9045cfd761e52.camel@gmail.com> <F9AC44CE-750E-416A-944D-E2382524020E@oracle.com> <19d2513b1093fc71223e361afca90d1a1ad6183a.camel@gmail.com> <E8D24949-C2A3-463A-953F-FAE7F46D4D23@oracle.com> <4e7912c6c55680f50b05aaa2cdc98f59733cd5b2.camel@ericsson.com> <C89BF8F3-7F65-4995-9CDB-CC1673E01463@oracle.com> <7833b21f09aaffdb35e1a578e2a07b533002d318.camel@ericsson.com> <7B26B15B-DE0C-4B6C-BBB0-D8F7B00EF328@oracle.com> <HE1PR0702MB3772D2EF118A844C6527171995D20@HE1PR0702MB3772.eurprd07.prod.outlook.com> <5CC44355-69D5-4C26-A976-FBECB182033D@oracle.com> <6f44c1ed7d6b4889cc2fdf6597fa032c32a98c75.camel@ericsson.com> <3FE13967-9805-4808-90ED-851B5FEF38DD@oracle.com> <0c882df033889200e038e068ba6d6977520072bf.camel@ericsson.com> <BB87D726-1A4C-4BAD-B67E-5869BF147646@oracle.com> <ff05325b40e8be64055af25b8dd22c8323565fd6.camel@ericsson.com> <83499FF8-BF16-46F4-9485-9694E3BB81D5@oracle.com> <CAABAsM5tUauO3tKAmSbqXKQ6zNRRMpM6Gx9BeR1WTDddHLP+og@mail.gmail.com> <94F6D6BE-F62E-4FAA-91E4-D70C6C69C581@oracle.com> <CAABAsM7w=mMV3XjsbTdHcCZ5QRTSq0BrVdLyqV1Rp-0zX6ObOw@mail.gmail.com> <73670430-85DE-4195-B9CB-B32DD6400A4F@oracle.com>
In-Reply-To: <73670430-85DE-4195-B9CB-B32DD6400A4F@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=faibish_sorin@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-04-28T12:54:05.0149865Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=cf3d85e5-329c-4617-8bc2-88a765d243a7; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.146.130.80]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-28_09:2020-04-28, 2020-04-28 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 bulkscore=0 impostorscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 adultscore=0 phishscore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004280100
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 clxscore=1015 suspectscore=0 bulkscore=0 priorityscore=1501 adultscore=0 mlxscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004280100
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/9m90EjumccsylnVoIxGTfBBXQYI>
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls
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, 28 Apr 2020 12:54:13 -0000


-----Original Message-----
From: nfsv4 <nfsv4-bounces@ietf.org> On Behalf Of Chuck Lever
Sent: Monday, April 27, 2020 5:02 PM
To: Trond Myklebust
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls


[EXTERNAL EMAIL] 



> On Apr 27, 2020, at 4:37 PM, Trond Myklebust <trondmy@gmail.com> wrote:
> 
> 
> 
> On Mon, 27 Apr 2020 at 11:45, Chuck Lever <chuck.lever@oracle.com> wrote:
> 
> 
>> > On Apr 27, 2020, at 11:11 AM, Trond Myklebust <trondmy@gmail.com> wrote:
>> > 
>> > 
>> > 
>> > On Mon, 27 Apr 2020 at 10:21, Chuck Lever <chuck.lever@oracle.com> wrote:
>> > Hi Magnus-
>> > 
>> > > On Apr 27, 2020, at 4:47 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
>> > > 
>> > > Hi,
>> > > 
>> > > I think that text works. However, that now recommends using a 
>> > > non-zero connection ID. From my perspective which have no 
>> > > implementation stake into this, this is fine. However, I would 
>> > > note that this backtracks on what was said just a few messages ago.
>> > 
>> > It's always possible I've gotten something wrong. However, I 
>> > realized that RPC on UDP permits an RPC server to use a different 
>> > network path to send a Reply than the path the client used to send 
>> > the matching Call. IIUC a substantial CID is needed to deal correctly with that situation.
>> > 
>> > 
>> > I don't think that matters. The server should always authenticate to the client during the D/TLS handshake, so there should be no ambiguity about the source of the replies.
>> 
>> The server is free to reply via any of its network interfaces. In 
>> other words, it can perform the handshake using one 5-tuple, then 
>> send replies via another (or send them via a mix of 5-tuples).
>> 
>> A CID is needed to handle NAT rebinding in any case. But IIUC 
>> rebinding would look like the client's 5-tuple changing, not the server's.
>> 
>> The question in mind is whether a DTLS session will be perturbed by 
>> the server's or client's 5-tuple changing. Magnus, can you elaborate 
>> on your earlier request for a clear statement about this in this 
>> section? Is this no longer a concern now that the REQUIREMENT to drop 
>> an out-of-session RPC Call?
>> 
>> 
>>   For RPC-on-DTLS, each DTLS handshake MUST include the connection_id
>>   extension described in Section 9 of [I-D.ietf-tls-dtls13].  RPC-on-
>>   DTLS peer endpoints SHOULD provide a ConnectionID with a non-zero
>>   length.  Endpoints implementing RPC programs that expect a
>>   significant number of concurrent clients should employ ConnectionIDs
>>   of at least 4 bytes in length.
>> 
>> Also, I'm not certain if SHOULD is correct here. Instead, "should" or 
>> "MUST" might be less ambiguous. However, if we all agree the 
>> statement is totally unnecessary, it can be replaced or dropped.
>> 
> 
> I'm saying that it doesn't matter from what network interface, or indeed which breed of carrier pigeon the server chooses, The client can still authenticate the reply as being genuine from the fact that the server authenticated to it at the start of the DTLS session. As long as this is still the same session, then the client can ignore any changes to the network topology.

My reading of draft-ietf-tls-dtls-connection-id suggests that is not the case for DTLS 1.2 and later.

Abstract says:

   A CID is an identifier carried in the record layer header that gives
   the recipient additional information for selecting the appropriate
   security association.  In "classical" DTLS, selecting a security
   association of an incoming DTLS record is accomplished with the help
   of the 5-tuple.  If the source IP address and/or source port changes
   during the lifetime of an ongoing DTLS session then the receiver will
   be unable to locate the correct security context.

Further, the Introduction states:

   In the current version of DTLS, the IP address and port of the peer
   are used to identify the DTLS association.  Unfortunately, in some
   cases, such as NAT rebinding, these values are insufficient.  This is
   a particular issue in the Internet of Things when devices enter
   extended sleep periods to increase their battery lifetime.  The NAT
   rebinding leads to connection failure, with the resulting cost of a
   new handshake.

Unless I'm reading this wrong, if either peer sees a DTLS datagram from a different IP address than was used during the DTLS handshake, it's not going to be able to associate that with a previously established DTLS session... unless there's a CID.

The DTLS handshake and the subsequent DTLS record exchanges are two separate protocols. The CID is exactly the material that the peers need to determine that the remote sender is the same peer that established that DTLS session.

[sf] I reviewed the latest draft and I have some questions and concerns related to section 7.2 it is defined the TLS management on clients:
"The RPC-on-TLS protocol by itself cannot protect against exposure of a user's RPC requests to
other users on the same client.
Moreover, client implementations are free to transmit RPC requests
for more than one RPC user using the same TLS session. Depending on
the details of the client RPC implementation, this means that the
client's TLS identity material is potentially visible to every RPC
user that shares a TLS session."

I see two issues with this:
1.	If there is a compromised user running on same client it is possible that the compromised user can "see" the identity material of the legitimate users.
2.	It is possible that a compromised user initiate a DDoS attack on the server and the server will not detect the attack as it comes from a legitimate host and encrypted. This may expose a server to undetected DDoS attacks.

Also the question is do we allow a mix of users using TLS and others not using TLS on same client? I understand that we don't support multiple TLS on same connection but do we support a mix? Some explanation/clarification text will be useful.

./Sorin
--
Chuck Lever



_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4