Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

Chuck Lever <chuck.lever@oracle.com> Fri, 05 April 2019 14:36 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 32916120455 for <nfsv4@ietfa.amsl.com>; Fri, 5 Apr 2019 07:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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, 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 6aUXgmnStuH2 for <nfsv4@ietfa.amsl.com>; Fri, 5 Apr 2019 07:36:00 -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 BF6CD12044F for <nfsv4@ietf.org>; Fri, 5 Apr 2019 07:36:00 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x35EXlGg146610; Fri, 5 Apr 2019 14:35:52 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=R0gOQnjHOyJbIcMRHmI8iLQqoaO5fj2wYNHU6+ejdrU=; b=rkKG7QhYd4QTwyz+B8Q7WaJXy/r+A5Y5eDbK12ST99BTeeSeP4yRHENEtNyV6gkX/lOI Fzs7qxA/mi1LCVpyTI6LIfuXNvX/knXhUl4g30Z89W32Lr0TPK0uepEIT66Nq37zHXsa wQwg9ncu2xywzWOB47AliL0sbpQEh+OJf5E0Y8yb/wsF7aTimqPJ18JYwJjhlulreYpS NKS+Nn7iYYTUQevI1MI/m96M3+LQTHbecYZCfftVgsh22+aVC/IgcR0xyu+7KQ6CKp8q vhjoxBC6EHF1IgqH+0lKL+sh5CsJ+cCxnzdH927v28v0WFrhzuO5/hC0NqKbUQiry7wX sA==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2rhyvtn8k6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Apr 2019 14:35:51 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x35EZRhD044205; Fri, 5 Apr 2019 14:35:50 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 2rp35rw5ba-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Apr 2019 14:35:50 +0000
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x35EZfQ2014859; Fri, 5 Apr 2019 14:35:41 GMT
Received: from anon-dhcp-171.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Apr 2019 07:35:41 -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: <2054230647.2997716.1554407541660.JavaMail.zimbra@desy.de>
Date: Fri, 05 Apr 2019 10:35:39 -0400
Cc: NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <774FFC90-BC12-403B-8CBA-4D702AA7EBF5@oracle.com>
References: <154264272736.5235.8955444239583271708.idtracker@ietfa.amsl.com> <BA8346C3-F491-42B6-8059-6DDAE52C58BA@oracle.com> <CAN-5tyEwvjSD59XhKdqshN3F57avh=3uOGjOCE5vf8R4u2FA4Q@mail.gmail.com> <C7FFE084-0192-40F1-929D-E9DA1F4BBAE7@oracle.com> <CAN-5tyFAJ6fN6GHz8Ecr3i6aQV+wGqvbdStqxruMs6Pw+Dppaw@mail.gmail.com> <A9AF8062-B9FC-425D-9E50-FC890065BBE1@oracle.com> <916629036.2643205.1554327076610.JavaMail.zimbra@desy.de> <6183F452-B7AC-4925-A6A8-472FB1FBF9C5@oracle.com> <2054230647.2997716.1554407541660.JavaMail.zimbra@desy.de>
To: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9217 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904050100
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9217 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=1015 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-1904050100
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/w58kCn74HPXX1UqTP2O4jwiTgws>
Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
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: Fri, 05 Apr 2019 14:36:03 -0000


