Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <159419140773.2153.2711644434582054796@ietfa.amsl.com>
Date: Thu, 9 Jul 2020 10:39:16 -0400
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpc-tls@ietf.org,
 nfsv4-chairs@ietf.org, nfsv4@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D74C936B-212A-4416-82AA-EDCAEAE71665@oracle.com>
References: <159419140773.2153.2711644434582054796@ietfa.amsl.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/aEz7aJuFA0oUvRLtl63qpicE1F0>
Subject: Re: [nfsv4] Benjamin Kaduk's Discuss on
 draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
Precedence: list

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:
>=20
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-nfsv4-rpc-tls-08: Discuss
>=20
> 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.)
>=20
>=20
> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>=20
> I support Roman's Discuss points.
>=20
> 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.
>=20
> (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.
>=20
> (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:
>=20
> - 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)
>=20
> - 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 :)
>=20
> - 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.
>=20
> (3) Please check this reference in Section 5.1.1:
>=20
>   Reverse-direction operation occurs only on connected transports such
>   as TCP (see Section 2 of [RFC8166]).  [...]
>=20
> It seems likely that RFC 8167 was intended...
>=20
> (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.
>=20
> (5) Section 5.2.1 requires that:
>=20
>   *  Implementations SHOULD indicate their trusted Certification
>      Authorities (CAs).
>=20
> Indicate to whom?
>=20
> (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.)
>=20
> (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.
>=20
> (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.
>=20
> (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.)
>=20
> (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?
>=20
> (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.
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> 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).
>=20
> Abstract
>=20
> 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".
>=20
> Section 1
>=20
>                                                                    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.
>=20
> I suggest s/is done by/includes/, since in some cases padding or other
> side-channel-resistance mechanisms are also used.
>=20
>   *  Parts of each RPC header remain in clear-text, constituting a
>      significant security exposure.
>=20
> "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".
>=20
>   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:
>=20
>   *  Per-client deployment and administrative costs are not scalable.
>=20
> 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".
>=20
>   *  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.
>=20
> 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.
>=20
>   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
>=20
> side note: I'd consider an editorial rewording to something like:
>=20
> % 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
>=20
>   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.
>=20
> 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.
>=20
>   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.
>=20
> nit: this paragraph, especially the first sentence, feels pretty =
redundant
> with the paragraph that I proposed a rewording of.
>=20
>   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.  [...]
>=20
> 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.
>=20
>   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.
>=20
> We assume that TLS is available where TLS support is to be added?  =
That
> might merit a bit more explanation.
>=20
> Also, what exactly does "PKI" mean, here?  PKIX X.509 certificates?
>=20
> Section 4.1
>=20
>   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
>=20
> I'd consider joining the two sentences via ", subject to policy =
settings on
> the RPC-over-TLS-enabled peer that determine".
>=20
>   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
>=20
> Is there a reference we could put in for the rpcbind service?
>=20
>   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.
>=20
> It might be nice if we could find a way to mention this transport
> restriction in the previous paragraph, though it's hardly vital.
>=20
>   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.
>=20
> 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.
>=20
>   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.
>=20
> nit: is the protocol element a 'reply_stat' field or a 'stat' field of =
type
> 'reply_stat'?  Likewise for reject_stat and auth_stat.
>=20
>   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.
>=20
> 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).
>=20
> Section 4.2
>=20
>   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
>=20
> 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.
>=20
>   from each client upon first contact.  There are two different modes
>=20
> nit: "contact" is perhaps needlessly ambiguous (i.e., w.r.t. TLS =
handshake
> vs. NULL RPC probe); perhaps "during the TLS handshake" suffices?
>=20
>      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.
>=20
> 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.
>=20
>   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
>=20
> 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.
>=20
> Section 4.2.1
>=20
>   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
>=20
> 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).
>=20
> Section 5
>=20
>   *  Negotiation of a ciphersuite providing confidentiality as well as
>      integrity protection is REQUIRED.  Support for and negotiation of
>      compression is OPTIONAL.
>=20
> 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.
>=20
>   *  Implementations MUST support certificate-based mutual
>      authentication.  Support for TLS-PSK mutual authentication
>      [RFC4279] is OPTIONAL.  See Section 4.2 for further details.
>=20
> (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.
>=20
>   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.
>=20
>   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.
>=20
> [this would change if we end up using ALPN to indicate whether GSS =
channel
> binding is used]
>=20
>   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.
>=20
> 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.
>=20
> Section 5.1.1
>=20
>                                                                      =
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.
>=20
> 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?).
>=20
>   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.
>=20
> 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.
>=20
>                                         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.
>=20
> 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)?
>=20
> Section 5.1.2
>=20
>   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
>=20
> "Packetization Layer Path MTU" (PLPMTU, =
draft-ietf-tsvwg-datagram-plpmtud,
> in the RFC Editor's queue) might be a better term to use.
>=20
>   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.
>=20
> 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.
>=20
>   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
>=20
> nit: we seem to prefer RPC-over- to RPC-on (as is used here, across =
the line
> break)
>=20
> Section 5.1.3
>=20
>   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.
>=20
> nit(?): somehow "can be" doesn't feel like the right wording here, but =
"must
> be" isn't right either...
>=20
>   scope of the current document.  Because there might not be other
>   provisions to exchange client and server certificates, =
authentication
>=20
> Er, "other provisions" than what?
>=20
> Section 5.2.1
>=20
>   X.509 certificates are specified in [X.509] and extended in
>   [RFC5280].
>=20
> Note that RFC 5280 claims to be a profile of X.509, not an extension =
to it.
>=20
>   *  Certificate validation MUST include the verification rules as per
>      [RFC5280].
>=20
> 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)
>=20
>   *  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
>=20
> 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.
>=20
>   *  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).
>=20
> I could imagine an extendedKeyUsage being configured, too.
>=20
>   trust model.  As a suggestion, at least the following parameters of
>   the X.509 client certificate SHOULD be exposed:
>=20
> What about non-extended keyUsage, and arbitrary X.509 extensions?
>=20
>   *  Originating IP address
>=20
> I don't think "originating IP address" is a parameter of the X.509 =
client
> certificate.
>=20
>   *  Certificate Fingerprint
>=20
> Using what hash algorithm?
>=20
>   *  Subject
>   [...]
>   *  all X.509v3 Subject Alternative Name
>=20
> Per RFC 5280 (=C2=A7 4.1.2.6) the SAN *is* (part of) the Subject.
>=20
> Section 5.2.2
>=20
> As above, fingerprint using what hash algorithm?
>=20
> Section 5.2.3
>=20
>   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]).  [...]
>=20
> 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.
>=20
>   *  TLS Identifier
>=20
> nit: missing "PSK".
>=20
> Section 7
>=20
> It's probably worth pulling in (by reference) the security =
considerations of
> RFCs 5280 and 8446 as well.
>=20
> Section 7.1.1
>=20
>   *  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
>=20
> 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.
>=20
> Section 7.1.2
>=20
>   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.
>=20
> I suggest hammering home the conclusion, ", so there is negligible =
privacy
> impact from this exception".
>=20
> Section 7.2
>=20
> I'd consider using the phrase "credentials" instead of, or in addition =
to,
> "identity material".
>=20
> Section 7.3
>=20
>   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.
>=20
> 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).
>=20
>   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.
>=20
> Perhaps add ", based on the authenticated identity of the client"?
>=20
> Section 7.4
>=20
>   *  When using AUTH_NULL or AUTH_SYS, both peers are required to have
>      DNS TLSA records and certificate material, and a policy that
>=20
> I suggest to s/DNS/DANE/ or s/DNS/DNSSEC/.
>=20
>   *  RCPSEC_GSS provides integrity and privacy services which are
>      redundant when TLS is in use.  These services should be disabled
>=20
> ["largely redundant", again]
>=20
> Section 8
>=20
> 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.
>=20
> Section 8.1
>=20
> 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.)
>=20
> Section 9.1
>=20
> RFC 7258 doesn't seem like it needs to be normative.
>=20
> Appendix A
>=20
> Maybe link to draft-dnoveck-nfsv4-security-needs for further =
(extensive!)
> discussion of the weaknesses of AUTH_SYS?
>=20
>   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.
>=20
> Also problematic due to the need for database consistency between
> client/server.
>=20
>=20
>=20
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever