chucklever / i-d-rpc-tls Goto Github PK

General Comments

Importance of this Work

This work addresses the two biggest problems in NFSv4 security and could serve as a basis to allow secure use of NFSv4 on the internet, which was one of the original goals of NFSv4. My thanks to Chuck and Trond for taking this on and bringing the work to this point.

State of the Document

This document is in good shape. The issues I've found concern how the material is presented rather than indicating problems in the approach taken or the specific choices made.

Per-Section Comments

1. Introduction

I feel that some reorganization of the second paragraph and the associated bullets would be helpful. I think you need to decide whether the focus is to be on the diffculties of deploying RPCSEC_GSS or the difficulties of deploying RPCSEC_GSS with privacy, which, to me are more clear-cut and are really the major thing that this proposal addresses. Note that, of the four bullets below this paragraph, only two are relevant to privacy while the paragraph after the bullets only makes sense if it speaking about RPCSEC_GSS with privacy. It is not the case that RPCSEC_GSS is not used at all, altough it is not used as much as originally hoped.

I think you might consider a replacement along the following lines:

The Remote Procedure Call version 2 protocol has been a Proposed Standard for three decades (see [RFC5531] and its antecedants). Eisler et al. first introduced an in-transit encryption mechanism for RPC with RPCSEC GSS over twenty years ago [RFC2203]. However, experience has shown that RPCSEC GSS with in-transit encryption can be difficult to deploy and use:

• Parts of each RPC header remain in clear-text, and can constitute a significant security exposure.
• On-host cryptographic manipulation of data payloads can exact a significant CPU and memory bandwidth cost on RPC peers. Offloadng does not appear to be practical using GSS privacy since each message is encrypted using its own key based on the issuing RPC user. As a result, the performance penalty is so significant that, for many important RPC-based protocols, RPCSEC_GSS wiith privacy is hardly ever used.

However strong a privacy service is, it cannot provide any security if the challenges of using it result in it not being used at all.
In addition, the use of AUTH_SYS remains common despite the negative effect on security that server acceptnce of uids and gids from unauthenticated clients brings with it. This is in part because:

• Per-client deployment and administrative costs are not scalable and, in many environments may be considered excessive. Keying material must be provided for each RPC client user, including transient users.
• Host identity management and user identity management must be carried out in the same security realm. In certain environments, different authorities might be responsible for provisioning client systems versus provisioning new users.

Through the use of TLS-aided client authentication these difficulties can be addressed without the security compromises that result from the use of AUTH_SYS, without client authentication and in the clear.

At the the start of the third (non-bulleted) paragraph, suggest replacing "an alternative approach" by "The Alternative approach proposed here".

With regard to your benefits paragraphs I feel some reorganization could be helpful to render the presentation more impactful:

• While "Encryption by default" is strong, it would better if it was immediately followed up by the second major benefit "Encryption Offload".
• I feel it is a mistake to mention AUTH_SYS where you do, before telling people you have rendered it more safe. So "Decoupled User and Host Identities" should appear after "Securing AUTH_SYS" and be revised in light of the fact that AUTH_SYS has been rendered OK (e.g. changing "still using" to "safely using").
• "Protection of Existing Protocols" should not be listed among these benefits since the first sentence of the paragraph is true of RPCSEC_GSS as well. I think you can add some of this material to a revised penultimate paragraph as I suggest below.

With regard to the penultimate paragraph of this section, I'm suggesting a revision to

• Incorporate material from "Protection of Existing Protocols"
• Eliminate the reference to RFC7435 (entitled "Opportunistic Security: Some Protection Most of the Time").

Although both this document and "opportunistic TLS" use the word "opportunistic", they are effectively homonyms and referencing RFC7435 adds confusion.

Would like you to consider the following replacement paragraphs:

This document specifies the use of RPC on a TLS-protected transport in a fashion that is transparent to upper layer protocols based on RPC. This transport layer encryption can protect all minor versions of NFS version 4 [RFC7530][RFC5661][RFC7862] as well legacy NFS versions such as NFS version 3 [RFC1813], NFS side-band protocols such as the MNT protocol [RFC1813] and other protocols using RPC.