> On Apr 4, 2019, at 3:52 PM, Mkrtchyan, Tigran <tigran.mkrtchyan@desy.de> wrote:
> 
> Hi Chuck,
> 
> ----- Original Message -----
>> From: "Chuck Lever" <chuck.lever@oracle.com>
>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>
>> Cc: "NFSv4" <nfsv4@ietf.org>
>> Sent: Thursday, April 4, 2019 4:32:55 PM
>> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
> 
>> Hi Tigran-
>> 
>>> On Apr 3, 2019, at 5:31 PM, Mkrtchyan, Tigran <tigran.mkrtchyan@desy.de> wrote:
>>> 
>>>>>>> 3. Section 4.2.3 "Advanced forms of RPC authentication". I'm surprised
>>>>>>> to see this here because of the wording in Section 1. Specifically it
>>>>>>> says: "An alternative approach is to employ transport layer security
>>>>>>> mechanism". Here alternative was to the GSS mechanism which was listed
>>>>>>> as "hard to use". So nowhere was there a talk that TLS connection can
>>>>>>> be used with a GSS mechanism. Is this section suppose to be about the
>>>>>>> fact that RPCSEC GSS besides authentication also provides an encrypted
>>>>>>> connection? Then I think the section title should be changed to
>>>>>>> "RPCSEC GSS secure connection establishment"?   This section,blurs the
>>>>>>> lines of RPC identify authentication via GSS identities and the TLS
>>>>>>> authentication. In previous two section, it wasn't discussed what kind
>>>>>>> of RPC authentication would happen on top of the TLS connection. I
>>>>>>> think this whole section should be removed. Because it basically says
>>>>>>> there is no need to use GSS privacy/integrity since underlying TLS
>>>>>>> connection already provides that and since TLS is suppose to be
>>>>>>> alternative to GSS so why combined it.
>>>>>> 
>>>>>> We have to discuss the use of channel binding somewhere, and
>>>>>> we have to discuss the double host authentication because TLS
>>>>>> has a host authentication step and so does GSS. I don't see any
>>>>>> discussion of user authentication here.
>>>>> 
>>>>> I would have re-organized this to be something like:
>>>>> 
>>>>> 4.2 Establishing an end-to-end encrypted channel
>>>>> same paragraph as before about providing a transparent end-to-end
>>>>> encrypted channel for the RPC operations.
>>>>> 4.2.1 TLS server-only authentication
>>>>> (same as before)
>>>>> 4.2.2 TLS mutual authentication
>>>>> (same as before)
>>>>> 4.3.3 Role of the RPCSEC GSS integrity and privacy services
>>>>> Here talk about redundancy of using GSS services on top of TLS.
>>>>> Channel binding would go here.
>>>>> 
>>>>> 4.3 RPC authentication on top of an encrypted channel
>>>>> Here talk about how any of the existing methods (AUTH_SYS, GSS) can be
>>>>> overplayed on top of the encrypted channel.
>>>> 
>>>> I'm not sure this warrants its own subsection. I'll look into
>>>> explicitly stating that RPC user authentication is not altered
>>>> by transport encryption earlier in Section 4.
>>>> 
>>>> Hopefully the new language will not forbid someday specifying
>>>> user authentication via certificates. For now I would like to
>>>> keep this document narrowly focused on providing transport
>>>> encryption.
>>> 
>>> In GRID computing, dealing with end-user certificates is the main
>>> reason why we try to move away from X509. Proxy certificates
>>> with limited life time to pass around with, LDAP configs,
>>> renewal, trusted CA distribution, CRLS, legal requirements to
>>> present ID-card to get a certificate in the first place...
>>> However, RPC is not only NFS. We have accelerator control systems,
>>> that use AUTH_NONE with IP table rules.
>> 
>> Indeed, this is a use case that is interesting to me as well.
>> In cases where a transient cloud service is spun up that has
>> no local user identities, AUTH_NONE would be appropriate to
>> use.
>> 
>> 
>>> And, in general, many
>>> server-to-server RPC based communication will benefit from
>>> client+server mutual authentication. For example pNFS deployment,
>>> where DSes talk to MDS and both want to be sure that the other
>>> side is the right one.
>> 
>> This sounds like what Trond is most interested in.
>> 
> 
> With a deployment dedicated CA it's an easy way to
> control which hosts belongs to the instance. We do
> it for our internal message communication.
> 
>> 
>>> IOW, don't require it, but keep it possible.
>> 
>> I'm not sure exactly what you would like to see.
>> 
>> - The option to use user certificates for host authentication
>> specified in this document.
>> 
>> - The option to use user certificates for host authentication
>> left open for a future specification.
>> 
>> - The option to use user certificates for user authentication
>> specified in this document.
>> 
>> - The option to use user certificates for user authentication
>> left open for a future specification.
>> 
> 
> 
> Let's have a look and HTTP-over-TLS (rfc2818). No special requirement
> for client authentication. The TLS spec (rfc8446) says:
> 
>   4.3.2.  Certificate Request
> 
>      A server which is authenticating with a certificate MAY optionally
>     request a certificate from the client. 
> 
> The combination of it I read as: server configuration controls is client
> certificate requested or not. Thus, leave it to TLS configuration.
> 
> But what should be part of your document is the handling of TLS session
> termination. Something like (please make it rfc language compliant):

Makes sense. Questions below:


>   Client can terminate the TLS session after sending a TLS closure alert.

What if a client closes the connection without terminating
the TLS session?


>   After TLS session termination any other RPC requests over the same connection
>   will fail with AUTH_ERROR.

What about UDP with DTLS?


> Regards,
>   Tigran.
> 
> 
>> Enabling user certs at all seems like it could add significant
>> complexity to the document, and IIUC the use of user certs
>> might need some involvement with the protocol being carried
>> by RPC. That's why my preference would be to defer this
>> complexity to other specifications, if we can.
>> 
>> The next revision is evolving here:
>> 
>> https://github.com/chucklever/i-d-rpc-tls/tree/master
>> 
>> The Editor's Copy is the latest work, and there is a link
>> under that to generate an rpcdiff with the revision that was
>> submitted earlier this week to the datatracker.
>> 
>> 
>> --
>> Chuck Lever
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever