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

Hi Ben-

Thanks for your thorough review and comments. I'd prefer to nail down
the document updates wrt Roman's DISCUSS / COMMENTs before responding
to yours. If that is not acceptable, please let me know!

> On Jul 8, 2020, at 2:56 AM, Benjamin Kaduk via Datatracker <noreply@ietf.org> 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:
> ----------------------------------------------------------------------
> 
> 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.
> 
> 
> ----------------------------------------------------------------------
> 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.
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever