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

"Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> Thu, 04 April 2019 19:52 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 BEB2E1204EB for <nfsv4@ietfa.amsl.com>; Thu, 4 Apr 2019 12:52:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 Khdw4Co70YHg for <nfsv4@ietfa.amsl.com>; Thu, 4 Apr 2019 12:52:25 -0700 (PDT)
Received: from smtp-o-2.desy.de (smtp-o-2.desy.de [IPv6:2001:638:700:1038::1:9b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BBB1204D7 for <nfsv4@ietf.org>; Thu, 4 Apr 2019 12:52:24 -0700 (PDT)
Received: from smtp-buf-3.desy.de (smtp-buf-3.desy.de [131.169.56.166]) by smtp-o-2.desy.de (Postfix) with ESMTP id 0A558160082 for <nfsv4@ietf.org>; Thu, 4 Apr 2019 21:52:22 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp-o-2.desy.de 0A558160082
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=desy.de; s=default; t=1554407542; bh=46V6ckupsZFkJRZ6kPol0bj5tBxOsO9mmrq++Y2MVUE=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=qOvI2gOQalGzIgZXXWKipwlZFcN7L1A53Ec864Go8dI6aXcB2QR6RKAf0+PG+Bbvk oj9zMpSgjOxT5AKXgJmmargmXVlLwV0aOZPQiNkVW7XM5curiK1e5e4QStk/QSD3i0 2y+FtU57NkdSOysGThBIzky02C/LVuwnFvsiMSXU=
Received: from smtp-m-3.desy.de (smtp-m-3.desy.de [131.169.56.131]) by smtp-buf-3.desy.de (Postfix) with ESMTP id 04916A0077; Thu, 4 Apr 2019 21:52:22 +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 BFB313E901; Thu, 4 Apr 2019 21:52:21 +0200 (MEST)
Date: Thu, 4 Apr 2019 21:52:21 +0200 (CEST)
From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: NFSv4 <nfsv4@ietf.org>
Message-ID: <2054230647.2997716.1554407541660.JavaMail.zimbra@desy.de>
In-Reply-To: <6183F452-B7AC-4925-A6A8-472FB1FBF9C5@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: 5F6sA+ivGC1etmhHTpwMYRjMtRQnxA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/tJJg9heItzrTK9WcPSsrmvg1N9g>
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: Thu, 04 Apr 2019 19:52:28 -0000

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 sould be part of your document is the handling of TLS session
termination. Something like (please make it rfc language compliant):


   Client can terminate the TLS session after sending a TLS closure alert.
   After TLS session termination any other RPC requests over the same connection
   will fail with AUTH_ERROR.


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