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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 08 Oct 2020 14:56:09 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-nfsv4-rpc-tls-09: 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:
----------------------------------------------------------------------

Thank you for the updates in the -09; they address all my previous Discuss points
(from the -08).  Unfortunately, there is one more issue that was introduced in the
update and will need to be resolved:

While I appreciate the efforts to find appropriate external specifications to
reference, I do not believe that an id-kp-rpcTLSServer certificate
is a Resource Certificate per RFC 6487 -- that specification deals with
the RPKI (Resource PKI) used to authenticate IP address assignment, but
the RPKI is an entirely separate PKI than the Internet PKI ("PKIX").  I
think we should drop that sentence entirely.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also have a few non-discuss-level comments on the -09.

Section 5.1.2

   Sending a TLS Closure Alert terminates a DTLS session.  Because
   neither DTLS nor UDP provide in-order delivery, after session closure
   there can be ambiguity as to whether a datagram should be interpreted
   as DTLS protected or not.  Therefore receivers MUST discard datagrams
   exchanged using the same 5-tuple that just terminated the DTLS
   session for 60 seconds.

The mandatory waiting period before reusing a 5-tuple is a fine
mechanism for resolving the ambiguity.  However, I worry that
prescribing the exact 60-second timeout is over-prescriptive, and it
might be better to say something like "MUST discard [...] for a
sufficient length of time to ensure that retransmissions have ceased and
packets already in the network have been delivered.  In the absence of
more specific data, a period of 60 seconds is expected to suffice."

Section 5.2.1.1

   The current document defines two new KeyPurposeId values: one that
   identifies the RPC-over-TLS peer as an RPC client, and one that
   identifies the RPC-over-TLS peer as an RPC server.  Additional
   KeyPurposeId values related to RPC-over-TLS may be specified in
   subsequent Standards Track documents.

Perhaps I am just forgetting a previous discussion, but I am not sure
why this is apparently limited to Standards-Track documents -- the
normal PKIX convention is that anyone can define whatever EKU they want
and specify the semantics of it.

Section 7.1.2

   Appendix C of [RFC8446] discusses precautions that can mitigate
   exposure during the exchange of connection handshake information and
   TLS certificate material that might enable attackers to track the RPC
   client.

I suggest adding another sentence at the end: "When PSK authentication
is used, the PSK identifier is exposed during the TLS handshake, and can
be used to track the RPC client."  I'm a bit surprised that this fact
was not stated in the referenced appendix, but didn't find it there!

---

From: Chuck Lever <[email-masked]>
Date: Thu, 8 Oct 2020 18:03:15 -0400

Hi Ben-

I've browsed all your replies so far. Haven't seen anything
outlandish. Give me a few days to digest them thoroughly and
come up with appropriate replacement text.

Glad you are on the mend!

> On Oct 8, 2020, at 5:56 PM, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Wed, 14 Oct 2020 11:50:25 -0400

Hi Ben-

I've attempted to address this official position and the other recent
follow-up comments made last Thursday. You can compare these updates
against rpc-tls-09 here:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-nfsv4-rpc-tls.txt&url2=https://chucklever.github.io/i-d-rpc-tls/draft-ietf-nfsv4-rpc-tls.txt

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 14 Oct 2020 20:33:34 -0700

Hi Chuck,

> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-nfsv4-rpc-tls.txt&url2=https://chucklever.github.io/i-d-rpc-tls/draft-ietf-nfsv4-rpc-tls.txt

Thanks for the link/updates.  The discuss point is definitely resolved :)

I would like to iterate on a couple other things, though.

======================================================================

The update in the introduction about the host/user identity management
seems to have dramatically changed the sentiment being conveyed.

For reference, this is

OLD (I-D -09):
   *  GSS host identity management and user identity management must be
      enforced in the same security realm.  In certain environments,
      different authorities might be responsible for provisioning client
      systems versus provisioning new users.

NEW:
   *  Host identity management and user identity management become
      overly complex in environments with a mixture of security
      mechanisms and realms.  Cloud providers, for instance, might
      prefer to use GSS for authenticating hosts but allow tenants to
      use AUTH_SYS to manage user identities within their private
      networks.

To try to recap my understanding of things:
- GSS for hosts + users works okay when both are in the same realm, but you
  are still stuck keying hosts individually which requires some effort to
  scale nicely. [0]
- GSS for hosts + users can kinda be done when they are in different realms
  but it's pretty messy (and you still have the "keyed hosts" scaling
  problems)
- [Some environments require that users and hosts are in separate realms,
  as the OLD text notes]