We specify policies that enable RPC-on-TLS to be deployed opportunistically in environments with RPC implementations that do not support TLS. Specifications for RPC-based upper layer protocols are free to adopt stricter policies to guarantee that TLS with encryption or TLS with host authentication and encryption is used for every connection or that connections for which these facilities are not available are restricted as to the facilities they are allowed to use.

4.2.1. Using TLS with RPCSEC GSS

I don't think the word "client" in the second paragraph is correct. IIUC, it is the requesting user rather than the client itself that is authenticated.

5.1.3. Operation on Other Transports

In the third sntence of the first paragraph, suggest:

• replacing "provisions" by "other provisions"
• replacing "could" by "would need to be"

In the first sentence of the second pragraph, suggest replacing "accommodated" by "addressed".
In the second sentence ofthe second paragraph, suggest replacing "might" by "would"

7.2. Multiple User Identity Realms

I don't see how establishing an independent TLS session for each user identity domain would prevent privileged users in each security realm from monitoring RPC traffic emitted on behalf of users in other security realms on the same peer. What am I missing? Are there some unstated assumptions about what privileged users might be allowed to do?

7.3. Security Considerations for AUTH_SYS on TLS

With regard to the penultimate paragraph, I don't see how this recommendation, desirable as it is, can provide any assurance that clients are "acting responsibly" Suggest the following as a possible replacement:

In light of the above, it is RECOMMENDED that when AUTH_SYS is used, RPC clients present authentication material to RPC servers and that servers use this material to determine if the client is a known one, so that they can make a determination whther the UIDs and GIDs in AUTH_SYS requests can be accepted as-is, subject to some degree some filtering or montitoring, or whther all AUTH_SYS requests on this connection are to be rejected.

With regard to the last sentence of the last paragraph, I think it should be noted that this issue could be addressed by not having names for these users and using numeric id's instead.

1. Section Status of this memo:

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

What material in this document is not provided according to BCP 78 and the TLP? I just wonder if you are over careful, or is something verbatim copied from an old RFC?

2. Section 3:

Note also that the NFS community uses the term "privacy" where other Internet communities use "confidentiality". In the current document, the two terms are synonymous.

Can this usage of privacy be avoided? Confidentiality is a tool to help provide privacy. So I think you should try to conform to more mainstream usage of privacy and use confidentiality where that is actually what is provided. See later comment also where this distinction becomes relevant.

3. Section 4.1:

  <CODE BEGINS>
enum auth_flavor {
           AUTH_NONE       = 0,
           AUTH_SYS        = 1,
           AUTH_SHORT      = 2,
           AUTH_DH         = 3,
           AUTH_KERB       = 4,
           AUTH_RSA        = 5,
           RPCSEC_GSS      = 6,
           AUTH_TLS        = 7,
/* and more to be defined */
   };
<CODE ENDS>

In this particular case, it might not be a major issue, but it is recommended that not put the numbers from the IANA registry into the document until it has been assigned to the document. In cases where one needs a number for testing during development, one can in many registries actually issue an early assignment.

To me, the right way of doing this table would have been to replace the 7 on the AUTH_TLS line with a [IANA_TBA]. And add an RFC-editor note in this section, and the necessary IANA sub-section requesting assignment. And if a number would have been needed for the implementation an early assignment request could have been done, and then converted to a permanent one using the IANA section.

4. Section 4.1:

In Section 5.1.1 is clear that the RPC receiving entity should reject requests that are not sent over TLS. However, there appears to be no requirement to actually send all subsequent requests over TLS made in section 4.1. I think such a statement should be added.

5. Section 4.2.1:

A TLS-capable RPC implementation uses GSS channel binding to determine when GSS integrity or privacy is unnecessary. See Section 2.5 of [RFC7861] for details.

RFC 7861 Section 2.5 says:

2.5. RPCSEC_GSS_BIND_CHANNEL Operation

