[nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 08 July 2020 06:56 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: nfsv4@ietf.org
Delivered-To: nfsv4@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBC03A09A6; Tue, 7 Jul 2020 23:56:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-nfsv4-rpc-tls@ietf.org, nfsv4-chairs@ietf.org, nfsv4@ietf.org, David Noveck <davenoveck@gmail.com>, davenoveck@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.7.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <159419140773.2153.2711644434582054796@ietfa.amsl.com>
Date: Tue, 07 Jul 2020 23:56:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/IL5I5cem1p8KiCcDQw3Nd5ruhRE>
Subject: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2020 06:56:48 -0000
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] Benjamin Kaduk's Discuss on draft-ietf-nf… Benjamin Kaduk via Datatracker
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… David Noveck
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… David Noveck
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Chuck Lever
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… David Noveck
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [nfsv4] Benjamin Kaduk's Discuss on draft-iet… David Noveck