Subject: [secdir] Secdir review of draft-ietf-nfsv4-rfc5666bis-10

From: Vincent Roca <[email-masked]>
Date: Fri, 24 Feb 2017 13:59:44 +0100

Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

Summary: ready with issues

Main comments:

A long and detailed Security considerations section is provided, which is clearly a good thing. However I have
a few comments WRT this section:

** Privacy or confidentiality? Throughout section 8, authors mention "Privacy" inappropriately IMHO.
Privacy refers to PII (Personally identifiable information) which is different. For instance in section 8.2, when saying:
        "However, integrity and privacy services require significant movement of data on each endpoint host."
the authors really mean confidentiality (this is mentioned just above, when saying that RPCSEC_GSS implements
"per-message confidentiality"). There are several mistakes of that kind throughout section 8.

** On the opposite, meta-data can raise privacy issues, regardless of whether the content is encrypted or not.
Can an eavesdropper who observes the traffic from an intermediate node (for instance) derive these meta-data
and identify the hosts that communicate together, at what frequency, when?
It probably depends on the protection provided (IPsec versus other RPCSEC integrated approach if I understand
correctly). However if this is the case then there can be privacy impacts... Is it the case, this is not detailed?

** Section 8.1: it is said:
        "The use of RPC-over-RDMA MUST NOT introduce any vulnerabilities to system memory contents, nor to
	memory owned by user processes."
This is of course highly desirable, but how can the destination be sure that data copied in its own memory does not
contain a malware? I have the feeling (but may be wrong) that there's a confusion between the RPC-over-RDMA 
**protocol** that MUST be secure, and the **content** transferred between two hosts where it's more a matter of
trust between them.

** Section 8.2.2.1: What happens when there's no TCP based NFS server on port 2049? The authors could be
more explicit and provide guidance.

** Section 8.2.2.4: There's something that is not clear to me.
It is said that "IDs, connection credit limits, and chunk lists" are exposed and if an attacker alters them, several
consequences are possible.
I understand that this information **is not** included in the RPCSEC_GSS integrity verifications.
Is it really the case?  I'm asking this because the paragraph concludes with:
        "The use of RPCSEC_GSS integrity or privacy services enable the requester to detect if such tampering 
	has been done and reject the RPC message."
which suggests that this information **is** protected.

** Last sentence:
	"To address attacks on RDMA protocols themselves, RDMA transport implementations should conform
	to [RFC5042]."
"should" or "SHOULD"?

Minor comments:

- A side comment: can we really say that IPsec can be co-located in RDMA hardware "without any [...] loss of 
data movement efficiency"? I'd rather say that the IPsec performance impacts can be **greatly reduced**.

- Typo in Introduction: "future NFSv4 minor verions" => versions

Cheers,

   Vincent

---

From: Chuck Lever <[email-masked]>
Date: Fri, 24 Feb 2017 10:57:53 -0800

> On Feb 24, 2017, at 4:59 AM, Vincent Roca <[email-masked]> wrote:
> 
> Hello,
> 

Hi Vincent-

Thanks for your review.

I believe your questions are mostly rhetorical,
so I will respond to those by saying the authors,
shepherd, and AD will attempt to address these
issues with the next document revision.

There is one remaining comment that IMO needs
group discussion, below.

> 	"To address attacks on RDMA protocols themselves, RDMA transport implementations should conform

Lower case "should" is used here because this statement
is IMO not an interoperability directive. I hope I
correctly understand the intent of your question.

If there is a security requirement that this be changed
to the RFC 2119 term, please let us know and that can be
done.

Any other thoughts about this?

--
Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Fri, 24 Feb 2017 21:28:37 +0000

[eliding some lines for brevity]

> -----Original Message-----
> From: Chuck Lever [mailto:[email-masked]]
> Sent: Friday, February 24, 2017 1:58 PM
> To: Vincent Roca <[email-masked]>
> Cc: IESG <[email-masked]>; [email-masked]; draft-ietf-nfsv4-
> [email-masked]
> Subject: Re: Secdir review of draft-ietf-nfsv4-rfc5666bis-10
> 
> 
> > I have reviewed this document as part of the security directorate’s
> > ongoing effort to review all IETF documents being processed by the
> > IESG. These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should treat
> > these comments just like any other last call comments.
>... 
> Hi Vincent-
> 
> Thanks for your review.
> 
> I believe your questions are mostly rhetorical, so I will respond to those by
> saying the authors, shepherd, and AD will attempt to address these issues with
> the next document revision.
> 
> There is one remaining comment that IMO needs group discussion, below.
> 
> 
> > Privacy refers to PII (Personally identifiable information) which is different.
> For instance in section 8.2, when saying:
> > the authors really mean confidentiality (this is mentioned just above,
> > when saying that RPCSEC_GSS implements "per-message confidentiality").
> There are several mistakes of that kind throughout section 8.

Regarding "privacy", this term is used in the document because all the NFS RFC's use it in this way. While I agree with you that there is room for confusion, it would be even wider if we switched terminology here.

>...
> Lower case "should" is used here because this statement is IMO not an
> interoperability directive. I hope I correctly understand the intent of your
> question.
> 
> If there is a security requirement that this be changed to the RFC 2119 term,
> please let us know and that can be done.

I don't think SHOULD is appropriate here. This statement refers to other protocols, in particular lower layers then this document, and in the case of the relevant IETF RDMA protocols, RFC5042 is already a required conformance. Therefore the statement is informational here, and not an RFC2119 usage.

Tom.

---

From: Chuck Lever <[email-masked]>
Date: Fri, 24 Feb 2017 13:37:41 -0800

> On Feb 24, 2017, at 1:28 PM, Tom Talpey <[email-masked]> wrote:
> 
> Regarding "privacy", this term is used in the document because all the NFS RFC's use it in this way.

For example, RFC 7861 "Remote Procedure Call (RPC)
Security Version 3" has this:
 
///  enum rpc_gss_service_t {
///           /* Note: The enumerated value for 0 is reserved. */
///           rpc_gss_svc_none
///           rpc_gss_svc_integrity
///           rpc_gss_svc_privacy
///           rpc_gss_svc_channel_prot = 4
///  };

The term "privacy" as used in rfc5666bis comes from
RPCSEC.

> While I agree with you that there is room for confusion, it would be even wider if we switched terminology here.

Perhaps we should consider replacing "per-message
confidentiality" ?

--
Chuck Lever