Subject: [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03

From: Derrell Piper via Datatracker <[email-masked]>
Date: Tue, 22 Oct 2019 12:54:37 -0700

Reviewer: Derrell Piper
Review result: Not Ready

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

---

From: Chuck Lever <[email-masked]>
Date: Tue, 22 Oct 2019 17:21:12 -0400

Derrell, thank you for your comments.

> On Oct 22, 2019, at 3:54 PM, Derrell Piper via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Derrell Piper
> Review result: Not Ready
> 
> Reviewer: Derrell Piper
> Review result: Not Ready
> 
> except it does not define this.

The document defines a mechanism to achieve this purpose. The goal is
that any server administrator can deploy a certificate (or other
authentication material) on her NFS server, and client implementations
that comply with this document will be able to employ encryption with
no additional encryption material needed. If client implementation
policy requires encryption (which over time, clients should do) then
encryption will be available everywhere without the need to provide
special configuration on each client (unlike GSS/Kerberos).

I can retitle this document "Towards Remote Procedure Call Encryption
by Default". Please let me know if you have a preferred title.

>  It instead discusses opportunistic RPC

I refer you to other work products of the nfsv4 working group. In them
you will find no pseudo-code (except for XDR), only MUST, MAY, and
SHOULD. As a protocol specification, it assumes that support for TLS,
PKI, GSS-API, and/or DNSSEC is already available in an implementation
where RPC-on-TLS might be added. Should the document state that?

> RFC7258 says we ought not be doing anymore.

This mechanism is the first step towards making RPC encryption
the default everywhere. And, except for policy changes in NFS
implementations, the only necessary coding change is support
for sending and recognizing RPC_AUTH_TLS, and then performing
a TLS handshake before allowing further RPC traffic on a
connection.

> there really no TLS or DTLS changes for any of this?

An ALPN number is allocated. No other code changes to TLS are
required. What kind of code changes do you expect, other than
implementation-specific logic to interpose the TLS handshake
at the proper moment? Would it be appropriate to detail those
changes in a document that is suppose to be implementation-
agnostic?

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

Can you be more specific?

> least justify that statement.

I can change this to a "MUST NOT substitute RPC_AUTH_TLS or the
peer identity used for TLS authentication, for the existing forms
of per-request RPC authentication specified by RFC 5531".

> protocol, making PSKs OPTIONAL almost seems quaint here, but okay.

What is your preferred alternative?

> RFCs, right?  Defer to AD.

I can change this to SHA-256, or whatever is the current
preference.

> give me confidence that this all interoperates, is it supposed to?

My understanding of the Implementation Status section is to
show that there are at least two implementations of the protocol
specified in the document. I was not aware that this section was
supposed to make any statement about interoperability with
implementations not mentioned here. In fact, that would seem to
be difficult to do in a document that is fixed at publication
time -- it can't refer to future implementations, of course.

In any event, a Linux kernel implementation is under way, and
I believe there is also interest among Solaris and FreeBSD
implementers. My plan is to introduce those implementations to
the list in this section as they become publicly available. I
am not at liberty to announce products that are not public.

> consumers the level of security that is actually in effect."  How?

I can clarify this.

> spirit of RFC7258.

The point of this language is to suggest a policy of requiring
TLS, rather than leaving it as opportunistic. This is good
implementation guidance.

> And just to remind, AUTH_SYS doesn't make sense on

AUTH_SYS is the most widely deployed RPC authentication flavor
by far. Addressing the security shortcomings for this flavor
is a prime motivation for enabling encryption via TLS.

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

What exactly would demonstrate harmlessness?

> either.

Simple analysis of the discovery protocol specified here shows
that the mechanism can indeed detect when its peer does not
support RPC_AUTH_TLS, and then not use it.

We host two NFS interoperability events a year and can easily
demonstrate that we have achieved reasonable interop, if that
is required by the IESG.

> Distributed file systems are never easy, hence DCE/AFS, so

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Wed, 23 Oct 2019 06:24:01 -0400

>> a least some flavors of Linux, you can't say this broadly interoperable

The document doesn't say that and there is no reason for it to do so.  The
document's
job is to defne a means by which better security could be achieved, when
implementations
are available.   If one waits for implementations to be done before
approviing the
specification, one is going to be waiting a long time, and NFS security
will remain
in its current unsatisfactory state indefinitely.

> demonstrate that we have achieved reasonable interop, if that

I don't believe it is required for a Proposed Standard.   As I understand
it, no actual implementations are required although the working group
has decided that prototyping of extensions is desirable.   Going
beyond that point and requiring full implementations of protocols that
have not been approved would be a mistake.

>> all we aspire to, and I sincerely hope it's not.

I think it should be clear that Chuck's and Trond's aspirations go beyond
this.
If they didn't, there would have been no need to work on this document.
The situation is similar for those who have worked on implementations.

If interoperation with legacy code is all one aspires to, one could
implement
the security specfified in rfcs 7530 and 5661.   These people and the
working
group clearly want something better.

That being said, the ability to work with legacy implementations is, in
practical
terms, a requirement of this enterprise.   There is no point in defining a
secure
protocol island that cannot communicate with the implementations that exist
today.

> > RPC and NFS and it will do something reasonable and secure,

If I understand this correctly, Derrel is saying that, with the appropriate
configuration
which he mentions, you would have someting "reasonanble and secure"  :-)

That makes it hard for me to undertstand the negative tone of this review.
 In any case,
I think his specific suggestions should be followed up on to get the
document ready for
WGLC.
.
> before I could recommend this advance.

I think this is the wrong approach.   In my experience, it is very hard to
get people to
invest resources in implementing something that is not at least a Proposed
Standand,
and potentially open to  radical change before publication.  From a
return-on-investment
perspective, it doesn't make sense to invest in anytihing beyond limited
prototyping.

The fact that so much expeimental implementation has already been done in
this area
illustrates the perceived urgency of the situation with regard to NFS
security.   That
work will continue in any case and implemtation experience will be
available but I
feel it would be a mistake to hold this document up waiting for it.   I
think it would be
best if the document is clarified and improved, go through WGLC, and be
considered
for adoption as a Proposed Standard.   That is a better way of getting
resources
allocated to the job of improving NFS security.

Of course, if anyone has an appoach to improving NFS security, that is
better than
that in rpc-tls, the working group would intestested in earing about it.

On Tue, Oct 22, 2019 at 5:21 PM Chuck Lever <[email-masked]> wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Chuck Lever <[email-masked]>
Date: Wed, 23 Oct 2019 10:17:03 -0400

> On Oct 23, 2019, at 6:24 AM, David Noveck <[email-masked]> wrote:
> 
> The document doesn't say that and there is no reason for it to do so.  The document's
> job is to defne a means by which better security could be achieved, when implementations
> are available.   If one waits for implementations to be done before approviing the
> specification, one is going to be waiting a long time, and NFS security will remain
> I think it should be clear that Chuck's and Trond's aspirations go beyond this.
> If interoperation with legacy code is all one aspires to, one could implement
> the security specfified in rfcs 7530 and 5661.   These people and the working
> That being said, the ability to work with legacy implementations is, in practical
> terms, a requirement of this enterprise.   There is no point in defining a secure 
> protocol island that cannot communicate with the implementations that exist today.
> 
> If I understand this correctly, Derrel is saying that, with the appropriate configuration
> That makes it hard for me to undertstand the negative tone of this review.   In any case,
> I think his specific suggestions should be followed up on to get the document ready for
> WGLC.

Agreed. The entire review has been filed as an issue against the document.

https://github.com/chucklever/i-d-rpc-tls/issues/3

I will work with Trond to address the specific issues Derrell has called out.

