Towards Remote Procedure Call Encryption by Default
draft-ietf-nfsv4-rpc-tls-11

[Ballot comment]
Thank you for all the updates in response to my earlier reviews.

One final note (no response necessary):

Section 1

The -10 has "must typically" where I (thought I) suggested "typically must".
If that's intentional, that's fine; I just wasn't 100% sure at first look.

[Ballot comment]
Thanks for addressing my DISCUSS about Early Data.

previous comment:

Thank you for this draft. I fully support bringing TLS into more use cases of this type.

Some comments:
Sec 1.
"Moreover, the use of AUTH_SYS remains common despite the adverse effects that acceptance of UIDs and GIDs from unauthenticated clients brings with it. Continued use is in part because:

Per-client deployment and administrative costs are not scalable. Administrators must provide keying material for each RPC client, including transient clients.
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."

The text above says that something is still in use because..., and then mentions two things that are bad. I think the two items are supposed to refer to GSS?

Sec 4.2 This sure looks like normative text, so s/must not/MUST NOT "... utilize the remote TLS peer identity for RPC user authentication"

Sec 5.1.2 Similarly, s/should/SHOULD "...employ ConnectionIDs of at least 4 bytes in length."

[Ballot 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.

[Ballot 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!

[Ballot comment]
Thank you for addressing the early SECDIR review items (and thank you Derrell Piper and Alan Alan DeKok for doing them)

Thank you for addressing by DISCUSS and COMMENT items.

[Ballot discuss]
I support Roman's Discuss points.

Sorry to provide so many new substantive points here -- I was only able to
follow the email discussions in the WG (and not completely, even) but not to
actually read the document earlier.  It hopefully goes without saying, but
the goal is to make sure we get it right, since it's going to be an important
pillar for the future of things; I'm happy to see that this is advancing.

(1) I don't think that the claim in Section 4.2 that "[b]oth RPC and TLS have
peer and user authentication" is correct, at least given my understanding of
those terms.  Using this document's definition of RPC "peer authentication"
as analogous to TLS server authentication, the functionality that TLS calls
"mutual authentication" is more analogous to RPC client authentication,
though it is sometimes repurposed for use for user authentication, with
concommittant bad user experience.  This analogy does not seem critical to
the mechanisms of this document, so I believe we should remove or modify it.

(2) The mention of using RPCSEC_GSS with GSS channel bindings to TLS is
quite underspecified.  Unfortunately, this is largely the fault of other
specifications, but we have to deal with the fallout.  On first glance (but
subject to further clarification/change), it seems like we should:

- Say what channel binding type (from the registry that RFC 5929 registered
  stuff in) is to be used -- just citing 5929 doesn't help, since it
  mentions three different ones (none of which are really right for TLS 1.3,
  see below)

- provide a mechanism for the peers to determine whether GSS channel binding
  to TLS is to be used.  (As discussed in
  draft-ietf-kitten-channel-bound-flag, the current state of things GSS is
  that if one party supplies channel bindings but the other doesn't, the
  security context negotiation fails, which is usually not the best for
  usability.)  Since this is a greenfield GSS-API application, the simplest
  thing by far is to just say "always provide the channel bindings when
  using RPCSEC_GSS over TLS".  It's even the more secure option, too :)

- give more detail about what value to provide as the 'chan_binding' input
  to the GSS security context negotiation.  We currently reference RFC 5929,
  that defines three different channel-binding values, but none of them are
  really usable for TLS 1.3 (as discussed in
  draft-ietf-kitten-tls-channel-bindings-for-tls13).  Most likely this will
  mean using the tls-exporter value from that document.

(3) Please check this reference in Section 5.1.1:

  Reverse-direction operation occurs only on connected transports such
  as TCP (see Section 2 of [RFC8166]).  [...]

It seems likely that RFC 8167 was intended...

(4) I don't think it's particularly safe to suggest that non-protected RPCs
should be exchanged on the same 5-tuple that just terminated a DTLS
association, since neither DTLS nor UDP provide in-order delivery, so there
is ambiguity as to whether a datagram should be interpreted as DTLS
protected or not.  This is particularly problematic in the face of the three
different DTLS record headers (DTLSPlaintext, DTLSCiphertext(full), and
DTLSCiphertext(minimal)) with something like 10 or 11 different possible
values for the first byte that might be in flight, with limited "magic
number" verification fields available.  I think I need some input from the
TSV ADs about what the options are, though -- while a cooling-off period
might be fine if an ephemeral port is in use, it seems problematic for cases
where fixed port numbers are used for both source and destination.

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

(7) Section 5.2.1 uses the phrase "renegotiate the TLS session".
Renegotiation is not defined or allowed for TLS 1.3; generally one would
need to either remember the presented certificate and re-run the validation
process on it or shutdown the TLS connection and make a new one, though in
theory one could try to define a mechanism using post-handshake
authentication.  (I don't recommend the latter, though; it's not widely
implemented/used.)

(8) Can we clarify the status of DNSSEC (or DANE) requirements?  Section 1
assumes that support for DNSSEC is already available in an RPC
implementation, but Section 7.1.1 says that "Clients [sic] implementors can
choose from" a list of things including DANE TLSA records.  Why would we
require DNSSEC support but not using the records if they're present?

(9) I agree with Roman('s comment) that Sections 5.2.2 and 5.2.4 should give
a minimum amount of information to be exposed to the administrator for
implementing the trust mode.

[Ballot comment]
I'm surprised that we don't make a normative reference to BCP 195's
"Recommendations for Secure Use of Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS)" (we have only an informative
reference from the security considerations).

Abstract

I can't quite put my finger on it, but something about "enables encryption
of in-transit Remote Procedure Call (RPC) transactions" rubs me the wrong
way.  I think I want to change what the "in transit" binds to, since what we
are doing is encrypting RPC messages while they are in transit, as opposed
to applying protection to just the subset of messages that are "in transit".

Section 1

                                                                    It
  strongly recommended that newly defined Internet protocols should
  make a genuine effort to mitigate monitoring attacks.  Typically this
  mitigation is done by encrypting data in transit.

I suggest s/is done by/includes/, since in some cases padding or other
side-channel-resistance mechanisms are also used.

  *  Parts of each RPC header remain in clear-text, constituting a
      significant security exposure.

"Security" is kind of a catch-all term; it would be good to be more precise,
here, perhaps as "constituting a needless loss of metadata confidentiality".

  Moreover, the use of AUTH_SYS remains common despite the adverse
  effects that acceptance of UIDs and GIDs from unauthenticated clients
  brings with it.  Continued use is in part because:

  *  Per-client deployment and administrative costs are not scalable.

This writing could be tidied up; it currently can be read as saying that the
deployment/administrative costs are of AUTH_SYS, but really the costs belong
to the only currently defined alternative to AUTH_SYS.  Perhaps, "Per-client
deployment and administrative costs for the only defined alternative to
AUTH_SYS are expensive at scale".

  *  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.

I think this is only true from a certain point of view.  They have to be
related, and (assuming Kerberos since non-Kerberos RPCSEC_GSS isn't really a
thing) a cross-realm relationship would have to exist in at least one
direction when client system and user provisioning are managed by separate
kerberos realms, but the authorities in question do not need to be exactly
the same.

  The alternative described in the current document is to employ a
  transport layer security mechanism that can protect the
  confidentiality of each RPC connection transparently to RPC and
  upper-layer protocols.  The Transport Layer Security protocol

side note: I'd consider an editorial rewording to something like:

% In light of the difficulties and issues with both the mechanisms currently
% defined for RPC protection and/or authentication, and the continued
% inability to make significant progress in mitigating those concerns, this
% document takes a new approach by defining a third mechanism to complement
% the existing ones.  The confidentiality of each RPC connection can be
% protected transparently to the RPC and upper-layer protocols by use of a
% transport-layer security mechanism.  The Transport Layer Security protocol

  Encryption By Default:  Transport encryption can be enabled without
      additional administrative tasks such as identifying client systems
      to a trust authority, generating additional keying material, or
      provisioning a secure network tunnel.

To clarify Roman's comment, it seems worth specifying that this is without
additional *per-client* keying material.  Generating per-server keying
material is clearly a minimum requirement.

  The current document specifies the implementation of RPC on an
  encrypted transport in a manner that is transparent to upper-layer
  protocols based on RPC.  The imposition of encryption at the
  transport layer protects any upper-layer protocol that employs RPC,
  without alteration of that protocol.

nit: this paragraph, especially the first sentence, feels pretty redundant
with the paragraph that I proposed a rewording of.

  that do not support TLS.  However, specifications for RPC-based
  upper-layer protocols should choose to require even stricter policies
  that guarantee encryption and host authentication is used for all RPC
  transactions.  [...]

We could probably cite 7258 again to strengthen this argument.  I though
7435 (opportunistic security) also had some applicable text, but am not
finding it right now.

  The protocol specification in the current document assumes that
  support for RPC, TLS, PKI, GSS-API, and DNSSEC is already available
  in an RPC implementation where TLS support is to be added.

We assume that TLS is available where TLS support is to be added?  That
might merit a bit more explanation.

Also, what exactly does "PKI" mean, here?  PKIX X.509 certificates?

Section 4.1

  The mechanism described in the current document interoperates fully
  with RPC implementations that do not support RPC-over-TLS.  Policy
  settings on the RPC-over-TLS-enabled peer determine whether RPC

I'd consider joining the two sentences via ", subject to policy settings on
the RPC-over-TLS-enabled peer that determine".

  The RPC client might query the RPC server's rpcbind service to make
  this selection.  In all cases, an RPC server MUST listen on the same

Is there a reference we could put in for the rpcbind service?

  containing a NULL RPC procedure with an auth_flavor of AUTH_TLS.  The
  mechanism described in the current document does not support RPC
  transports other than TCP and UDP.

It might be nice if we could find a way to mention this transport
restriction in the previous paragraph, though it's hardly vital.

  The flavor value of the verifier in the RPC Reply message received
  from the server MUST be AUTH_NONE.  The length of the verifier's body
  field is eight.  The bytes of the verifier's body field encode the
  ASCII characters "STARTTLS" as a fixed-length opaque.

nit/style: I kind of want there to be mention of "to accept" starttls or
"a server supporting this mechanism" or something in this paragraph, since
of course a client that sent the proper probe message will not get this
response from a server that doesn't implement it.

  If an RPC client uses the AUTH_TLS authentication flavor on any
  procedure other than the NULL procedure, or an RPC client sends an
  RPC AUTH_TLS probe within an existing (D)TLS session, the RPC server
  MUST reject that RPC Call by setting the reply_stat field to
  MSG_DENIED, the reject_stat field to AUTH_ERROR, and the auth_stat
  field to AUTH_BADCRED.

nit: is the protocol element a 'reply_stat' field or a 'stat' field of type
'reply_stat'?  Likewise for reject_stat and auth_stat.

  Once the TLS session handshake is complete, the RPC client and server
  have established a secure channel for communicating.  A successful
  AUTH_TLS probe on one particular port/transport tuple never implies
  RPC-over-TLS is available on that same server using a different port/
  transport tuple.

It could be worth saying something about expected future availability of
RPC-over-TLS on the same server/port/transport (though it is, of course, not
guaranteed).  RFC 7435 admits this possibility when it discusses that peer
capabilities may be obtained by out-of-band mechanisms such as
trust-on-first-use (TOFU).

Section 4.2

  Each RPC server that supports RPC-over-TLS MUST possess a unique
  global identity (e.g., a certificate that is signed by a well-known
  trust anchor).  Such an RPC server MUST request a TLS peer identity

This is perhaps sufficiently vague to not be actively problematic, but at
least comes close to a touchy area.  The main source of "well-known trust
anchor" that many readers will think of is the Web PKI, but use of TLS
certificates issued from the Web PKI for authenticating RPC operation enters
a grey area in terms of CA policy; if the CA determines that the certificate
is being used for a purpose other than the one it was issued for, the
certificate is subject to revocation by the CA.  A hypothetical
mass-revocation event due to publicity about wide-scale "misuse" of TLS
certificate for RPC (i.e., not HTTP) would have knock-on effects on other
consumers of those CAs via expanded CRL size and the resources needed to
perform revocation checks.  Things would be easier in this regard if a
dedicated "well-known" CA infrastructure appeared for RPC usage, though many
things would have to align for that to happen (which would themselves not be
"easy"!), and there are of course options involving site-local CAs where the
combination of issuer and subject serves to satisfy the "unique global
identity" criterion.

  from each client upon first contact.  There are two different modes

nit: "contact" is perhaps needlessly ambiguous (i.e., w.r.t. TLS handshake
vs. NULL RPC probe); perhaps "during the TLS handshake" suffices?

      identities.  If authentication of either peer fails, or if
      authorization based on those identities blocks access to the
      server, the peers MUST reject the association.

nit: there's something like a singular/plural mismatch, in that only
authorization based on the client identity would "block access to the
server", but we talk about "authorization based on those identities" plural.
I guess in some sense the client could reject a server as unauthorized, but
given how the server identity check happens usually the client would make
that rejection before it even does a DNS resolution and starts the TLS
handshake, with the in-handshake checks being limited to authenticating that
the server is the one the client was trying to talk to.

  In either of these modes, RPC user authentication is not affected by
  the use of transport layer security.  When a client presents a TLS
  peer identity to an RPC server, the protocol extension described in
  the current document provides no way for the server to know whether
  that identity represents one RPC user on that client, or is shared
  amongst many RPC users.  Therefore, a server implementation must not

That's only true to the extent that we haven't yet defined X.509 mechanisms
to convey that information.  It's certainly imaginable that we would define
new name types or key usage that are specific to RPC client or RPC user
authentication, though I don't know of any such mechanism that already
exists today.

Section 4.2.1

  RPCSEC GSS can also perform per-request integrity or confidentiality
  protection.  When operating over a TLS session, these GSS services
  become redundant.  An RPC implementation capable of concurrently

At risk of being called a pedant, these services are only "largely
redundant" -- most TLS setups will be using standard asymmetric key exchange
that is vulnerable to a quantum computer, whereas a kerberos-backed
RPCSEC_GSS will be using symmetric crypto that is or can be
quantum-resistant for appropriate key sizes.  When a "record now, decrypt
later" attack is relevant the distinction can be important to make (though
for purely ephemeral traffic the distinction collapses).

Section 5

  *  Negotiation of a ciphersuite providing confidentiality as well as
      integrity protection is REQUIRED.  Support for and negotiation of
      compression is OPTIONAL.

There's a bit of tidying we can do that falls out from the "1.3 only" change
-- all TLS 1.3 ciphersuites provide confidentiality (by virtue of needing to
be AEAD ciphers), and compression is forbidden in TLS 1.3.

  *  Implementations MUST support certificate-based mutual
      authentication.  Support for TLS-PSK mutual authentication
      [RFC4279] is OPTIONAL.  See Section 4.2 for further details.

(Roman's Discuss is valid, but also) people using TLS-PSK (with TLS 1.3)
might be interested in the topics discussed in
draft-ietf-tls-external-psk-guidance and
draft-ietf-tls-external-psk-importer.  I don't insist on referencing them,
but it might be worth considering.

  Client implementations MUST include the
  "application_layer_protocol_negotiation(16)" extension [RFC7301] in
  their "ClientHello" message and MUST include the protocol identifier
  defined in Section 8.2 in that message's ProtocolNameList value.

  Similary, in response to the "ClientHello" message, server
  implementations MUST include the
  "application_layer_protocol_negotiation(16)" extension [RFC7301] in
  their "ServerHello" message and MUST include only the protocol
  identifier defined in Section 8.2 in that message's ProtocolNameList
  value.

[this would change if we end up using ALPN to indicate whether GSS channel
binding is used]

  If the server responds incorrectly (for instance, if the
  "ServerHello" message does not conform to the above requirements),
  the client MUST NOT establish a TLS session for use with RPC on this
  connection.  See [RFC7301] for further details about how to form
  these messages properly.

We could probably give a bit more detail about what happens here.
Specifically, once you abort the TLS handshake, most implementations don't
give you a guaranteed clean way to get back to a non-TLS socket, so you
generally end up tearing the whole thing down.  If we expect people to be
able to say "well, STARTTLS failed, let me just reuse this connection for
unencrypted RPC", we should be clear about that.

Section 5.1.1

                                                                      If
  spurious traffic appears on a TCP connection between the initial
  clear-text AUTH_TLS probe and the TLS session handshake, receivers
  MUST discard that data without response and then SHOULD drop the
  connection.

Is this "spurious traffic" supposed to be just in one direction or in both?
IIUC at least one of those cases would probably be malformed RPC (and thus
discarded anyway?).

  The protocol convention specified in the current document assumes
  there can be no more than one concurrent TLS session per TCP
  connection.  This is true of current generations of TLS, but might be
  different in a future version of TLS.

I'd be pretty surprised if a future version of TLS grew this feature; I've
asked the TLS WG if we think there's not need to include such a statement in
this document.

                                        To protect reverse-direction
  RPC operations, the RPC server does not establish a separate TLS
  session on the TCP connection, but instead uses the existing TLS
  session on that connection to protect these operations.

My apologies for zoning out during the WG discussions, but we're sure that
the RPC framing is enough to let this work (with forward and
reverse-direction RPCs intermingled on the same TLS connection)?

Section 5.1.2

  Using DTLS does not introduce reliable or in-order semantics to RPC
  on UDP.  Each RPC message MUST fit in a single DTLS record.  DTLS
  encapsulation has overhead, which reduces the effective Path MTU
  (PMTU) and thus the maximum RPC payload size.  The use of DTLS record

"Packetization Layer Path MTU" (PLPMTU, draft-ietf-tsvwg-datagram-plpmtud,
in the RFC Editor's queue) might be a better term to use.

  As soon as a client initializes a UDP socket for use with an RPC
  server, it uses the mechanism described in Section 4.1 to discover
  DTLS support for an RPC program on a particular port.  It then
  negotiates a DTLS session.

We could probably normalize the wording between the TCP and UDP cases (e.g.,
TCP says "typically, once a client completes the TCP handshake, it uses the
mechanism [...]" but this uses descriptive text).  That would also let us
decide whether or not to mention that (D)TLS usage is contingent on mutual
support for STARTTLS.

  extension described in Section 9 of [I-D.ietf-tls-dtls13], and RPC-
  on-DTLS peer endpoints MUST provide a ConnectionID with a non-zero

nit: we seem to prefer RPC-over- to RPC-on (as is used here, across the line
break)

Section 5.1.3

  Transports that provide intrinsic TLS-level security (e.g., QUIC)
  need to be addressed separately from the current document.  In such
  cases, the use of TLS is not opportunistic as it can be for TCP or
  UDP.

nit(?): somehow "can be" doesn't feel like the right wording here, but "must
be" isn't right either...

  scope of the current document.  Because there might not be other
  provisions to exchange client and server certificates, authentication

Er, "other provisions" than what?

Section 5.2.1

  X.509 certificates are specified in [X.509] and extended in
  [RFC5280].

Note that RFC 5280 claims to be a profile of X.509, not an extension to it.

  *  Certificate validation MUST include the verification rules as per
      [RFC5280].

It might be appropriate to reference RFC 6125 as well (though that places
some restrictions on how servers are named, claims to only apply to server
certificate validation, and requires specifying what type of name is to be
validated and how the input name to validation is obtained)

  *  Peer validation always includes a check on whether the locally
      configured expected DNS name or IP address of the server that is
      contacted matches its presented certificate.  DNS names and IP

In the RFC 6125 parlance these would be the "DNS-ID" and "iPAddress
subjectAltName", respectively, and such a reference would obviate the need
for most of the subsequent explanation.

  *  Implementations MAY allow the configuration of a set of additional
      properties of the certificate to check for a peer's authorization
      to communicate (e.g., a set of allowed values in
      subjectAltName:URI or a set of allowed X.509v3 Certificate
      Policies).

I could imagine an extendedKeyUsage being configured, too.

  trust model.  As a suggestion, at least the following parameters of
  the X.509 client certificate SHOULD be exposed:

What about non-extended keyUsage, and arbitrary X.509 extensions?

  *  Originating IP address

I don't think "originating IP address" is a parameter of the X.509 client
certificate.

  *  Certificate Fingerprint

Using what hash algorithm?

  *  Subject
  [...]
  *  all X.509v3 Subject Alternative Name

Per RFC 5280 (§ 4.1.2.6) the SAN *is* (part of) the Subject.

Section 5.2.2

As above, fingerprint using what hash algorithm?

Section 5.2.3

  This mechanism is OPTIONAL to implement.  In this mode, the RPC peer
  is uniquely identified by keying material that has been shared out-
  of-band or by a previous TLS-protected connection (see Section 2.2 of
  [RFC8446]).  [...]

I strongly suggest not mentioning the "by a previous TLS-protected
connection (see Section 2.2 of [RFC8446])" case here; the TLS stack should
handle resumption transparently and expose the identity information from the
original handshake.  There's no need to make the application manage and
track the resumption PSK identifier values.

  *  TLS Identifier

nit: missing "PSK".

Section 7

It's probably worth pulling in (by reference) the security considerations of
RFCs 5280 and 8446 as well.

Section 7.1.1

  *  Client security policy can require that a TLS session is
      established on every connection.  If an attacker spoofs the
      handshake, the client disconnects and reports the problem.  If

It might be worth adding a few more words about how this is a "fail-safe"
setup where the attacker cannot cause the client to fall back to plaintext.

Section 7.1.2

  The exception to this edict is the initial RPC NULL procedure that
  acts as a STARTTLS message, which cannot be protected.  This RPC NULL
  procedure contains no arguments or results, and the AUTH_TLS
  authentication flavor it uses does not contain user information.

I suggest hammering home the conclusion, ", so there is negligible privacy
impact from this exception".

Section 7.2

I'd consider using the phrase "credentials" instead of, or in addition to,
"identity material".

Section 7.3

  but it does enable receivers to reject non-participant messages.  In
  particular, transport layer encryption plus peer authentication
  protects receiving XDR decoders from deserializing untrusted data, a
  common coding vulnerability.

I might go on to add that these decoders would still be exposed to untrusted
input in the case of the compromise of a trusted peer (or trusted CA).

  In light of the above, it is RECOMMENDED that when AUTH_SYS is used,
  every RPC client should present host authentication material to RPC
  servers to prove that the client is a known one.  The server can then
  determine whether the UIDs and GIDs in AUTH_SYS requests from that
  client can be accepted.

Perhaps add ", based on the authenticated identity of the client"?

Section 7.4

  *  When using AUTH_NULL or AUTH_SYS, both peers are required to have
      DNS TLSA records and certificate material, and a policy that

I suggest to s/DNS/DANE/ or s/DNS/DNSSEC/.

  *  RCPSEC_GSS provides integrity and privacy services which are
      redundant when TLS is in use.  These services should be disabled

["largely redundant", again]

Section 8

I think we should consider getting IANA to allocate OIDs for some X.509
extendedKeyUsage values that correspond to RPC-TLS client/server usage.
It's not necessarily something that we'd require to be present (but would be
helpful if a dedicated RPC-TLS PKI was to appear), but is useful to have
available for when it's needed.  This would presumably be under the
1.3.6.1.5.5.7.3 arc, and the referenced documents for existing allocations
usable as a template for what text to put in.

Section 8.1

Isn't it codepoint squatting to claim auth flavor 7 before IANA has
allocated it?  (This is usually a Discuss-level issue, but that part is too
long already so I left it here.)

Section 9.1

RFC 7258 doesn't seem like it needs to be normative.

Appendix A

Maybe link to draft-dnoveck-nfsv4-security-needs for further (extensive!)
discussion of the weaknesses of AUTH_SYS?

  3.  The use of 32-bit unsigned integers as user and group identifiers
      is problematic because these data types are not cryptographically
      signed or otherwise verified by any authority.

Also problematic due to the need for database consistency between
client/server.

[Ballot discuss]
** Despite Section 5.0 stating that only TLS v1.3+ can be used, there are two references to TLS v1.2 mechanisms:

-- Section 5.0. Per “Implementations MUST support certificate-based mutual authentication.  Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL”.  Shouldn’t Section 2.2.2 or 4.2.11 of RFC8446 be used instead?

-- Section 5.2.4.  The token binding mechanism suggested here, RFC8471, only applies to TLS v1.2.  The expired draft-ietf-tokbind-tls13 provides the TLS v1.3 mechanism.

** Section 7.4.  Per “When using AUTH_NULL or AUTH_SYS, both peers are required to have DNS TLSA records and certificate material …”, what is “certificate materials”?  Can this guidance please be clarified (and perhaps related to the options specified in Section 5.2).

[Ballot comment]
Thank you for addressing the early SECDIR review items (and thank you Derrell Piper and Alan Alan DeKok for doing them)

** Section 1.  Per “Encryption by Default: Transport encryption can be enabled without … generating additional keying materials”, I’m not sure that this is accurate if the server and clients need to be keyed with certificates or PSK for TLS

** Section 4.1. Per “Policy settings on the RPC-over-TLS-enabled peer determine whether RPC operation continues without the use of TLS or RPC operation is not permitted.”, I had trouble parsing this sentence.

** Section 4.1.  Per “RPC operation can continue …”, it might be worth repeating what was stated earlier that  “[t]he RPC operation can continue if permitted by local policy …”

** Section 5.2.1.  Per “For services accessed by their network identifiers (netids) and universal network addresses (uaddr), the iPAddress subjectAltName SHOULD be present in the certificate and must exactly …”, why not a normative MUST?

** Section 5.2.1.  Per “For example, if the Issuer is not in a trusted set of Issuers, the RPC server may decline to perform RPC transactions with this client.”, wouldn’t the TLS connection fail in this case and not even get to whatever authorization logic the RPC server might have?

** Section 5.2.1.  Per “As a suggestion, at least the following parameters of the X.509 client certificate SHOULD be exposed … Originating IP address”, how exactly should this IP address be exposed in the certificate, or is this intended to be the IP address of the peer which presented the certificate?

** Section 5.2.2 and 5.2.4.  Both 5.2.1 and 5.2.3 described what information should be exposed by implementations.  These sections omit that information.  For example, I would have expected Section 5.2.4 to discuss Token Binding IDs

** Section 5.2.2.  Is there any MTI guidance on the kinds of digests to support for these fingerprints?

** Section 5.2.4.  Are there any MTI parameters for the token binding to specify?

** Section 7.3.  Per “… it is RECOMMENDED that when AUTH_SYS is used, every RPC client should present authentication materials to RPC servers …”, is this the same thing as saying that when AUTH_SYS is used a mutual authentication TLS-scheme is RECOMMENDED?  I concur with this approach.  I would just recommended saying that explicitly.

** Section 7.4.  Is there a reason not to use normative language in this section?  Specifically, RECOMMENDED for the first bullet and SHOULD for the second.

** Editorial Nits:
-- Section 5.  Typo. s/Similary/Similarly/

-- Section 7.1.2. Typo. s/connnection/connection/

[Ballot comment]
I'm having trouble parsing the first paragraph of Section 4.1.

Thank you for including Section 6.

The REQUIRED in Section 7.1 isn't actually an interoperability concern, is it?

[Ballot comment]
Thank you for the work put into this document.

Please find below a couple on non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
As section 4.2 specifies the use of at least server-side authenticated TLS session, I wonder why the abstract contains 'opportunistic encryption'.

-- Section 4.1 --

"(D)TLS-protected RPC" while DTLS was never expanded before... or did I miss it ?

-- Section 6.3 --
Just puzzled by "No comments from implementors" about Hammerspace while one author is affiliated with Hammerspace.

[Ballot comment]
[[ questions ]]

* Can/should the same AUTH_TLS w/ NULL RPC check be done on the rpcbind
  (portmapper) service as well?

* What mechanism guarantees that (D)TLS traffic can always and easily be
  distinguished from RPC traffic on the same port?


[[ nits ]]

[ section 5.1.1 ]

* "When operation is complete" ... In addition to a grammar tweak, you
  might repeat a few choice words from section 7.2 about the ability to
  send multiple requests over a connection.

[ section 7.4 ]

* s/RCPSEC_GSS/RPCSEC_GSS/

[Ballot comment]
Thank you for this draft. I fully support bringing TLS into more use cases of this type.

Some comments:
Sec 1.
"Moreover, the use of AUTH_SYS remains common despite the adverse effects that acceptance of UIDs and GIDs from unauthenticated clients brings with it. Continued use is in part because:

Per-client deployment and administrative costs are not scalable. Administrators must provide keying material for each RPC client, including transient clients.
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."

The text above says that something is still in use because..., and then mentions two things that are bad. I think the two items are supposed to refer to GSS?

Sec 4.2 This sure looks like normative text, so s/must not/MUST NOT "... utilize the remote TLS peer identity for RPC user authentication"

Sec 5.1.2 Similarly, s/should/SHOULD "...employ ConnectionIDs of at least 4 bytes in length."

[Ballot discuss]
This presumably a trivial fix but I think it's important enough to be a DISCUSS:

I think the document needs some discussion of the security properties of TLS1.3 early data over TCP, if only to refer to Section 8 of RFC 8446 (replay) and mention that it is not forward-secure, unlike the rest of the payload.

[Ballot comment]
Thank you for this draft. I fully support bring TLS into more use cases of this type.

Some comments:
Sec 1.
"Moreover, the use of AUTH_SYS remains common despite the adverse effects that acceptance of UIDs and GIDs from unauthenticated clients brings with it. Continued use is in part because:

Per-client deployment and administrative costs are not scalable. Administrators must provide keying material for each RPC client, including transient clients.
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."

The text above says that something is still in use because..., and then mentions two things that are bad. I think the two items are supposed to refer to GSS?

Sec 4.2 This sure looks like normative text, so s/must not/MUST NOT "... utilize the remote TLS peer identity for RPC user authentication"

Sec 5.1.2 Similarly, s/should/SHOULD "...employ ConnectionIDs of at least 4 bytes in length."

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-nfsv4-rpc-tls-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the RPC Authentication Flavor Numbers registry on the Remote Procedure Call (RPC) Authentication Numbers registry page located at:

https://www.iana.org/assignments/rpc-authentication-numbers/

a single, new registration will be made as follows:

Identifier String: AUTH_TLS
Flavor Name: TLS
Value: [ TBD-at-Registration ]
Description: Signals the use of TLS to protect RPC messages on socket-based transports.
Reference: [ RFC-to-be ]

IANA notes that the authors have requested a value of 7 for this registration.

Second, in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a single, new registration is to be made as follows:

Protocol: SunRPC
Identification Sequence: 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc")
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, the IESG-designated experts for the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry have asked that you send a review request to the mailing list tls-reg-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-05-27):

From: The IESG
To: IETF-Announce
CC: nfsv4-chairs@ietf.org, draft-ietf-nfsv4-rpc-tls@ietf.org, David Noveck , nfsv4@ietf.org, magnus.westerlund@ericsson.com, davenoveck@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Towards Remote Procedure Call Encryption By Default) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document: - 'Towards Remote Procedure Call
Encryption By Default'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a mechanism that, through the use of
  opportunistic Transport Layer Security (TLS), enables encryption of
  in-transit Remote Procedure Call (RPC) transactions while
  interoperating with ONC RPC implementations that do not support this
  mechanism.  This document updates RFC 5531.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/



No IPR declarations have been submitted directly on this I-D.

1. Summary

This docuument provides for the encryption of RPC transactions using opportunistic TLS,
extending RFC 5531, for which the nfsv4 working group is also responsible.  The Shepherd
is David Noveck and the Responsible Area Director is Magnus Westerlund.  The working group
anticipates that this document will be approved as a Proposed Standard, as is appropriate
given that RFC5531 which it extends is currently a Proposed Standard.

2. Review and Consensus

This document has the support of the working group and has had extensive discussion and
review within the working group and considerable work in the form of prototype
implementations.  Although this document provides a necessary building-block there has
already been discussion about developing policies for protocols at the level above RPC
(e.g NFSv4) that might require use of the mechanisms defined in this document to mitigate
security weaknesses in the handling of existing protocols for which the working group is
responsible.  These weaknesses include the very limited of support privacy exposing much
traffic to monitering and the pervasive acceptance of requests using AUTH_SYS
"authentication" from unauthenicated clients.

While the working group agrees that the approach taken here to improve RPC security is an
appropriate one, there have at times been worries about its acceptability to the larger
IETF community.  In particular, the fact that this document seeks to limit the harm caused
by use of AUTH_SYS (by provinding encryption and client authentication), as opposed to
outlawing or otherwise denigrating it, has led some to wonder whether the current approach,
while technically sound, would encounter resistance from those who felt otherwise  For
this reason a number of reviews by the Security Directorate have been scheduled, which
found important issues which have been addressed in the current draft.  As to the continued use of AUTH_SYS within NFSv4, it is now generally accepted that that is a descision to be
made in another document and that the building blocks provided in this document are a
desirable precursor for the necessary later discussion.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the
document.

1. Summary

This docuument provides for the encryption of RPC transactions using opportunistic TLS,
extending RFC 5531, for which the nfsv4 working group is also responsible.  The Shepherd
is David Noveck and the Responsible Area Director is Magnus Westerlund.  The working group
anticipates that this document will be approved as a Proposed Standard, as is appropriate
given that RFC5531 which it extends is currently a Proposed Standard.

2. Review and Consensus

This document has the support of the working group and has had extensive discussion and
review within the working group and considerable work in the form of prototype
implementations.  Although this document provides a necessary building-block there has
already been discussion about developing policies for protocols at the level above RPC
(e.g NFSv4) that might require use of the mechanisms defined in this document to mitigate
security weaknesses in the handling of existing protocols for which the working group is
responsible.  These weaknesses include the very limited of support privacy exposing much
traffic to monitering and the pervasive acceptance of requests using AUTH_SYS
"authentication" from unauthenicated clients.

While the working group agrees that the approach taken here to improve RPC security is an
appropriate one, there have at times been worries about its acceptability to the larger
IETF community.  In particular, the fact that this document seeks to limit the harm caused
by use of AUTH_SYS (by provinding encryption and client authentication), as opposed to
outlawing or otherwise denigrating it, has led some to wonder whether the current approach,
while technically sound, would encounter resistance from those who felt otherwise  For
this reason a number of reviews by the Security Directorate have been scheduled, which
found important issues which have been addressed in the current draft.  As to the continued use of AUTH_SYS within NFSv4, it is now generally accepted that that is a descision to be
made in another document and that the building blocks provided in this document are a
desirable precursor for the necessary later discussion.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the
document.