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

Rick Macklem <rmacklem@uoguelph.ca> Tue, 07 December 2021 00:56 UTC

Return-Path: <rmacklem@uoguelph.ca>
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 3FA183A0D0D for <nfsv4@ietfa.amsl.com>; Mon, 6 Dec 2021 16:56:17 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=uoguelph.ca
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 E2QxfjMhQDI3 for <nfsv4@ietfa.amsl.com>; Mon, 6 Dec 2021 16:56:12 -0800 (PST)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0620.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::620]) (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 3D7CD3A03EE for <nfsv4@ietf.org>; Mon, 6 Dec 2021 16:56:11 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UwzV6f6hda3psbruWLncbp2wPTfZXmZNEWNOLaQ29+gEKrbEbS/ylF8m5gWC19fC+vaHNGAPeLLyhhh95ACUOpD743rh14lhfmhPeC31aZ2oU3ILRXE66mKfg1eyLEGHfXSylOCwzFgYH6KhLPdcdRyZWJOI5uiY3gLNw8K2CQlrWgsLrLsrWREm/ljLRW4Fq/g1XI2FEUVqgq4/2La6oUzWVMY6Gu0CoeK5qzB7lwfvnmrXe6+pamDZaFiyTPsdupEgGZHjdtI7w67x+PtQrouy0teChuMyA39GDHPlSldFhm7KeLwjIOPJiPKMVad7BP7B0nKjTTVdLmpgdI+W6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wiclY5LrV0qNaUzFto9GHhsw44K8nPE+x+ULAZOwDMU=; b=SPTMsw00Oujztyt+uI/OoLKkqudQMFZWc8CFdSFlKe2FoeIiy/iJANvCQFtoh/hj2Dla/3ZMB1KxnwzsdpWaSOnvNpnN70c4RKJ7A+0FYvjdPtvrMY/222pBI4p3m9rAf9lt1i0Tn+gdc4e0qkDGaezELtfniJ/NDgCMEs7eQx+7bjOBHFmA+/4llpUdx36/Kqy6sxrnOM6hF/vcSxo6t4R5dtHfi4evbACXsZcnL88qX26O1eIEmTzNxvh8kc3WXB5P2iBDcgk07+d7HOfjQgCAZ53J+Khp6tCNe3FOSEBfcHwQaPY1jxwjjXxrKg8yOEQL5ZQ09xZfjBDwt/KVJQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wiclY5LrV0qNaUzFto9GHhsw44K8nPE+x+ULAZOwDMU=; b=ZE6nAc31dROb7g5abCNen42hVo/EYQodrBkm2LW5eN3Z1Ohh9k2R+A43u2Ed+r4tjr3Vn+K57cgQN3pjgXsVQ7e9JWkWI5TZPwj0IhNhtk51eLM1o3KdorRuuansEYjlmrz3zdfOSgZKsEXR38m+MYaQzMMSFGVHlLL2WItMDGqhLD61PmZj2+Svm2ltKiYcFdRryykN59pZNmGr5q1CDfWPI1wu4rVkoge/n7c6dR7hUyd3rwR5YsM2ZQ0YJNgK76OLvuBdC7hQNqQvREyIBd3IQfvdBP+4Q2E2Y16bv+7z0nr7pmLsWLHZ6cyKM2rpc0SJC1jEMBOEnaGnjwBxNg==
Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by QB1PR01MB3076.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:3e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Tue, 7 Dec 2021 00:56:06 +0000
Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::e56f:b7a2:3830:5706]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::e56f:b7a2:3830:5706%3]) with mapi id 15.20.4755.022; Tue, 7 Dec 2021 00:56:06 +0000
From: Rick Macklem <rmacklem@uoguelph.ca>
To: Chuck Lever III <chuck.lever@oracle.com>
CC: "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
Thread-Index: AQHX6hAa5Iy4UaEkKUeUmSSqi5G97awktqlCgADjywCAAG4ZaoAAHAuAgAAM2Jk=
Date: Tue, 07 Dec 2021 00:56:05 +0000
Message-ID: <YQXPR0101MB096809E7D3A34CE1FAA0D484DD6E9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
References: <163873328734.5490.15468230922208392053@ietfa.amsl.com> <856F08E9-CDFD-43B5-B8B1-278BE0DA7339@oracle.com> <YQXPR0101MB0968E2DC868A17423FF8D8B7DD6D9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <56914C1D-97BC-4225-AFD3-01F2CE096C8A@oracle.com> <YQXPR0101MB096887BF90B0107899DBDBC8DD6D9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> <C1CB89D1-1D5B-4CC8-ACC9-27AFAE73F538@oracle.com>
In-Reply-To: <C1CB89D1-1D5B-4CC8-ACC9-27AFAE73F538@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
suggested_attachment_session_id: 1ad479be-675b-3101-5401-8d260a134281
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=uoguelph.ca;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c6b24194-1f40-469b-8fef-08d9b91c5971
x-ms-traffictypediagnostic: QB1PR01MB3076:EE_
x-microsoft-antispam-prvs: <QB1PR01MB3076E71F165DDFCE9E706A40DD6E9@QB1PR01MB3076.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Zh+LRx7kOBcOybIIFxdj62ksdP6+xy0LL/KCSNlKSiCI3HevJ+L8NFPAm42A/k2IlidYq5IqwGFDrBUg0hlizouZvC0Wv15IiUlGDfPLvpZ5WtNZEg8L9Yt+c58tzwJ1qRqTulNU6dr+I0AlvIwacTBrLGaJjLjEaTklfh/H/ECf6JpqOj8PMWPo5lOQAk8Yc0eIyDoPLmwqFHFBTKjeaYp6HO3xmFv/S9JthF3WuzpgXlDJHxKdJqDbolJMtGHxvSHZQSWoppVvtHc/n/6nMbDxYQFCxsBTMMGopaMKyazYQqlIrh46pYONpcRMr44xtVO+lBcE+qebFS9S+i7x1Bbe8ewRSyn74X8E3ruN4CMX2cntf5gFmN6p6Qya8uoigz2eKIylfqs/1B5ppvCP9spjCg8FDiFgqHJHUBrsLjK/MgUtbWd1qtG560EzNnJXMyWgNqBtRNree+KH9RgVpnY8QCCP55BdWxdieR9B0y/QMSEW0QiWSREenxk0xoDdm06JsAwQ/5cCIP9S/Df/whsI6ImlgEcWSmQRCHOzvH/ugrWvkaBbRWn4REA1TvwwZmc06s1zuK16yXOsaiuReFQ1bSG6MUuB85Vr8Dj0QkH2XpCfSXseKkbiA3KygRQjeRk0p805vCoMROkd+JZb0XgJhiy+/sKJe/hU2J96doAMzIlMmKKSUbckLLgyCWVsMYu2th3KutZSUm3d/4uSC4P42mnFdQCBqqKc/aYq/oOq1cymZXN1h/P3+dqtAVxQn2lmP9iIhPo9zpzJQkZ8y0HWKBsIOHoQgmPwC6jJej8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(508600001)(52536014)(15650500001)(66574015)(64756008)(66556008)(66446008)(8936002)(2906002)(7696005)(316002)(66476007)(5660300002)(786003)(966005)(66946007)(8676002)(9686003)(4326008)(6506007)(122000001)(86362001)(38100700002)(76116006)(71200400001)(53546011)(55016003)(6916009)(186003)(33656002)(83380400001)(38070700005)(91956017); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 4gjilyAyK4y76MeipWS1j+FiHAXlC0iab99yjc+0GXN3130NEfbZMzynDy1o8K7PwWQFrf0WqQEdg9kIC1bYTZJpgMUQ/Bb4YUq0gnBIJuFDVCGy9eUQFYA2AT8pSv2YHXDRvUy15mSR+e0xT9ql1vgYVEEsOON55OrEV4u6DxB28zkT56aJNjvEHikfOAMkDFuEdxsXiLRyZDejUM+rbS/rmdZ265zxWg/2HJnz0tPVifFMsXIQU/8/3IVP9FZllzwYCEmZ8mb0VDCmIC0xG1Dd4dsWpBSh5ObZVK0659IJej0045uz1ALqoTtwxtyEzCVvV1EtoCQqxxuUaKKYnYGD8jxKQj2t31FYdBui/hXwXxf7zrp1v5ho9yu+MjCwc0uiTZKvBMoCou5ghxwNjbOkeqYES33lUPhLsqYSFuJ5j7ZAhIS+/1GrYtp3KZ4tHzlI3kDuZJHPGdX1mT2Gf4G+aZWg/Gh/rnXIi9mgGdT7fEkANJqkMzScrC+aLNYUcj9L8Noi1YnFtlEVF9294kq1hkhie3LFma3ov1TKHSMnR/z4y4XoImKGg4X8IxPVmsXWkOdcuE5K15oflDiapeUE2yVt0B7E2y9EvF5OdOWkbxiTX7HQ5Ip6rCXX+bw7YKKYfWwwE6YX9QDhy+Op0eFcSwNPg6GcI/oJolOMMs6ir1A+17Z/egh1ea3mrKNxG8RYQ3URBvJtngU+iqN9s3Kz7D2647Z5bon7L8wgTT/Zv4ucpkBTGAvuHjL2/IBWWRn05YCYgBC/PfuI+EKtFXf4uOBIJnSbGHp0ZD5kaFQ7eWMdq9l3iXa9XnM3nIJuldu42Ho9vMsQyKG9tiO1YvjnOj4CPW30mebO5imNQJ2T2IA70krl+MCMr2hutRnCr9mHnAD8G+h93EZ+IbE7N83oGYyhhEnt7wJmqWS2Os+p7Cl+iPqHP5NywJKWXaGOAvM0PpJt6RUSfp5dfLxNfYHr+J4c7/Xi7+mgwZAtQ+v4dFvTewjxjDDNmtmUZHMMvZtokz7d+bRy454bJToNNemFOnPachsekHEyKfGiU6nfwJxnbstL5uujz4iO1xQC0aXOmxZqpXn/LyTBcAaULbg/JHMguMjdT2srA4IOTOJ2FnsKlYq8GHgqNWc8SZzHkwRUXtZBwm3jS0ESfzWvAdidBTt/8SmLRHh2Z3JHwgK+xVwDvblJlU3F8ehcgQI1AqhtSJydb2gNtCpBFr3ozGAWTRb5LgUkeuAVGoCmo+mLYNa/3gAXKtPs/vV2FUI8+bf6FhMtwAypfKCpmPx0nmqKNwgmg15WxF4gqKky8309CQascv97NzRIWb7jqgZ/CUd/cN2u5d0XokJlg/9I0Ti+rBDgiX57jOI9myrqSiXDXE3mBYcrpErQ6B4SjXICqcRa0ADmB+NY2+YjHPDhBqV7xSD2QvBafE4gq+xO8r7FFfXGVFgaaRASJM/bFvd/oy8nxDkFKj71avcYGlKDpofF1zVke/+9F2lLzwfAxDT1z9L1rHqzbOkla531FngAEuPNpR0WZaglfUzwQ+DGEuIPUygAGKgyWsyrjJTWYnslpOXd6Y232OLgX3SW8g2AnjjIPfUReBCuxE97rLe9H/QTZYo3eF1U12YzwtxO+u5vl6BeNV2qenRz01dHse1N+Mur+K2cYUV04wOj91dnnQ==
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: c6b24194-1f40-469b-8fef-08d9b91c5971
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2021 00:56:06.0063 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OD8mWSzMP7VJhJntD+o8AOzybK1GpV1ZfGsA6No0yK4h4EjuU5vi4dt+eUNK2yZEaIJrJ4K/8j12bG4o9zOBcg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3076
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/ZMVFtBjWul3w4h09vxtUQ21yaqs>
Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-00.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: Tue, 07 Dec 2021 00:56:17 -0000