RPCSEC_GSSv3 provides a channel-binding assertion that replaces the RPCSEC_GSSv2 RPCSEC_GSS_BIND_CHANNEL operation.

The RPCSEC_GSS_BIND_CHANNEL operation is not supported on RPCSEC_GSS version 3 handles. If a server receives an RPCSEC_GSS_BIND_CHANNEL operation on an RPCSEC_GSSv3 handle, it MUST return a reply status of MSG_ACCEPTED with an accept_stat of PROC_UNAVAIL [RFC5531].

I don't see how the details in 2.5 provide an answer to how each peer can determine that TLS Is present by using the GSS channel binding. Maybe this is understandable by someone that understands GSS in detail. However, I think some more details are needed.

6. Section 5.1.1:

After establishing a TLS session, an RPC server MUST reject with a reject_stat of AUTH_ERROR any subsequent RPC requests over a TLS-protected connection that are outside of a TLS session.

I assume this is actually bound to a host or a user identity? Because reading the above sentence immediately made me ask how can the RPC server determine that the RPC request is coming from an entity that already has an TLS session? Can you please clarify this question?

7. Section 5.1.2. Operation on UDP

RPC over UDP is protected using DTLS [RFC6347].

DTLS 1.3 specification appears to have been publication requested so it is not significantly later than your document in the process. Thus, I wonder if it wouldn't be better to require DTLS 1.3 to match version with TLS 1.3? I also recommend being explicit about the version in this sentence. I have also asked the responsible SEC AD about the status of DTLS 1.3 so I hopefully have more input into this question soon.

8. Section 5.1.2:

As soon as a client initializes a socket for use with an unfamiliar server, it uses the mechanism described in Section 4.1 to discover DTLS support and then negotiate a DTLS session.

So, first of all, is the usage of TLS for TCP completely separate from using DTLS over UDP? So having determined TLS support for TCP does not indicate the same for UDP? And is it in any case possible to skip the initial RPC null request with AUTH_TLS authentication and go directly to negotiate TLS after support has been determined with a server?

9. Section 6.

Should there be an RFC-editor note that the whole of Section 6 should be removed prior to publication, or do you intended to have this section included in the RFC? I do note that RFC 7942 does indicate the removal of this section.

10. Section 7:

Privacy leakage due to STARTTLS procedure. So what is sent in clear text over the TCP connection prior to the TLS session establishment? Is there information here that provides any information that enables tracking of client, or the user on the client? If there is anything that may be sent that could allow tracking that should be mentioned in the security consideration.

11. Section 8:

ALPN label.

So the IANA section requests the ALPN label "sunrpc" however the document fails to discuss how this is to be used. If it is to be used, then I think there needs to be a requirement on including it and verifying that it is present. I also wonder if the WG expect that this label can be used also for a future TLS based solution that requires the usage of TLS, or if you actually need to have a separate label between them to identify on TLS Level the difference in policy and intention of the request by the client.

12. Section 8.

I am missing a sub-section requesting the assignment of the AUTH_TLS value from the
RPC Authentication Flavor Numbers registry. What I can see that request has not yet been named as value 7 is unassigned.

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

13. Requirement on implementation

Should this document actually update any or all of the versions of NFS 4 to mandate implementation support? From the WG's perspective doesn't it make sense to start demand implementation support. The mechanism is clearly opportunistic in its establishment, however, the goal here needs to be to get support in as many places is as possible. Thus, sending a clearer signal that NFS 4.x servers and clients are expected to support this should be sent. If not can you clarify what the concerns are? Because we are going to get this question again in the IESG evaluation.

To me, the reasonable plan towards always used transport security (something I expect the full updates, for example of NFS v4.1 to require) is to require implementation but not used now. Then next step to require its usage.

Although we don't intend to fully support using TLS identities to represent single RPC users in this iteration of the protocol, that is an eventual possibility. We want to ensure the document does not unnecessarily limit the possibility, potentially by permitting deployments to use multiple TLS identities on a client (or even, specifically, permitting a client to use each user's certificate to create a separate TLS session for each user).

