Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

Chuck Lever <> Wed, 09 September 2020 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 585A83A0E70; Wed, 9 Sep 2020 07:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lIUEf8C428Dg; Wed, 9 Sep 2020 07:58:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF6B33A0E6E; Wed, 9 Sep 2020 07:58:31 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 089EseZi069730; Wed, 9 Sep 2020 14:58:23 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2020-01-29; bh=zmzfVoEzpfY8iVCEnxaODaN4kdttEMJl7bwusdwBvJU=; b=OC7P5tnvYx50paV9DWcUYpSTaDQJudGG6ttcfW5oNqGWQHNwJLXaKHFKDHvq0nYYUV05 5/GXvsO3RZ1/dBwYTP/o8z/cz0YNWt71M3ART6uOSNATLUcAz1oTvJJdbLhVLrL16MSp v1k8APP7A8jwCUK4gFLoTU3bJJv4EXS/vdJng7bj+Wz5sW3SLZZEG9P6Z2f9OYsW9wME 5pDVx1wTvaOP/fue8DV89rbnKYE1SKc3AhkKJYVTTGjJ//AfS93pW5GZ4u0rqfQ3LMNo E6Ddq+u0lc1HRL3TFcFNeIEqCsvxlNSMjldaRyCAhMt3fH/hSlU7PlIXaga30BZo6Usi pw==
Received: from ( []) by with ESMTP id 33c2mm2amy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 09 Sep 2020 14:58:23 +0000
Received: from pps.filterd ( []) by ( with SMTP id 089EtcgE047185; Wed, 9 Sep 2020 14:58:22 GMT
Received: from ( []) by with ESMTP id 33dackm2hf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 09 Sep 2020 14:58:22 +0000
Received: from ( []) by (8.14.4/8.13.8) with ESMTP id 089EwI1G010282; Wed, 9 Sep 2020 14:58:20 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Sep 2020 07:58:17 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Chuck Lever <>
In-Reply-To: <>
Date: Wed, 09 Sep 2020 10:58:16 -0400
Cc: The IESG <>,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Benjamin Kaduk <>, Trond Myklebust <>, "Mkrtchyan, Tigran" <>, Rick Macklem <>
X-Mailer: Apple Mail (2.3608.
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9739 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 bulkscore=0 phishscore=0 adultscore=0 suspectscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009090135
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9739 signatures=668679
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 priorityscore=1501 phishscore=0 adultscore=0 bulkscore=0 clxscore=1011 mlxlogscore=999 malwarescore=0 suspectscore=0 lowpriorityscore=0 spamscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009090135
Archived-At: <>
Subject: Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Sep 2020 14:58:33 -0000

Hi Ben-

It appears that many of your comments have overlapping impact on
the document, so I'm attempting to address all of them in my
working copy of the document and will post proposals for replacement
text once I feel that they coherently address your concerns.

More below.

> On Jul 8, 2020, at 2:56 AM, Benjamin Kaduk via Datatracker <> wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-nfsv4-rpc-tls-08: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------


> (5) Section 5.2.1 requires that:
>   *  Implementations SHOULD indicate their trusted Certification
>      Authorities (CAs).
> Indicate to whom?
> (6) The usage of RFC 6125 procedures in Section 5.2.1 seems counter to its
> intent.  Specifically, we seem to be saying "the peer gave me a cert, let me
> look through it to see if it has something I like", but RFC 6125's intended
> procedure is "I know a list of names that I expect to see at least one of in
> the cert; these rules tell me whether the cert is valid for any such name".
> It's not entirely clear that it's appropriate for this document to specify
> how the client has to order its list of names by type (per Section 6.1 of
> RFC 6125's "The client constructs a list of acceptable reference
> identifiers"), which the bit about "The following precedence applies" seems
> to be doing.  To the extent that we give a recommendation to use DNS-ID
> instead of CN-ID, and ipAddress SAN instead of CN-ID, that's already covered
> by RFC 6125; it would be okay for us to say "use DNS-ID or iPAddress SAN",
> though.  (Roman's comment about "why not a normative MUST" for putting IP
> addresses in the iPAddress SAN is related, and if we don't have a compelling
> reason to allow the flexibility, we should limit to the specific
> DNS-ID/iPAddress options without allowing CN-ID.)
> (6.1) Note additionally that if wildcard certificates are to be used, RFC
> 6125 requires the application protocol specification to give details on how
> they are to be used.
> (6.2) RFC 6125's procedures are (facially, at least) only valid for TLS
> server authentication.  We also want to authenticate TLS clients, so we
> should say whether we expect the same procedures to be used, or what
> procedures should be used (even just as how it differs from the RFC 6125
> ones).  Of particular note is that, since the server is not initiating the
> network connection, it is unlikely to have a preconceived notion of what
> client identity to expect, and is likely limited to attempting to extract
> something from the certificate.  In this scenario a precedence list (as I
> complained about being inconsistent with RFC 6125 above) would be
> appropriate.

These two DISCUSS points are related to Section 5.2.1, and will
likely have to be dealt with by rewriting that section. The crux
of your commentary seems to be:

--- Clients use different logic for authenticating and authorizing
a TLS session than servers do, and what rpc-tls provides is a jumble.

As you point out, RFC 6125 stipulates that clients authenticate a
server by checking its presented identity against a list of known
identities. I don't see a need for rpc-tls to further decorate the
process laid out in RFC 6125, and I don't know of any issue with
disallowing CN-ID.

rpc-tls still thinks about the server-side authorization process in
terms of the NFS server's legacy IP access control list. Instead we
should think of it like GSS: the RPC layer handles authorization, full
stop, and nothing need be exposed otherwise. The peer's IP address may
be exposed to the upper layer service, but I don't see that rpc-tls
needs to take a position on that; it's an implementation quality issue.

However, rpc-tls does need to provide explicit instructions for servers
to authenticate clients. Thus editorially I think we need to split
Section 5.2.1 into a section that describes server authentication of
clients, and client authentication of servers.

I'm wondering if the PSK section likewise needs bifurcation. But also,
I'm not sure that the PSK identity needs to be surfaced, for similar
reasons: TLS should handle authorization -- either the session was
established by the rules, or it wasn't authorized, and that's all the
upper layer consumer needs to be aware of.

Finally, there's the issue of whether a TLS exporter will be necessary
for properly dealing with GSS channel binding. I haven't looked at that
closely yet, but it might need to be partially addressed in 5.2.1.

I'm interested in my co-author's thoughts, as well as the opinions of
those who have already implemented a RPC-over-TLS prototype.

Chuck Lever