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

[Chuck Lever <[e-mail]>]

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 <[e-mail]> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------

...

> (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