The MUST NOT in the 2nd paragraph is too vague to be implemented. This text needs to be strengthened, making it clear what the implementations have to do.

The reason the current protocol does not bind the client certificate to a particular user is because we want to enable encryption in the following usage scenarios:

• The client has no certificate
• The client has a certificate that is shared amongst some or all of its users
• Each user has her own certificate (or, the client has a single user which is indistinguishable from the host itself)

The problem is that, given the currently proposed protocol extension, the server has no way to distinguish between the latter two cases.

Regarding the last paragraph of the introduction, I think you have to clarify what you mean by "opportunistic" and recognize that "opportunistic" as used in the phrase "opportunistic TLS" and in RFC 7435 are really homonyms. I'm going to suggest something like the following two paragraphs as a possible replacement:

This document specifies the use of RPC on a TLS-protected transport in a fashion that is transparent to upper layer protocols based on RPC. It is specfied to use opportunistic TLS, enabling use of RPC-on-TLS to be deployed in environments with implentations that do not support it. Specifications for RPC-based upper layer protocols are free to require stricter policies to guarantee that TLS is used for each connection.

Client authentication is provided for using the opportnitunstic approach specified in [RFC7435], allowing encryption to be used even when authenitication is not. However, specifications for RPC-based upper layer protocols are free to require stricter policies to guarantee the client is always authenticated or always authenticated when certain secrity flavors (e.g. AUTH_SYS) are used.

In section 4.1, I'm not clear about the relevance of the last sentence of the first paragraph. While the tatement is true, it doesn't appear relevant to the matter being discussed.

With regard to the two deployment modes, I suggest that what they share (a server cerificate) should be made clearer by pulling thi assumption into the second paragraph. Also I'm concened about overuse of the term "SHOULD". In some cases (e.g. the "SHOULD" now in the second paragraph) I have no idea what circumstance might justify not doing rhe recommended action, while in other cases it appear that the i just describing the way the protocol works and that "SHOULD" might suggest a choice where there really isn't one, leading to a large set of deplyment modes, rather than just two. So here is possible replacement text to consider.

In all cases a server is to posess a unique global identity (e.g., a certificate that is signed by a well-known trust anchor) . The RPC server MUST request a TLS peer identity from each client upon first contact. The availabilit of such client identities and how the absence of such identities are dealt with permits two deployment modes:

Server-only Host Authentication

In this case, clients are anonymous (i.e., present no identifier or any identifier presented ). In this situation, the client will authenticate the server host using the presented TLS identity, but the server cannot authenticate clients.
Mutual Host Authentication

In this type of deployment, all clients are to possess unique identities (e.g., certificates). As part of the TLS handshake, both peers authenticate using the presented TLS identities. If authentication of either peer fails, or if authorization based on those identities blocks access to the server, the client association is to be rejected.
In the second sentence of the first paragraph of section 4.2.1, suggest replacing "disabled" by "avoided".

I'm concrerned abou the use of the term "RECOMMENDED" in the first bullet in secttion 7.1.1. I think thisshould be changed to "recommended". With "RECOMMENDED", the natural interpretation is that you SHOULD do A but MUST do B if you don't. However, you don't have to do any of it since that would invalidate the opportunistic nature of the whole thing.

Section 7.2 really confuses me. First of all it isn't made very clear what "multiple distinct security realms" means although it is natural to assume that they correspond to the multiiple "identity domains" mentioned in the second paragraph.

if that's the case., I don't see how use of the same tls session by the client would compormise the "privacty of RPC users" if the requestring user are [email protected] and [email protected] any more than they would be compromised by use by users [email protected] and [email protected] (i.e. not at all). i suspect that this comes from the security directorate. If so, it makes sense to ask them to clarify exactly what they want and why.

I'd like to suggest the following as a possible replacement for the third paragraph of section 7.3:

In light of the above, it is RECOMMENDED that AUTH_SYS is to be used, RPC clients present authentication material necessary for RPC servers they contact to have a degree of trust that the clients are acting responsibly.