The NEW text implies that the complexity comes in with a mixture of
security mechanisms and mixture of realms, but in order to make our case
effectively it seems like we want to talk about just the case where there
is a mixture of realms (adding a mix of security mechanisms is orthogonal
to our point).  Indeed, a mixture of security mechanisms is perhaps arguing
in the wrong direction, since we are proposing to add more mechanisms to
the mix; more concretely, though, prior to rpc-tls the choices are AUTH_SYS
or AUTH_GSS, and we are saying that AUTH_SYS is used because AUTH_GSS is
too hard.  Saying that mixing AUTH_GSS and AUTH_SYS is complicated doesn't
promote the claim that AUTH_GSS is hard.

I'm also not entirely sure what protocol mechanisms are supposed to map up
to the cloud provider case descried in the NEW text -- how do you actually
use GSS for host authentication but AUTH_SYS for users?  I thought you only
had a single mechanism per RPC connection/association.

======================================================================

The new text in Section 5.1.2 seems to have some editing leftovers (most
notably, a full stop after the dtls13 reference).

I'm also curious about the addition of "RPC-over-DTLS support for that RPC
program on that port" -- why do we need to scope the discovery to a single
RPC program on that port for the UDP/DTLS case, when the TCP/TLS case just
says "RPC-over-TLS support for that connection"?

======================================================================

The other stuff looks good to me.

Thanks again,

Ben

[0] IIUC Stanford has a nice system that integrates with the
host-management DB and lets you, the user that "owns" a host, authenticate
to a service as yourself and get credentials for that host.  But that's not
in any standard distribution, and the integration with the host-management
DB is custom work anyways.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 15 Oct 2020 10:00:00 -0400

> On Oct 14, 2020, at 11:33 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Chuck,
> 

Thanks! Once we get through the remaining iterations I will submit
a fresh revision.

> I would like to iterate on a couple other things, though.

I was trying to address your specific concern about "must be enforced"
but seem to have made matters worse. Try this instead:

  *  GSS host identity management and user identity management must be
     enforced in the same security realm. However, cloud providers, for
     instance, might prefer to remain authoritative for host identity
     but allow tenants to manage user identities within their private
     networks.

The split cloud/tenant usage scenario described above is one of the
initial drivers for using transport-layer security, so I'd like to
find some way to include it in the Introduction.

RPC-over-(D)TLS discover must be done for each RPC program. That's true
for TCP or UDP. You can't mix cleartext and TLS-protected traffic on
a TCP connection with an established TLS session. However, with UDP,
there is no connection that encases the DTLS session, and that allows
mixture of cleartext and DTLS-protected datagrams to the same 

I'm open to suggestions (and editorial correction, of course).

That sounds similar to Windows Active Directory deployments.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Fri, 30 Oct 2020 10:49:43 -0400

Hi Ben-

See below.

> On Oct 15, 2020, at 10:00 AM, Chuck Lever <[email-masked]> wrote:
> 
> 
> 

There is a desire to close your DISCUSS with a fresh revision before
the draft submission window closes for 109 on Sunday. Do you have any
further comments on my proposed replacement text?

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 30 Oct 2020 13:46:16 -0700

Hi Chuck,

Sorry that I missed this when it first came in (and thanks for the separate
reminder).

> find some way to include it in the Introduction.

This text about the split cloud/tenant scenario looks good, but we are back
to the "must be enforced" topic.  Perhaps just "typically must be enforced"
or some similar hedging is the right approach, since the prerequisite
Kerberos topology for doing it any other way is rather atypical.

> I'm open to suggestions (and editorial correction, of course).

Probably what I'm missing is how the TLS/TCP connection is bound to the
specific RPC program.  (I assume that it's just part of how RPC-over-TCP
works and I've forgotten that detail.)  Proceeding on that assumption, that
might suggest an editorial change to §5.1.1 to keep the TLS and DTLS
descriptions more parallel, perhaps "[...] it uses the mechanism described
in Section 4.1 to discover RPC-over-TLS support for the RPC program on that
connection."

-Ben

---

From: David Noveck <[email-masked]>
Date: Sat, 31 Oct 2020 04:10:39 -0400

How about "would need to be enforced" instead of "typically must be
enforced" ??

---

From: Chuck Lever <[email-masked]>
Date: Sat, 31 Oct 2020 12:22:59 -0400

Sorry for the delay. Our corporate e-mail system did not show your
reply until this morning.

> On Oct 30, 2020, at 4:46 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Chuck,
> 

I'm not actually aware of any way to get Kerberos to do this, which
is why I used "must be enforced". But perhaps I am jaded by the
particular RPCSEC GSS implementations I'm familiar with, and did not
imagine that the protocols themselves might allow it.

Anyway, I've added "typically" as you suggested, just to close this
out for the next revision.

> in Section 4.1 to discover RPC-over-TLS support for the RPC program on that

... which is a totally true and correct statement. So let's go with that.

--
Chuck Lever