Chuck Lever III wrote:
Hi Rick-
[stuff snipped]
> Let me try an example.
>
> Sending AUTH_SYS_ENC to a server on an unencrypted connection
> is just wrong.
Ok, so now you've completely confused me.
I thought that these pseudo-flavors were meant to be used in the reply
to SECINFO/SECINFO_NONAME (and in the reply to the MNT RPC for NFSv3)
to indicate what the NFS server required.

> The upper layer server (NFS) should not even
> see that request because the client sent a message that is
> insecure and cannot be trusted.
So, how does the RPC layer know that AUTH_SYS_ENC is required,
unless the RPC program server (NFS server for our case) tells it
that that is the case?
--> And as I noted before, I think the NFS server will want to look
      at the RPC request before it decides what it requires.
      (per file system via file handle or NFSv4 state operation not
       associated with a file handle)

> The point of AUTH_TOOWEAK is to forbid clients from sending
> AUTH_SYS_XYZZY requests on unprotected connections. If that
> happens, the server is supposed to bat that request down
> immediately. The transport layer security has to match the
> pseudo-flavor.
Again, what do you mean by "match the pseudo-flavor"?
Or, put another way, how does the RPC layer know what this
pseudo-flavor is supposed to be?

> Nothing more than that is going on.
It seems that you are assuming some pseudo-flavor will apply to all
NFS server access from all clients.
And, as I already stated, I do not think that is going to be the case.