In the second sentence of the last paragraph of suggest adding "in addition," at the start of the sentence.

Suggest replacing the last (unnumbered) paragraph of Appendix A by the following:

In light of the avbove, it should be clear that AUTH_SYS therefore by itself offers little to no communication security:

In item 2, suggest replacing "real" by "actual".

FInally, I'd like to to suggest the following as a replacement for section 5.1,3:

5.1.3. Potential Operation on other Transports
The RPC-over-RDMA transport can make use of Transport Layer Security below the RDMA transport layer [RFC8166]. The exact mechanism is not within the scope of this document. Because there might not provisions made to exchange client and server certificates, authentication material might be provide by facilites with the RPC-over-RDMA transport [TBD].

Transports that provide tls-level security [e.g. QUIC] would need to be accommodated, even though, in such cases, use of TLS is not opportunitic as it is in the cases in which TCP or UDP is used.

Rick Macklem says:
As I am working through implementation of NFS over TLS, I have run into a couple of things related to certificates. Here's an example scenario:

• The client is a laptop that wants to mount a server from "anywhere" using TLS, so that data is encrypted on the wire. The server understandably wants to use "mutual authentication" to determine that the client is indeed one that is allowed to mount the server.

Ok, so now how do you get a certificate for the client that the server can reasonably verify?
--> After a discussion over on a FreeBSD mailing list, it sounds like the easy (maybe only?) way to do this is for the NFS server admin. to run a site local CA and generate certificates against that.

• Although I'm sure there are other ways, you can create a site local CA certificate with two openssl commands and sign a certificate for a client with two more openssl commands.
  Then the server can verify the certificate using the CAcert that was used to sign the client's certificate.

Now, when I read the sections around Page 6 of the draft...

Mutual Host Authentication
In this type of deployment, the client possesses a unique global
identity (e.g., a certificate). As part of the TLS handshake,
both peers authenticate using the presented TLS identities. If
authentication of either peer fails, or if authorization based on
those identities blocks access to the server, the client
association MUST be rejected.

For the above, the client does not possess a unique global identity, it might more correctly be called a "site local identity" that the server can authenticate. Is the "unique global identity" requirement necessary? It seems to me that a site local CA issued certificate might be appropriate. (RFC 5280 page 12, second (a) item seems to allow site local CA certificates).

The current text is confusing. The deeper issue is how keys are managed on the client. Explain the risks of sharing the client's peer identity between users.

Will also need to revisit the discussion of connection management. If we permit multiple sessions/keys on the same connection (multiple user keys) then terminating the connection will impact other sessions sharing that connection.

Tigran opened a thread on this:

https://mailarchive.ietf.org/arch/msg/nfsv4/05AcqG3vXoINtop2tGQUy4KFgiw

Reviewer: Derrell Piper
Review result: Not Ready

I reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents entering the IESG. These comments
are directed at the security area director(s). Document editors and WG
chairs should treat these comments like any other last call comments.

This draft is entitled, "Remote Procedure Call Encryption by Default",
except it does not define this. It instead discusses opportunistic RPC
encryption using TLS (DTLS), encryption that might be used if the sun,
moon, and stars align, and likely only if you're running one of two NFS
implementations mentioned in this draft, which exclude most existing NFS
servers on the Internet today and is incompatible with Linux (pp. 13).

To some extent, this draft simply defines a new enum in ONC RPC, named
AUTH_TLS. It completely handwaves all code changes in RPC and NFS to
support TLS, PKI, GSS-API, or DNSSEC. It contains no pseudocode, just
RFC2119 MUST, MAYs, and SHOULDs.

pp. 5, Discovery

"The mechanism described in this document interoperates fully with RPC
implementations that do not support TLS. The use of TLS is automatically
disabled in these cases."

Hence, Not Ready.

I have great sympathy for wanting to try to make it possible to use TLS
by default in new NFS servers that support it, however even then, I
think this draft falls short. It seems self-contradictory at times, and
seems to continue to default to off, not on, which is exactly what
RFC7258 says we ought not be doing anymore.