> I think this is the wrong approach.   In my experience, it is very hard to get people to
> invest resources in implementing something that is not at least a Proposed Standand,
> and potentially open to  radical change before publication.  From a return-on-investment
> perspective, it doesn't make sense to invest in anytihing beyond limited prototyping.
> 
> The fact that so much expeimental implementation has already been done in this area
> illustrates the perceived urgency of the situation with regard to NFS security.   That
> work will continue in any case and implemtation experience will be available but I
> feel it would be a mistake to hold this document up waiting for it.   I think it would be
> best if the document is clarified and improved, go through WGLC, and be considered
> for adoption as a Proposed Standard.   That is a better way of getting resources
> Of course, if anyone has an appoach to improving NFS security, that is better than

I also welcome hearing new ideas in this area.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Wed, 23 Oct 2019 21:13:38 +0000

I'll admit I haven't read the most recent draft and haven't looked at it
in detail. However, my impression is that the reviewer might be more
comfortable if the draft makes it clear that "rpc-tls only" servers will
not only be permitted, but encouraged.
(I don't see a "http" vs "https" distinction, but extant NFSv4 servers that
 I am familiar with can be configured to only allow clients that use
 RPCSEC_GSS and I would expect that rpc-tls enabled servers could be
 configured the same way.)

As an aside, I do plan on implementing this in Winter 2020, rick

________________________________________
From: nfsv4 <[email-masked]> on behalf of David Noveck <[email-masked]>
Sent: Wednesday, October 23, 2019 6:24 AM
To: Chuck Lever
Cc: [email-masked]; NFSv4; Derrell Piper; [email-masked]
Subject: Re: [nfsv4] Secdir early review of draft-ietf-nfsv4-rpc-tls-03

On Tue, Oct 22, 2019 at 5:21 PM Chuck Lever <[email-masked]<mailto:[email-masked]>> wrote:
Derrell, thank you for your comments.

> On Oct 22, 2019, at 3:54 PM, Derrell Piper via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
>
> Reviewer: Derrell Piper
> Review result: Not Ready
>
> Reviewer: Derrell Piper
> Review result: Not Ready
>

> That's a curious statement to end a section on Authentication with..  At

I can clarify this.

--
Chuck Lever

_______________________________________________
nfsv4 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Thu, 24 Oct 2019 09:13:57 -0400

> On Oct 23, 2019, at 5:13 PM, Rick Macklem <[email-masked]> wrote:
> 

Indeed, they are permitted. All legacy servers will take this form,
and of course, if no certificate material is provided to a TLS-capable
NFS server, it will act as if RPC-on-TLS is recognized but not
supported.

"Encouraged" is a bit strong, however. I think if we /encourage/ a
behavior, it would be to encourage the use of RPC-on-TLS where it is
practical.

> As an aside, I do plan on implementing this in Winter 2020, rick

Thanks Rick!

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Thu, 24 Oct 2019 12:42:03 -0400

> Indeed, they are permitted.

Otherwise there would be no point in writing this document.

> All legacy servers will take this form,

What form?

> and of course,

????

> if no certificate material is provided to a TLS-capable

i don't think this right.   I think encryption without authentication
is of real value if you have other ways of authenticating.   I think
it would be reasonable for server to be configured so as not to
accept use of auth_SYs fro unauthenticated clients.

> "Encouraged" is a bit strong, however.

It's weaker than "recommended", "required", "RECOMMENDED",
and "REQUIRED".   If you don't like those, you are gpoing to have
to say something beyond "OPTIONAL".   Even if there is no
RFC21119, you could describe 9normatively) describe use of this
as "valuable", "highly desirable".

> I think if we /encourage/ a

We certainly don't want to encorage use of this where it is impractical.
If we did, nobody would listen to us, anyway.

Perhaps we can address this non-normatively by accurately describing
the consequences of not using this.   The document on NFSv4 security
will probably take that approach.