rick


>> In the case of crossing a filesystem boundary, as long as AUTH_SYS_ENC
>> is used and the transport connection is protected, the RPC is accepted.
>> It is then up to the NFSv4 server to authorize that a particular
>> AUTH_SYS_ENC-flavored caller is permitted to access that filesystem.
> Not on the FreeBSD server, at least as implemented now.
>
> I do not have a problem with always using AUTH_ERR/AUTH_TOOWEAK
> to indicate problems with "machine credentials" (or whatever terminology
> fits?) vs NFS4ERR_WRONGSEC for problems with "user credentials".
> However I do have a problem with the assumption that "machine credential"
> requirements are invariant across the RPC protocol.

I'm not talking about machine credentials v. user credentials.

AUTH_SYS_XYZZY carries a traditional AUTH_SYS user and group
credential. It does not make any requirement of the peer
credential that was used to establish the protected channel.

If the FreeBSD server squashes that AUTH_SYS user and group
into something else based on the peer credential, that's
totally independent of whether the client has sent the RPC
Call properly. I don't see how my proposal interferes with
that security policy in any way.

Or, if the FreeBSD server happens to restrict the set of
RPC auth flavors a client may use when sending a SECINFO,
there is a different mechanism for indicating an authorization
failure there. AUTH_TOOWEAK would be returned only if the
client tried to send AUTH_YADA_XYZZY on a channel that did
not match that flavor's transport layer security requirements.