Or maybe it doesn't intend to say this, since Token binding and TLSA are
mentioned in Security Considerations, but optional, so it kinda does.
So, defer to the ADs.

pp. 6, Discovery

"Once the TLS handshake is complete, the RPC client and server will have
established a secure channel for communicating. The client MUST switch
to a security flavor other than AUTH_TLS within that channel, presumably
after negotiating down redundant RPCSEC_GSS privacy and integrity
services and applying channel binding."

What are the code changes? GSS-API is subtle, please explain. Are
there really no TLS or DTLS changes for any of this?

pp. 6, Discovery, STARTTLS discussion

ONC RPC person needed. The AUTH_NONE and NULL RPC text is of concern.

pp. 7, Authentication

"If authentication of either peer fails, or if authorization based on
those identities blocks access to the server, the client association
SHOULD be rejected."

MUST be rejected.

pp. 7, Authentication

"Once a TLS session is established, the server MUST NOT utilize the
client peer's TLS identity for the purpose of authorizing individual RPC
requests."

That's a curious statement to end a section on Authentication with. At
least justify that statement.

pp. 8, TLS Requirements

"Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL."

Considering this is retrofit security for a legacy UNIX UID/GID
protocol, making PSKs OPTIONAL almost seems quaint here, but okay.

pp. 8, TLS Requirements

"Support for and negotiation of compression is OPTIONAL." Noted.

pp. 9, Operation on Other Transports

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

"opportunitic" is misspelled, and I don't know what to make of this
sentence, but I have very partisan views on QUIC, so defer to the ADs.

I assume Section 5.1.3 is there for RDMA but it doesn't say anything.

pp. 11, X.509 Certificates Using Fingerprints

"Implementations MUST support SHA-1 as the hash algorithm for the
fingerprint. To prevent attacks based on hash collisions, support for a
more contemporary hash function, such as SHA-256, is RECOMMENDED."

SHA-1's deprecated, right? So we shoudn't be mandating SHA-1 in new
RFCs, right? Defer to AD.

pp. 11 Pre-Shared Keys

"should be exposed" -> "SHOULD be exposed"

pp. 12, DESY, Hammerspace, and Linux

Why are these two implementations called out? This section does not
give me confidence that this all interoperates, is it supposed to?

pp. 13, Security Considerations

Since absolute compatibilty with fielded insecure NFS is stated as a
requirement, the obvious downgrade attack is not only permitted, but
required. Again, RFC7258 says that's no longer acceptable, doesn't it?
nAgain, defer to the ADs.

"Implementations must take care to accurately represent to all RPC
consumers the level of security that is actually in effect." How?

pp. 14, Security Considerations for AUTH_SYS on TLS

"In light of the above, it is RECOMMENDED that when AUTH_SYS is used,
RPC clients present authentication material necessary for RPC servers
they contact to have a degree of trust that the clients are acting
responsibly."

Hence, "if the sun, moon, and stars align." Again, this is not in the
spirit of RFC7258. And just to remind, AUTH_SYS doesn't make sense on
non-UNIX operating systems, but that perhaps is my partisan viewpoint.

In closing, there's two broad questions to consider:

1. Does this do no harm?

2. Does it improve security on the Internet in the spirit of RFC7258?

This is going to have to be much more detailed to convince me that it
does either of these things for any implementation other than DESY or
Hammerspace, and without other reference implemenatation in the BSDs or
a least some flavors of Linux, you can't say this broadly interoperable
either. Distributed file systems are never easy, hence DCE/AFS, so
granted it's not an easy problem, but this is not ready to advance on
Standards Track, unless merely being interoperable with legacy code is
all we aspire to, and I sincerely hope it's not.

Perhaps this needle can be threaded and with appropriate configuration
by enterprising people, TLS can be configured with DNSSEC and GSS-API in
RPC and NFS and it will do something reasonable and secure, but I would
like to see at least some more comments from implementation experience
before I could recommend this advance.

Derrell