Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
"Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> Mon, 08 April 2019 15:53 UTC
Return-Path: <tigran.mkrtchyan@desy.de>
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 D4E3A12043C for <nfsv4@ietfa.amsl.com>; Mon, 8 Apr 2019 08:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=desy.de
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 HAtF8zP0I2ov for <nfsv4@ietfa.amsl.com>; Mon, 8 Apr 2019 08:53:45 -0700 (PDT)
Received: from smtp-o-2.desy.de (smtp-o-2.desy.de [131.169.56.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCE71203EB for <nfsv4@ietf.org>; Mon, 8 Apr 2019 08:53:44 -0700 (PDT)
Received: from smtp-buf-2.desy.de (smtp-buf-2.desy.de [IPv6:2001:638:700:1038::1:a5]) by smtp-o-2.desy.de (Postfix) with ESMTP id D2403160169 for <nfsv4@ietf.org>; Mon, 8 Apr 2019 17:53:41 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp-o-2.desy.de D2403160169
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=desy.de; s=default; t=1554738821; bh=a5f2f8BcacISiUAQa1TBj4eI0/cR1Q0OcHLj1DPxK+w=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ocm3ssq+fwdpkfYh8qhuI30xeVZYURFS5ssEQRY1TXKAdDhfYZAIDhOwQAzes2sbJ 4RC+SYjjgiZYNjPPoj0edDrue+yOgghW57JutIfdPT0R6uQ9GXpaLR9TvDXFu0bFrz //+9jC6xNQDqaXnbGHJEsQmGU2d11Rr7w7PudUW0=
Received: from smtp-m-2.desy.de (smtp-m-2.desy.de [131.169.56.130]) by smtp-buf-2.desy.de (Postfix) with ESMTP id CB62F1A00B9; Mon, 8 Apr 2019 17:53:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at desy.de
Received: from z-mbx-2.desy.de (z-mbx-2.desy.de [131.169.55.140]) by smtp-intra-1.desy.de (DESY-INTRA-1) with ESMTP id 8F9723E901; Mon, 8 Apr 2019 17:53:41 +0200 (MEST)
Date: Mon, 08 Apr 2019 17:53:41 +0200
From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Chuck Lever <chuck.lever@oracle.com>, NFSv4 <nfsv4@ietf.org>
Message-ID: <1623176801.3604116.1554738821387.JavaMail.zimbra@desy.de>
In-Reply-To: <20190406032253.GK70202@kduck.mit.edu>
References: <154264272736.5235.8955444239583271708.idtracker@ietfa.amsl.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> <774FFC90-BC12-403B-8CBA-4D702AA7EBF5@oracle.com> <20190406032253.GK70202@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Zimbra 8.8.10_GA_3781 (ZimbraWebClient - FF66 (Linux)/8.8.10_GA_3786)
Thread-Topic: New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
Thread-Index: ogs2q9AWfTWDBvaDLf6qlesLkDObHw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/_410pQOfR_GpnjuFrAQxcCFm44w>
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: Mon, 08 Apr 2019 15:53:55 -0000
Some performance numbers on Dell PowerEdge R510 E5645 2.40GHz, TCP, single client single server over localhost sending op NULL: Benchmark (withTLS) Mode Cnt Score Error Units TlsOverhead.callOpNull true thrpt 25 12865.357 ± 135.963 ops/s TlsOverhead.callOpNull false thrpt 25 12802.179 ± 156.782 ops/s Looks like TLS overhead is ~0.5%. For each mode (with and without TLS) a 25 iterations of runs was performed. Each each iteration was running for 10 seconds and calling op null in a loop. Regards, Tigran. ----- Original Message ----- > From: "Benjamin Kaduk" <kaduk@mit.edu> > To: "Chuck Lever" <chuck.lever@oracle.com> > Cc: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>, "NFSv4" <nfsv4@ietf.org> > Sent: Saturday, April 6, 2019 5:22:54 AM > Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt > On Fri, Apr 05, 2019 at 10:35:39AM -0400, Chuck Lever wrote: >> >> >> > 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? > > Indeed, close_notify is basically unusable in the web world due to clients > just doing this. > >> >> > After TLS session termination any other RPC requests over the same connection >> > will fail with AUTH_ERROR. >> >> What about UDP with DTLS? > > (There's not a reliable way to do so.) > > -Ben
- [nfsv4] Fwd: New Version Notification for draft-c… Chuck Lever
- Re: [nfsv4] Fwd: New Version Notification for dra… Rob Thurlow
- Re: [nfsv4] Fwd: New Version Notification for dra… Chuck Lever
- Re: [nfsv4] Fwd: New Version Notification for dra… McDonald, Alex
- Re: [nfsv4] Fwd: New Version Notification for dra… Chuck Lever
- Re: [nfsv4] Fwd: New Version Notification for dra… Tom Talpey
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… Mkrtchyan, Tigran
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… David Noveck
- Re: [nfsv4] New Version Notification for draft-ce… Mkrtchyan, Tigran
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Mkrtchyan, Tigran
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Mkrtchyan, Tigran
- Re: [nfsv4] New Version Notification for draft-ce… Olga Kornievskaia
- Re: [nfsv4] New Version Notification for draft-ce… Lars Eggert
- Re: [nfsv4] New Version Notification for draft-ce… Lars Eggert
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Tom Talpey
- Re: [nfsv4] New Version Notification for draft-ce… Benjamin Kaduk
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Tom Talpey
- Re: [nfsv4] New Version Notification for draft-ce… Trond Myklebust
- Re: [nfsv4] New Version Notification for draft-ce… Trond Myklebust
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Tom Talpey
- Re: [nfsv4] New Version Notification for draft-ce… Olga Kornievskaia
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Olga Kornievskaia
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Olga Kornievskaia
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Olga Kornievskaia
- Re: [nfsv4] New Version Notification for draft-ce… Tom Talpey
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Mkrtchyan, Tigran
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Mkrtchyan, Tigran
- Re: [nfsv4] New Version Notification for draft-ce… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-ce… Benjamin Kaduk
- Re: [nfsv4] New Version Notification for draft-ce… Mkrtchyan, Tigran