>> In other words, it's perfectly fine for a server to return only
>> AUTH_SYS_ENC in a SECINFO response, and then the client to try to
>> access that filesystem with AUTH_SYS. The server should respond
>> NFS4ERR_WRONGSEC in that case.
> I think the SECINFO reply should indicate whether or not "peer
> authentication" is required, for this client to access this file system.

I think my proposal does exactly that.

Say SECINFO returns "AUTH_SYS AUTH_SYS_ENC AUTH_SYS_MPA_ENC".

That means the client can send requests using AUTH_SYS on any
connection, or using AUTH_SYS_ENC on a connection that uses at
least encryption, or using AUTH_SYS_MPA_ENC on a connection that
has done peer authentication and is using encryption.

But using AUTH_SYS_MPA (as long as the client constructs the RPC
request properly and sends it on a properly protected connection)
will get NFS4ERR_WRONGSEC.

That's a contrived example, but the server clearly indicates
which RPC auth flavors can be used to access that filesystem.


If SECINFO returns a list containing only "AUTH_SYS_MPA_ENC",
then the client must use only AUTH_SYS_MPA_ENC RPC credentials
on a connection that has done peer authentication and is using
encryption. Everything else (as long as it is constructed
correctly and sent on a properly protected connection) will get
NFS4ERR_WRONGSEC.

