Re: [nfsv4] questions w.r.t RPC-over-TLS draft

Rick Macklem <rmacklem@uoguelph.ca> Mon, 20 January 2020 23:08 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 7158512011D for <nfsv4@ietfa.amsl.com>; Mon, 20 Jan 2020 15:08:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 0dXt1ESSwIbY for <nfsv4@ietfa.amsl.com>; Mon, 20 Jan 2020 15:08:18 -0800 (PST)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670072.outbound.protection.outlook.com [40.107.67.72]) (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 28DE3120045 for <nfsv4@ietf.org>; Mon, 20 Jan 2020 15:08:17 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TcO6dcZxPHg3MAlSA8Z/uFDcFaLQk38VGLJ4qixk8HHyyuHwTIFIont+xyCpUMXd2429TB3AZJd0pvRu5f9u2qKKcIt3AXrv+TEJxn4JWSiBBerMLFpSnyNtKhCtgYoCOwARV+l/ZQ3xs6L2vDvTCBw3fB2EP+c4d7kCizaFnwYoFuP+hWt/nJuyzhKZ39cjQVMB7+5m7tFwhSGOYA70jiT/L0zhPFGf9eZvTQJfNYJPYHzNlHHHFT6R+P+8fTJdqwKO6XgieMKR0aJ0His3L7ttszNxNDAbnspU2R9rHzqrJ4kFSJx5p8OAsyltOcKfoU0wbjbwRtkBU0cZduvJ3w==
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-SenderADCheck; bh=VQOZZIscFgl5CEk5fWAqO1ZXV//qP+l9wvEsirKVSEQ=; b=ZtkRvIrvAr+YMusI2T1mT6vGSTZ7QmHAksfQ1Zx6pYXq3Hyfxg46Uqalp7Vl9DWErbrk1qDIBJiHAXUh1qbIGvylBOEuaJLyjTgiP3Z05BFd7g80XZWjCHgpixxxXdDayFpdMCZEIG/fSrDnJ6rJmuJdKutumuH/VhrfrEaM5kT0+AVAg+0d+BhaKNCM0xBU6UBbvblAi3zSqbiYW5pNEw3drx3c5rM99XVxouWoQTIrgdsWqbqbP72FryYcvhYmprmztOBYCGDIgPWJk9kQNmi0GiTFboJMC1uO4/ZDZnrObWBTpKaf6+mldUd2+NWRUtZsZSo3VXIsf7lpmr/Lbw==
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
Received: from YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM (52.132.69.153) by YQBPR0101MB2147.CANPRD01.PROD.OUTLOOK.COM (52.132.65.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Mon, 20 Jan 2020 23:08:16 +0000
Received: from YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM ([fe80::7512:8580:8d82:6c94]) by YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM ([fe80::7512:8580:8d82:6c94%6]) with mapi id 15.20.2644.026; Mon, 20 Jan 2020 23:08:16 +0000
From: Rick Macklem <rmacklem@uoguelph.ca>
To: Chuck Lever <chuck.lever@oracle.com>
CC: "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: [nfsv4] questions w.r.t RPC-over-TLS draft
Thread-Index: AQHVzye+eTXe64dubES650eWV4dxj6fzqLCAgAB8+P8=
Date: Mon, 20 Jan 2020 23:08:16 +0000
Message-ID: <YQBPR0101MB1427364BAFED4564FD0FD67BDD320@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM>
References: <YQBPR0101MB142761C64D6A842CB99EADC0DD320@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM>, <0E8060A0-B8DA-462E-915E-9121824A7A3D@oracle.com>
In-Reply-To: <0E8060A0-B8DA-462E-915E-9121824A7A3D@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5d1cd5be-6a37-4754-9e31-08d79dfda1e4
x-ms-traffictypediagnostic: YQBPR0101MB2147:
x-microsoft-antispam-prvs: <YQBPR0101MB2147D88FA5A2B6946B49FBACDD320@YQBPR0101MB2147.CANPRD01.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0288CD37D9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(346002)(376002)(39860400002)(199004)(189003)(2906002)(7696005)(786003)(316002)(4326008)(91956017)(55016002)(76116006)(66946007)(64756008)(478600001)(66556008)(66476007)(5660300002)(8936002)(9686003)(6916009)(8676002)(52536014)(26005)(81166006)(33656002)(186003)(6506007)(53546011)(71200400001)(81156014)(86362001)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR0101MB2147; H:YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ayalzAzj8VIy0RcRIzT/KMljWgd0jV+qzMcJLCO9fUC3rxhMK+kSQHRUW/cNjUpil69nKoRjnLNgg0hgi1iWuMMvYBGSB5XhlF1n5GfHwiM4/wO9KPsZY1eHxlu8FnzHhyzOoBflSRemR4EojphgQd841rVRrWMBuTyKPEXtWn0zqVl2Kc3YJTBMlx6Pvy5zlIa7hVtZ3S1Mz7FUUdWerAn4vw+d/fP/o/F94kuApv+A47UJlGyTMNs/fyQCMXf+HoPJ4ABO2bTaGScYmg5eUACJIR2KTaVRaI7x2ZboU1ww1rsiey478Vf53hZ8f+Eh6QMm38HiUwzvFI4eWynEjYdlVpDKo1rK4B6uVSEPGl13X4j0uvp2eg9Wq/A0dNECaQSsptP6dlzI95uNllaztPAkmPL9ER9NRi38QQUrx7j4p9Iee7xbF0nrNo7s/ZS6
x-ms-exchange-transport-forked: True
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-Network-Message-Id: 5d1cd5be-6a37-4754-9e31-08d79dfda1e4
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2020 23:08:16.3666 (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: VpBk1Xd3jGyAMgH/utsTPM+K3d/SHOEbW7fr+jdWSm9dMSbSIsryci4/tJ+UGi4UbvKCJdSAWECOY0cN+4us4g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB2147
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/oVlzdDWBOB8LiSa9C0jYlxfcUWU>
Subject: Re: [nfsv4] questions w.r.t RPC-over-TLS draft
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, 20 Jan 2020 23:08:21 -0000

Chuck Lever wrote:
>May I add the FreeBSD implementation of RPC/TLS to Section 6? Did I
>already ask you this and simply forgot to add it?
Definitely a "work in progress" at this time, so you can decide if it should be
mentioned. (I am making pretty good progress, but the FreeBSD kernel TLS
only works for send at this time, unless you have hardware that does TOE.
It may be a few months before the kernel TLS can do receive, so that it
actually works.)

>> On Jan 19, 2020, at 7:30 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote:
>>
>> Hi,
>>
>> I've started implementing RPC-over-TLS for NFS and have run into a couple
>> of questions related to the draft (#4, I haven't downloaded #5).
>>
>> 1 - Given this description...
>>   The flavor value of the verifier received in the reply message from
>>   the server MUST be AUTH_NONE.  The bytes of the verifier's string
>>   encode the fixed ASCII characters "STARTTLS".
>>
>> Is the verifier coded as:
>> A:   verifier length: 8
>>      bytes STARTTLS
>> OR
>> B:   verifier length: 12
>>      string length: 8
>>      bytes STARTTLS
>>
>> ie. Is there supposed to be a string length as coded by xdr_string() in the
>> verifier? (It is the words "verifier string" the above that I find confusing.)
>
>I agree, "string" is confusing. It should rather say "fixed-length
>opaque".
This might still hint at an extra length field.
How about something like "The body of the verifier consists of the 8 ASCII bytes STARTTLS"?
(Btw, this is how I had coded it and then, when I read "verifier string" I wasn't sure.)

>Section 7.2 of RFC 1831 has this:
>
>enum auth_flavor {
>      AUTH_NONE = 0,
>      AUTH_SYS = 1,
>     AUTH_SHORT = 2
>      /* and more to be defined */
>
>};
>
>struct opaque_auth {
>      auth_flavor flavor;
>      opaque body<400>;
>
>};
>
>The flavor field contains AUTH_NONE (0), the opaque's length field
>contains 8, and the opaque's data contains the ASCII characters
>"STARTTLS".
>
>
>> Then there is this sentence...
>>   AUTH_ERROR.  If the client sends a STARTTLS after it has sent other
>>   non-encrypted RPC traffic or after a TLS session has already been
>>   negotiated, the server MUST silently discard it.
>>
>> Does "other non-encrypted RPC traffic" refer specifically to traffic between
>> the NULL RPC with AUTH_TLS and the STARTTLS or does it refer to non-NULL RPC traffic >or??
>
>The client can't start a TLS session on a connection after it
>has sent non-NULL RPC traffic.
Cool. Maybe it needs to say that the NULL RPC with authentication flavor of AUTH_TLS
constitutes a STARTTLS operation.

That still doesn't really clarify if a NULL RPC with authentication flavor of AUTH_NULL
is also allowed before the NULL RPC with authentication flavor of AUTH_TLS.
(FreeBSD currently uses NULL RPCs with AUTH_NULL as a "ping" to figure out if
 the server is up, however it uses a separate TCP connection to do this, so it shouldn't
 matter if it allowed on the same connection.)

>> I am also confused about what "sends a STARTTLS" actually means?
>> (I'll admit I know nothing about TLS and can only find STARTTLS mentioned w.r.t.
>> an SMTP email command.)
>>
>> Does this mean that the 8 bytes STARTTLS goes on the wire immediately after
>> a NULL RPC with AUTH_TLS or does it mean the 8 bytes STARTTLS goes in a
>> TCP RPC message (an 8byte message as indicated by the RPC over TCP record
>> mark, which would normally be too small) or does "sends a STARTTLS" just saying
>> that the TLS handshake should come immediately after the NULL RPC with AUTH_TLS?
>
>
>"sends a STARTTLS" means "initiates a TLS session."
That clarifies it. It might be even clearer if it said "initiates a TLS handshake"?
Alternately, defining the NULL RPC with authentication flavor AUTH_TLS as a STARTTLS
command would do so as well.

One slight problem here is that the above would seem to be TCP specific, since it assumes
ordering, but is not in the TCP section. I know nothing about the UDP case and have no intention of implementing it, but it does seem that 
>>   AUTH_ERROR.  If the client sends a STARTTLS after it has sent other
>>   non-encrypted RPC traffic or after a TLS session has already been
>>   negotiated, the server MUST silently discard it.
is TCP specific? (Would the UDP variant be non-NULL RPC traffic from the same client
IP address or do you just not worry about this for UDP?)

Thanks for the help with this, rick

--
Chuck Lever