In this case, the server requires peer authentication and
encryption before it will let a client use AUTH_SYS user and
group credentials to access that filesystem. The client forms
those requests by using the AUTH_SYS_MPA_ENC RPC auth flavor,
an AUTH_SYS credential and verifier, and it sends them on any
channel that is peer authenticated and encrypted.


>> However, if the client sends that AUTH_SYS_ENC request to access that
>> filesystem on a TCP connection with no TLS session, the proper server
>> response is AUTH_TOOWEAK.
>>
>> "You can't access that NFS object" versus "you formed the RPC request
>> incorrectly".
> As you can see, I would have worded this as "You can't access that NFS
> object because you formed the RPC request incorrectly".

That might describe the end result seen by a user, but the
protocols aren't layered that way, so the specification has
to express the distinction just as I did it.


> rick
>
>> rick
>>
>>
>> ________________________________________
>> From: nfsv4 <nfsv4-bounces@ietf.org> on behalf of Chuck Lever III <chuck.lever@oracle.com>
>> Sent: Sunday, December 5, 2021 3:07 PM
>> To: NFSv4
>> Subject: [nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
>>
>> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca
>>
>>
>>> Begin forwarded message:
>>>
>>> From: internet-drafts@ietf.org
>>> Subject: New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
>>> Date: December 5, 2021 at 2:41:27 PM EST
>>> To: "Charles Lever" <chuck.lever@oracle.com>, "Chuck Lever" <chuck.lever@oracle.com>
>>>
>>>
>>> A new version of I-D, draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
>>> has been successfully submitted by Chuck Lever and posted to the
>>> IETF repository.
>>>
>>> Name:         draft-cel-nfsv4-rpc-tls-pseudoflavors
>>> Revision:     00
>>> Title:                Pseudo-flavors for Remote Procedure Calls with Transport Layer Security
>>> Document date:        2021-12-05
>>> Group:                Individual Submission
>>> Pages:                14
>>> URL:            https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-tls-pseudoflavors/
>>> Html:           https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-tls-pseudoflavors-00.html
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpc-tls-pseudoflavors
>>>
>>>
>>> Abstract:
>>> Recent innovations in Remote Procedure Call (RPC) transport layer
>>> security enable broad deployment of encryption and mutual peer
>>> authentication when exchanging RPC messages.  These security
>>> mechanisms can protect peers who continue to use the AUTH_SYS RPC
>>> auth flavor, which is not cryptographically secure, on open networks.
>>> This document introduces several RPC auth pseudo-flavors and other
>>> mechanisms that an RPC service can use to indicate transport layer
>>> security requirements for accessing that service.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>
>> I've submitted this personal draft to provide a fleshed-out version of
>> a proposal I have outlined in the recent past:
>>
>> https://mailarchive.ietf.org/arch/msg/nfsv4/tU1WfkYQUm2AbiZUA3L2uX56uR4/
>> https://mailarchive.ietf.org/arch/msg/nfsv4/7psVqBBY8uhP9L9bMfF7hUbVXK0/
>>
>> among other places.
>>
>> This document provides a similar but contrasting approach to the one
>> described in Sections 13 through 15 of draft-dnoveck-nfsv4-security-03.
>> In addition to covering NFSv4, my document also addresses NFSv2/3 and
>> other RPC services that might wish to employ transport layer security.
>> I'm hoping that comparing and contrasting these two approaches will
>> sharpen our vision and thinking as the WG comes to a rough consensus.
>>
>> Another important reason for a separate document is there seems to be
>> palpable demand for a standards-based NFS in-transit encryption solution.
>> The RPC protocol changes put forth in draft-ietf-nfsv4-rpc-tls are
>> necessary but not sufficient to accomplish this goal. I would like to
>> see a vehicle for moving the remaining components through WG consensus
>> and into the publication queue as quickly as possible. This document
>> might serve as that vehicle.
>>
>> An -00 is, as always, a rough cut. There are likely to be significant
>> gaps in this proposal, which at this point is still quite malleable.
>> Thanks in advance for your time and attention to this work.
>>
>>
>> --
>> Chuck Lever
>>
>>
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>
> --
> Chuck Lever

--
Chuck Lever