Subject: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Apr 2020 08:27:27 +0000

NFSv4 WG,

Sorry my AD review took longer time than it was supposed to. Anyway here are
my comments. And as usual I am not an expert on NFS or RPC. So don't
hesitate to push back or educate me with relevant context if what I comment
appears to be just strange. 

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 are 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 to the document until
it has been assigned to the document. In cases where one need 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 an
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 appear 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 provides 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 to be explicit about 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 cases 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
remove prior to publication, or do you intended to have this section
included in the RFC? I do note that RFC 7942 do indicate removal of this
section. 

10. Section 7: 

Privacy leakage due to STARTLS 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 enable tracking of
client, or the user on the client? If there are 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 used. If it is to be used, then I think
there need 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 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-authenticati
on-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 client 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 usage now. Then next step to require its usage. 

Cheers

Magnus Westerlund

---

From: David Noveck <[email-masked]>
Date: Wed, 1 Apr 2020 08:06:46 -0400

On Wed, Apr 1, 2020, 4:27 AM Magnus Westerlund <magnus.westerlund=
[email-masked]> wrote:

> NFSv4 WG,
>
>
>
> Sorry my AD review took longer time than it was supposed to. Anyway here
> are my comments. And as usual I am not an expert on NFS or RPC.
>

True but you noticed something important (re channel binding) that the
> members of the working group, more knowledgeable about RPC, did not notice.
>

So don’t hesitate to push back or educate me with relevant context if what
> I comment appears to be just strange.
>

We're used to AD'S sounding strange to us.
 Its clear you have issues with some of the strange things we say.

>    the two terms are synonymous.

But it doesn't say what this common meaning is :-(

>
> Can this usage of privacy be avoided.
>

Not totally. A lot of it is embedded in existing hard-to-update documents.

> 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 to the
> document until it has been assigned to the document. In cases where one
> need 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
> an number would have been needed for the implementation an early assignment
> request could have been done,
>

This was needed but wasn't done then.

 then converted to a permanent one using the IANA section.

Not sure what our options are now, given the wide use of 7.

> determine that TLS Is present by using the GSS channel binding.
>

I don't either.

Maybe this is understandable by someone that understands GSS in detail.

And maybe not.

>
>  Howeverr, I think some more details are needed.
>

The alternative, which I do not recommend, is to update the sentence to say
"See Section 2.5 of [RFC7861] to be totally mystified" :-)

I think the place to start in addressing this is to consider what existing
implementations do about this issue.

> Should this document actually update any or all of the versions of NFS 4
> to mandate implementation support?
>

No.  I think we are trying to move in a direction in which there are fewer,
ideally one, document to look at to tell you what you have to do to
implement a minor version.  This document defines an RPC-level facility and
should not reach up the stack in that way.

Fromm the WG's perspective doesn't it make sense to start demand
> implementation support.

We don't want to "demand" things and be ignored.  I think we can, without
demanding it, encourage it's use.

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.
>

Yes.

Thus, sending a clearer signal that NFS 4.x servers and client are expected
> to support this should be sent.
>

I think we can figure out how to send a clearer signal.

> 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 usage now. Then next step to require
> its usage.
>

Maybe I'm getting upper and lower case mixed up but I don't see that you
can reasonably update the specification of a particular minor version, in a
way that defines a significant number of existing implementations as
non-compliant post facto.

Adding  a new recommendation is different. Saying this "SHOULD" be
implemented makes sense, as defined by RFC2119.  (Often "SHOULD" is used as
a "MUST" without a whole lot of conviction. Sigh!).  In this context, the
time to implement, test, and deploy support are valid reasons it might not
be implemented but the text will need to explain clearly the unfortunate
consequences for security.

Regarding staging, we need to treat encryption and client authentication
separately.  For encryption, If the client and server implement this, it
will be used.  There is no need for two stages.  With regard to client
authentication, not sure what we will do, given the issues about
fingerprinting recently discussed on the list.  If those are satisfactorily
addressed before draft-ietf-nfsv4-security is ready, it might make sense to
recommend implementation by client and server, especially where use of
AUTH_SYS is anticipated.  If they aren't, we might see if a phased approach
makes sense.

We will discuss this on 4/22 as part of the rfc5661bis effort.

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

---

From: Chuck Lever <[email-masked]>
Date: Wed, 1 Apr 2020 10:50:34 -0400

> On Apr 1, 2020, at 4:27 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> NFSv4 WG,
>  
> Sorry my AD review took longer time than it was supposed to. Anyway here are my comments. And as usual I am not an expert on NFS or RPC. So don’t hesitate to push back or educate me with relevant context if what I comment appears to be just strange.

Magnus, thank you for your thoughts. These all seem like reasonable
questions. I can answer a few of these right now, and as I make
progress towards a fresh revision of the document, the remaining
questions can be addressed by further discussion.

> What material in this document are 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? 

I don't recall exactly, but I did copy from old RFCs in a few spots.
The RPC authentication flavor enum, for example. I should have added
a comment, but neither the XML source nor the git log appears to
indicate exactly why I added that disclaimer. I assume it's because
of the bits of RFC 5531 that are included herein.

How can we resolve this question to everyone's satisfaction?

> 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.

The NFS community's usage of "privacy" is baked into existing documents,
which is why Section 3 mentions this confusion. I could make that more
clear here by changing it to read:

> Note also that the NFS community has historically used the term "privacy"
> where other Internet communities ...

I read your comment to further recommend that the rpc-tls document adopt
the use of "confidentiality" and entirely shun the use of "privacy". I
can look into doing that, but cannot promise it will be sensible to
replace every last use of "privacy".

> 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 to the document until it has been assigned to the document. In cases where one need 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 an 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. 

Two issues:

- I was not previously aware of the IANA registry for RPC auth
flavors, and interestingly no-one else caught this during WGLC!

- As Dave points out, we have some prototypes that already use
the value 7 for this purpose.

Can someone suggest appropriate phrasing to deal with this
situation, and I will update the IANA considerations section to
request the addition of AUTH_TLS.

In fact, such a change might enable the removal of "updates RFC
5531" and the problematic IPR boilerplate.

> 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 appear 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: 
>  
> I don't see how the details in 2.5 provides 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: 
> 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? 
>  
> 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 to be explicit about 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.

Good catch. Yes this text should call for DTLS 1.3 or later, if
DTLS 1.3 is nearing readiness. It might have been pretty distant
two years ago when I started authoring rpc-tls.

Please let me know of any additional commentary from the SEC AD.

> 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 cases 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 remove prior to publication, or do you intended to have this section included in the RFC? I do note that RFC 7942 do indicate removal of this section.

The XML source for this document contains this comment preceding the
Implementation Status section:

> <!-- RFC Editor:
> Please remove the following section and the reference to RFC 7942
> before this document is published.
> -->

I hope that is adequate.

> 10. Section 7: 
>  
> Privacy leakage due to STARTLS 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 enable tracking of client, or the user on the client? If there are 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 used.

The ALPN label is part of the TLS protocol. This might need a bit
of text to explain that context and refer the reader to the TLS
document that explains its usage. But maybe more is needed?

Maybe Lars E. can comment on what might be necessary in this
section.

> If it is to be used, then I think there need 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 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

I agree, it's missing. See above.

> 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 client 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 usage now. Then next step to require its usage.

Dave covered this in his e-mail reply earlier in this thread. What I
know is that, because rpc-tls is an RPC-layer document, we are
planning separate NFS-specific document(s) to address these issues,
as is appropriate to the more "cemented" status of those minor versions.

We should discuss this during our interim meeting. I will add it to
my slides.

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Apr 2020 15:28:21 +0000

Hi,

Please see inline.

On Wed, 2020-04-01 at 08:06 -0400, David Noveck wrote:
> 
> 
> On Wed, Apr 1, 2020, 4:27 AM Magnus Westerlund <
> magnus.westerlund=[email-masked]> wrote:
> > NFSv4 WG,
> >  
> > my comments. And as usual I am not an expert on NFS or RPC.
> > So don’t hesitate to push back or educate me with relevant context if what I
> > comment appears to be just strange.
> 

So RFC 4949 says the following: 

   $ privacy
      1. (I) The right of an entity (normally a person), acting in its
      own behalf, to determine the degree to which it will interact with
      its environment, including the degree to which the entity is
      willing to share its personal information with others. (See:
      HIPAA, personal information, Privacy Act of 1974. Compare:
      anonymity, data confidentiality.) [FP041]

      2. (O) "The right of individuals to control or influence what
      information related to them may be collected and stored and by
      whom and to whom that information may be disclosed." [I7498-2]

Shirey                       Informational                    [Page 232]
RFC 4949         Internet Security Glossary, Version 2       August 2007

      3. (D) Synonym for "data confidentiality".

      Deprecated Definition: IDOCs SHOULD NOT use this term as a synonym
      for "data confidentiality" or "data confidentiality service",
      which are different concepts. Privacy is a reason for security
      rather than a kind of security. For example, a system that stores
      personal data needs to protect the data to prevent harm,
      embarrassment, inconvenience, or unfairness to any person about
      whom data is maintained, and to protect the person's privacy. For
      that reason, the system may need to provide data confidentiality
      service.

      Tutorial: The term "privacy" is used for various separate but
      related concepts, including bodily privacy, territorial privacy,
      personal information privacy, and communication privacy. IDOCs are
      expected to address only communication privacy, which in this
      Glossary is defined primarily by "data confidentiality" and
      secondarily by "data integrity".

      IDOCs are not expected to address information privacy, but this
      Glossary provides definition 1 for that concept because personal
      information privacy is often confused with communication privacy.
      IDOCs are not expected to address bodily privacy or territorial
      privacy, and this Glossary does not define those concepts because
      they are not easily confused with communication privacy.

You also have to consider the threats from pervasive monitoring on privacy as
discussed in https://datatracker.ietf.org/doc/rfc7258/

> Not totally. A lot of it is embedded in existing hard-to-update documents.

Yes, but there are 14 mention of privacy in this document. These should be
possible to change to say either confidentiality or encrypted depending on what
is actually intended to be said. 

> > it has been assigned to the document.. In cases where one need a number for

So the above is what I recommend that the WG uses in the future. In this case,
add an IANA section and specifically request this to be assigned value 7 as that
has been used in the implementations. 

> implementations do about this issue.

So it appears some new text is required here then. 

> > mandate implementation support?
> 
> ideally one, document to look at to tell you what you have to do to implement
> a minor version.  This document defines an RPC-level facility and should not
> reach up the stack in that way. 

Ok, that is a good point. I think it can be part of an answer. I do see the
point, and likely we have to work threw the updates of RFC 5531 in this area. 

> I think we can figure out how to send a clearer signal.

Good!

> Maybe I'm getting upper and lower case mixed up but I don't see that you can
> reasonably update the specification of a particular minor version, in a way
> that defines a significant number of existing implementations as non-compliant 
> post facto.

I know that different groups have a  bit different views on how one consider
compliance when one have new RFCs that update old ones. From my perspective one
likely have to indicate the set of normative references + updates/replaced RFCs
for a particular compliance point. 

> 
> Adding  a new recommendation is different. Saying this "SHOULD" be implemented
> makes sense, as defined by RFC2119.  (Often "SHOULD" is used as a "MUST"
> without a whole lot of conviction. Sigh!).  In this context, the time to
> implement, test, and deploy support are valid reasons it might not be
> implemented but the text will need to explain clearly the unfortunate

When it comes to SHOULD, I think a good way to think of it is as an MUST, but
with escape clauses. And it is good to be explicit on the escape clauses that
are considered acceptable. 

> separately.  For encryption, If the client and server implement this, it will
> be used.  There is no need for two stages.  With regard to client

Agree that TLS for encryption without client authentication is still
opportunistic unless one have the policies and the methods for determining that
encryption SHALL be used. I think that requirement needs to come at that next
steps. 

> We will discuss this on 4/22 as part of the rfc5661bis effort.

Good, it is expected that the update will have a mandatory to implement and use
security solutions to achieve a modern expected security level. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 1 Apr 2020 16:07:32 +0000

Hi,

Please see inline.

On Wed, 2020-04-01 at 10:50 -0400, Chuck Lever wrote:
> > my comments. And as usual I am not an expert on NFS or RPC. So don’t

But RFC 5531 is published according to the TLP and BCP 78 so there are no need
to have that disclaimer if there is only material from that is included. 

> replace every last use of "privacy".

No, as I answered David I think the goal would be to move the usage of privacy
that is intended to have the meaing of confidentiality or even just encryption
should be changed. I would expect that there might still be privacy concerns due
to the STARTTLS procedure itself.

> 5531" and the problematic IPR boilerplate.

So I think the updates probably should stay due to that this documents updates
the security solution for RFC 5531. 

So I think the simple way forward is to simply just add the IANA request to
section 8.

NEW:

Section 8.2 Registration of AUTH_TLS 

This document registes a new entry in the RPC Authentication Flavor Numbers
registry, part of Remote Procedure Call (RPC) Authentication Numbers currently
residing at 
https://www.iana.org/assignments/rpc-authentication-numbers/rpc-authentication-numbers.xhtml#flavor

   Identifier String: AUTH_TLS

   Flavor Name: <none>

   Value: 7 

   Description: Authentication flavor used with RPC null operation 
                to determine support for RPC over TLS/TCP. 
   
   Reference: [RFCXXXX]

RFC-edtior note: Please replace RFCXXXX with the number given to this document.

> Please let me know of any additional commentary from the SEC AD.

Will do. 

> > before this document is published.

It likely is for the RFC-editor. It is the rest that don't see the comment. I
think you could convert the XML comment to a an RFC-editor note in the text. 

> > fails to discuss how this is to used.
> 

Please investigate this a bit, and if you need any help with contact to the
people that defined this and might have more direct recommendations, like Martin
Thomson or Eric Rescorla, please ping me. 

> 
> 
> > If it is to be used, then I think there need 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 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.
> >  
> We should discuss this during our interim meeting. I will add it to
Yes, lets take that in the other part of the thread. 

Cheers

Magnus Westerlund

---

From: Chuck Lever <[email-masked]>
Date: Sun, 5 Apr 2020 13:58:14 -0400

Going back to Magnus' original concern:

> Should this document actually update any or all of the versions of NFS 4 to mandate implementation support?

IMO the proper place to make fresh requirements on NFSv4 implementations is
in NFSv4-specific documents. I would rather not focus this document any more
on NFS than it already is. And we have a plan to author and publish one or
more NFSv4-specific documents regarding NFS-on-TLS (which will be covered
to some extent during our interim meeting).

So, I vote that this document should not update any NFSv4 standards-track
documents.

> 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.

Agreed, but practically speaking, the WG is not in control of
implementations.

With the rpc-tls proposal IMO we are trying to walk a very fine line
between limiting protocol changes for existing implementations and
meeting a critical security need. The opportunistic behavior of this
mechanism is a key part of this proposal. And the document describes
clearly ways that implementations can make the force the use of TLS.

In other words, I'm hoping rpc-tls provides an easy step forward
towards "support in as many places as possible".

> Thus, sending a clearer signal that NFS 4.x servers and client 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.

We've placed early versions of this document in front of members of the
IETF's Security Directorate. They immediately recognized that an
opportunistic tactic such as the one we propose in rpc-tls is a well-
understand and practical way to improve security of legacy protocols
such as NFS. I don't expect that they will object to the opportunistic
nature of the proposal.

However, more context (like a security strategy statement) could be
helpful. Dave was working on a document like that, but I don't know
what state is is currently in. I don't see it in the personal drafts
section of the nfsv4 document datatracker.

Alternately we could introduce some security-related text to the
WG's charter that outlines NFSv4 security strategy.

> 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 usage now. Then next…

That seems like jumping ahead of the gun. We have to get the new
mechanism out there first. Then a subsequent NFS-on-RPC-on-TLS I-D can
address the specifics of how NFSv4 will operate on TLS-protected
transports. As recent nfsv4@ threads show, there are crucial NFS-
specific details that need to be resolved before a requirement that
is practical for NFS implementations can be made.

IMO we are on a path towards requiring NFS with TLS. This document
is but the initial step.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Sun, 5 Apr 2020 20:32:26 -0400

> section of the nfsv4 document datatracker.

Due the press of other work, I now expect to submit an informational I-D
in May rather than in April.  As we will discuss on 4/22, this document
is intended for internal working group use and I don't expect it to be
published
as RFC

> IMO we are on a path towards requiring NFS with TLS.

I agree, but I think pc-tls needs to convey that the working group
shares  that opinion and intends to travw\erse that path, even
though, as you say, we are not in a position to impose
implementation requirements right now.

> This document is but the initial step.

s/but the/a crititical/

On Sun, Apr 5, 2020 at 1:58 PM Chuck Lever <[email-masked]> wrote:

> > 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 client 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.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 6 Apr 2020 13:08:10 +0000

Hi Chuck,

So this document is clearly an opportunistic mechanism. And I am not trying to
push things beyond this in this document. However, I need to understand the
answers to certain questions that are likely to arise in the IETF last call and
IESG evaluation. 

Thanks for clarifying that due to layering, it would be a bad idea for this
document to demand anything from NFS implementation. The NFS specificaiton
extension/updates will have to make such requirement. I am fine with conveying
that message to anyone raising this as an issue. 

Even on the RPC level, I do think the document can become clearer in that this
document's solution is strongly recommended to be implemented to improve
security. It is good that the document do dicsuss how policies can be
established to move this mechanism beyond just opportunistic. Hinting on the
likelihood that you will soon be required to support it. 

Thus, can one in introduce any RECOMMENDED/SHOULD writings on implementation of
this mechanism for RPC implementors? 

Second are there aspect of the non-normative text that can be improved? 

Cheers

Magnus

On Sun, 2020-04-05 at 13:58 -0400, Chuck Lever wrote:
> > 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.
> 
-- 
Cheers

Magnus Westerlund

---

From: Chuck Lever <[email-masked]>
Date: Tue, 7 Apr 2020 14:07:04 -0400

Hi Magnus -

> On Apr 6, 2020, at 9:08 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi Chuck,
> 

OK, glad we agree!

> this mechanism for RPC implementors?

One choice is Dave's proposed expansion to the Introduction, but the use of
compliance keywords is usually not appropriate in the Introduction. So it sounds
like you are asking for changes somewhere else in the document...

Perhaps Section 7.1 is the best place, as it directly addresses the shortcomings
of opportunistic security mechanisms.

> Second are there aspect of the non-normative text that can be improved?

Always. Is there a particular example that stands out to you?

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Thu, 9 Apr 2020 15:28:30 -0400

> 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 cases possibl…

There seems to be a high-order bit here that rpc-tls does not currently
address. Leaving it unaddressed could introduce significant
interoperability issues.

Our new STARTTLS RPC NULL probe carries an RPC program. Does a successful
probe mean that the RPC server supports TLS for every RPC program on that
that host? on that port? Or just for the program used in the probe? I think
it means TLS can be used only with the RPC program used in that probe,
and only for the lifetime of that connection. (ie each connection has to
do the probe).

Since the STARTTLS RPC NULL probe is always done in clear-text, that means
a second probe cannot be done once a TLS session has been established on
a connection. (A separate connection must be established to initiate a
second TLS session).

Therefore with RPC-on-TLS we do not allow multiple RPC programs to share
a TLS session. And we do not allow multiple RPC-on-TLS sessions per TCP
connection.

For DTLS, the STARTTLS probe has to be done for each RPC program on each
server. Only that one RPC program can use the established DTLS session.

This means RPC-on-TLS robs us of some TCP connection sharing opportunities.
Is there consensus on this, or should these design points be revisited?

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Thu, 9 Apr 2020 16:53:40 -0400

> a TLS session. And we do not allow multiple RPC-on-TLS sessions per TCP

That was my impression reading the document.  However, as you point out, the
document never clearly atated that.

> server. Only that one RPC program can use the established DTLS session.

OK with me.

> This means RPC-on-TLS robs us of some TCP connection sharing
opportunities.

I'm unaware of any actual use of these opportunities, in the absence of
RPC-TLS .  If there
is little use of these, than the deprivation of sharing opportunities is
purely formal.

> Is there consensus on this, or should these design points be revisited?

I'd prefer not but we need to give working group members who feel
differently, the
opportunity to raise their concerns.  if there is no objection, why don't
you include
explicit langusge about your non-sharing model in the next revision and the
working group discssion of the chamges in that document will serve as the
basis
for determining whether we have a continued onsensus on those point.

On Thu, Apr 9, 2020 at 3:28 PM Chuck Lever <[email-masked]> wrote:

> > 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 cases 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?
>

---

From: Chuck Lever <[email-masked]>
Date: Thu, 9 Apr 2020 17:02:05 -0400

> On Apr 9, 2020, at 4:53 PM, David Noveck <[email-masked]> wrote:
> 
> I'm unaware of any actual use of these opportunities, in the absence of RPC-TLS .  If there
> is little use of these, than the deprivation of sharing opportunities is purely formal.

The particular use case is that both the Linux and Solaris NFSv3
implementations use the same connection for NFS and NFSACL traffic,
which are two distinct RPC programs.

It's an ongoing concern for NFS clients that use privileged source
ports to conserve the number of connections they make to a
particular server.

Not a problem for NFSv4, or NFS with Kerberos which can use an
ephemeral source port without any consequences. We could probably
even stipulate in an NFS-on-TLS or NFS security document that an
NFS server should not require a privileged source port, but that's
a rat hole.

> I'd prefer not but we need to give working group members who feel differently, the
> opportunity to raise their concerns.

+1

> if there is no objection, why don't you include
> working group discssion of the chamges in that document will serve as the basis

Excellent suggestion, I will do that.

--
Chuck Lever

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 09 Apr 2020 17:42:04 -0400

> NFS server should not require a privileged source port, but that's

That's only OK if you can trust the client itself to enforce user
identities. The main reason for requiring the privileged port is to
ensure that the server is either talking to the kernel on the client,
or that it is talking to a privileged process. You don't normally want
to trust an unprivileged RPC client not to lie to you about AUTH_SYS
credentials...

I can't see that TLS changes that trust model unless the client also
authenticates to the server to prove it is running a trusted RPC
program.

> > opportunity to raise their concerns.

That proposal essentially bans the backchannel on NFSv4.x (which uses a
program number assigned by the client), so it is not acceptable.

Furthermore, as already pointed out, there are use cases for other
side-band protocols that share the same connection to the server as the
main protocol.

> Excellent suggestion, I will do that.

I object.

> > > 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 cases
> > > 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? 
> > 
-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email-masked]

---

From: Chuck Lever <[email-masked]>
Date: Thu, 9 Apr 2020 18:01:11 -0400

> On Apr 9, 2020, at 5:42 PM, Trond Myklebust <[email-masked]> wrote:
> 

> authenticates to the server to prove it is running a trusted RPC

So, does that mean in cases where TLS host authentication is used,
the server MAY ignore the client's source port?

> program number assigned by the client), so it is not acceptable.

As Dave said, what I described is what is already implied by or stated
in rpc-tls. It's possible that either rpc-tls or my understanding is
not correct.

I am open to alternative proposals or corrections to my understanding.
But do note that the situation has to be clarified as part of our
response to the AD review.

>> Excellent suggestion, I will do that.

To what? Do you mean that you would prefer we work this out here on the
mailing list rather than through the draft revision process? That's
fine with me too.

--
Chuck Lever

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 09 Apr 2020 18:51:52 -0400

On Thu, 2020-04-09 at 18:01 -0400, Chuck Lever wrote:
> > > > > Therefore with RPC-on-TLS we do not allow multiple RPC
> > > > > programs
> > > > > to share
> > > > > a TLS session. And we do not allow multiple RPC-on-TLS
> > > > > sessions
> > > > > per TCP
> > > > > connection.
> > > > 
> > > > That was my impression reading the document.  However, as you
> > > > point
> > > > out, the
> > > > > For DTLS, the STARTTLS probe has to be done for each RPC
> > > > > program
> > > > > on each
> > > > > server. Only that one RPC program can use the established
> > > > > DTLS
> > > > > session.
> > > > 
> > > > OK with me.
> > > > 

I'm saying that if I were the sysadmin, then the case where the client
identifies itself strongly is the only one where I would relax the
requirement on the source port.

> in rpc-tls. It's possible that either rpc-tls or my understanding is

I'm saying if that is how the protocol currently reads, then we've made
a mistake, and we need to correct it.

I don't see any reason why we need to add RPC layer restrictions when
we're effectively just adding a new underlying transport protocol. RPC
already has its own mechanisms for rejecting unsupported programs and
program versions.

What we might want to stipulate is that _if_ the server rejects your
program on the established channel, then that does not automatically
imply that it would also reject it on a different connection. However,
I'd first like to understand why it is desirable to treat TLS/DTLS
differently from ordinary TCP/UDP in that situation.

> > > > explicit langusge about your non-sharing model in the next
> > > > revision
> > > > and the
> > > > working group discssion of the chamges in that document will
> > > > serve
> > > > as the basis

I'd prefer that we work it out here. As I said, I consider this to be a
potential protocol error, if indeed the current text can be interpreted
in the suggested manner.

> 
> > > > On Thu, Apr 9, 2020 at 3:28 PM Chuck Lever <
> > > > [email-masked]>
> > > > wrote:
> > > > 
> > > > probe mean that the RPC server supports TLS for every RPC
> > > > program
> > > > on that
> > > > that host? on that port? Or just for the program used in the
> > > > probe?
> > > > I think
> > > > and only for the lifetime of that connection. (ie each
> > > > connection
> > > > has to
> > > > do the probe).
> > > > 
> > > > Therefore with RPC-on-TLS we do not allow multiple RPC programs
> > > > to
> > > > share
> > > > a TLS session. And we do not allow multiple RPC-on-TLS sessions
> > > > per
> > > > TCP
> > > > connection.
> > > > 
> > > > For DTLS, the STARTTLS probe has to be done for each RPC
> > > > program on
> > > > each

---

From: David Noveck <[email-masked]>
Date: Fri, 10 Apr 2020 08:40:28 -0400

On Thu, Apr 9, 2020, 3:28 PM Chuck Lever <[email-masked]> wrote:

> using DTLS over UDP?

It seems that that was Chuck's intention and was the way I have been
reading the spec.  However, it is not explicitly stated right now and does
need to be clarified as part of the response to Magnus's review.

> So having determined TLS support for TCP does not indicate the same for
> UDP?

I would hope not.   Ad a practical matter, there are many servers that
would not be all
interested in implementing DTLS, given that UDP is not allowed by NFSv4.
 Tying this
to TLS support would haveth effect of increasing the effort to provide
support without
correspondingly increasing the benefit.

Even though we cleary don't have consensus on the TCP-connection-sharing,
we might
well have consensus on this.

And is it in any cases possible to skip the initial RPC null request with
> AUTH_TLS authentication and go directly to negotiate TLS after support has
> rpc-tls does not discuss this a possibility.  On the other hand it does
not forbid it either.
Addressing this whole area is part of the needed clarification.

rpc-tls is written assuming opportunistic TLS access is the only means
of RPC-TLS  access but it never states that explicitly.  As a result,
Magnus,
quite reasonably, asks whether there are cases in which opportnistic acces
might be used as an information-gathering mechasnism to support non-
opportunistic TLS access.

> I don't think that's the high order bit but I agree it does need to be
resolved :-(

> Our new STARTTLS RPC NULL probe carries an RPC program.

It does.

> Does a successful

While I read things that way, I'm not committed to that reading.   Given
the lack
of consensus on that point, I want to understand how important that
reading is to you.

> I think that part is the high-order bit.   I'm hoping we might be able to
get
consensus on that since I feel that changing that might be more disruptive
than restrictions on the program used which run into the contentious
connection-sharing issue.

> a connection.

Right.

> (A separate connection must be established to initiate a
> second TLS session).
>

That's not made clear in rpc-rls but I hope that everyone is OK with that
being made explicit.

> a TLS session.

 What is the justification for the "therefore"?

Although we may reasonably conclude that a successful STARTTLS indicates
that you do may support for the specified program and version, I don't see
that
you are forced to conclude that no other program is supported.   I read it
that
way because the connection sharing case isn't important to me, but, since
it appears
that we can't reach consensus on that, we might want to consider
whether being
more relaxed on that point is a viable path forward.

And we do not allow multiple RPC-on-TLS sessions per TCP

> I hope we can achieve consensus on that.

> This means RPC-on-TLS robs us of some TCP connection sharing opportunities.

I don't feel robbed, but it appears some people do :-(

> Is there consensus on this,

I appears not.

> or should these design points be revisited?
>
> Not all of them,   I would hope we can disturb as few decisions already
made as possible.

---

From: Chuck Lever <[email-masked]>
Date: Fri, 10 Apr 2020 10:51:30 -0400

> On Apr 9, 2020, at 6:51 PM, Trond Myklebust <[email-masked]> wrote:
> 

I don't have a problem with that at all. IMO this should be clearly
mentioned somewhere in rpc-tls (which I can add if you agree).

> a mistake, and we need to correct it.

Exactly why I started this sub-thread: Correction could be necessary.
So, we're right on the same page.

> imply that it would also reject it on a different connection.

And/or:

rpc-tls should mandate a particular response if the client sends an
AUTH_TLS probe with an RPC program that the server does not recognize
on that port. Obvious choice is PROG_UNAVAIL -- and in this case, this
carries the additional meaning that the STARTTLS probe has failed.

I hope that is enough to imply that the client has a limited choice
of RPC program numbers to use in its AUTH_TLS probes.

Does rpc-tls need to explicitly state that the backchannel MUST NOT send
an AUTH_TLS probe on a connection with an established TLS session? It
is already implied by "no clear-text RPCs are allowed after a TLS
session is established". But perhaps it would be helpful implementation
guidance.

> However,

I agree that we should avoid unnecessary divergence in behavior. Let's

> 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 cases possibl…

The underlying question I read here is "after an AUTH_TLS probe, how
long can a client assume the RPC server supports RPC-on-TLS, and for
which RPC programs?"

Magnus' comment was made regarding UDP/DTLS, so my initial response was
that rpc-tls needs to stipulate how TLS sessions are used on transports

> server. Only that one RPC program can use the established DTLS session.

Then I started thinking about TCP.

Since we have implementations that use the same connection to transport
multiple RPC programs, we have to make a different statement. What should
that statement be?

I wondered again about whether it makes sense to permit or encourage
multiple TLS sessions on the same connection.

If you wanted to, how would you establish a second TLS session? Because
of the "no clear-text RPCs after a TLS session has been established"
stipulation, the client would have to perform a bunch of AUTH_TLS probes
_before_ sending any ClientHello messages.

(And in any event we probably want rpc-tls to discuss what should happen
if there is traffic on the connection between the AUTH_TLS probe and
the ClientHello message).

But it's likely that multiple TLS sessions makes sense only when there
are multiple certificates on the client side. So this is very likely
out of scope for rpc-tls. Then do we explicitly forbid the use of
multiple TLS sessions per connection for this iteration of RPC-on-TLS?

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Fri, 10 Apr 2020 11:00:20 -0400

> On Apr 10, 2020, at 8:40 AM, David Noveck <[email-masked]> wrote:
> 
> 
> 
> On Thu, Apr 9, 2020, 3:28 PM Chuck Lever <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On Apr 1, 2020, at 4:27 AM, Magnus Westerlund <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > 8. Section 5.1.2:
> >  
> >    As soon as a client
> > So first of all is the usage of TLS for TCP completely separate from using DTLS over UDP?
> 
> It seems that that was Chuck's intention and was the way I have been reading the spec.  However, it is not explicitly stated right now and does need to be clarified as part of the response to Magnus's review.
>    
> So having determined TLS support for TCP does not indicate the same for UDP?
> 
> I would hope not.   Ad a practical matter, there are many servers that would not be all
> interested in implementing DTLS, given that UDP is not allowed by NFSv4.   Tying this
> to TLS support would haveth effect of increasing the effort to provide support without
> Even though we cleary don't have consensus on the TCP-connection-sharing, we might
> And is it in any cases 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? 
> 
> rpc-tls does not discuss this a possibility.  On the other hand it does not forbid it either.
> of RPC-TLS  access but it never states that explicitly.  As a result, Magnus, 
> I don't think that's the high order bit but I agree it does need to be resolved :-(
>  
> While I read things that way, I'm not committed to that reading.   Given the lack

At this point I'm simply trying to align my understanding and the text in rpc-tls
with the WG's consensus. So, I'm not strongly advocating this interpretation.
Think of it, I guess, as a strawman.

> I think that part is the high-order bit.

Yes, probably so.

> I'm hoping we might be able to get 

IMO rpc-tls should be updated to make it clear.

However, it needs to be made clear in a way that does not preclude the
possibility of having multiple sessions per connection in a future RPC-on-TLS
iteration.

>  What is the justification for the "therefore"?

See my response to Trond: it was a thought experiment that reached this
conclusion.

> that you do may support for the specified program and version, I don't see that
> you are forced to conclude that no other program is supported.   I read it that
> way because the connection sharing case isn't important to me, but, since it appears
> that we can't reach consensus on that, we might want to consider whether being

Using the existing PROG_UNAVAIL accept status seems appropriate to enable
clients to work through this issue. I proposed some new text in my response to
Trond that leads in that direction.

> Not all of them,   I would hope we can disturb as few decisions already made as possible.

That is my hope too.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Fri, 10 Apr 2020 15:33:51 +0000

Chuck Lever wrote:
[stuff snipped]
>the ClientHello message).
I think that multiple AUTH_TLS probes before sending ClientHello
is both difficult to implement and confusing.

The AUTH_TLS probe serves two purposes well.
1 - It establishes whether or not RPC-over-TLS is supported by the server.
2 - If supported, it triggers a TLS handshake for the first session.

If you do want multiple TLS sessions on the same TCP connection (I'll assume TLS
allows this?), then I think a separate kind of AUTH_TLS Null RPC which is done
within a TLS session would be a more appropriate way to establish it.
(This one could have a non-NULL credential to differentiate it from the initial one.)

>multiple TLS sessions per connection for this iteration of RPC-on-TLS?
Yes, I would agree with this.

However, I do not see why multiple RPC programs cannot be allowed on
the same TCP connection using the same TLS session and I don't see that
the RPC program number used for the AUTH_TLS probe need imply
"only this program for this session".
Of course, this typically does not happen, since same TCP connection
implies same server port# and FreeBSD does not do this at this time.
So, as such, I really do not care whether or not a "only one RPC program
per TCP connection" restriction exists.

rick

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Fri, 10 Apr 2020 11:44:07 -0400

> On Apr 10, 2020, at 11:33 AM, Rick Macklem <[email-masked]> wrote:
> 
> Chuck Lever wrote:
> [stuff snipped]

That sounds about right.

> "only this program for this session".

Thanks Rick. I am tending to agree with this conclusion.

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 11 Apr 2020 19:37:16 -0700

> allows this?), then I think a separate kind of AUTH_TLS Null RPC which is done

TLS doesn't really allow this.  You could in theory make a TLS variant that
did it anyway, but you'd have to add a protocol field for a connection
identifier and/or do trial decryption on each TLS record, which doesn't
really make sense.

-Ben

---

From: Chuck Lever <[email-masked]>
Date: Sun, 12 Apr 2020 12:27:14 -0400

Hi Ben -

> On Apr 11, 2020, at 10:37 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> TLS doesn't really allow this.

I want to understand how to word the text in rpc-tls. "this" here means
"multiple TLS sessions on the same TCP connection" ? What happens when
the client peer sends a second ClientHello message on a connection with
an established TLS session? I haven't been able to find a firm description
of how a server is supposed to respond in this case.

> You could in theory make a TLS variant that

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 12 Apr 2020 09:32:38 -0700

> of how a server is supposed to respond in this case.

There's two possibilities that I see:

(1) the second ClientHello is unencrypted, in which case the server sees a
TLS record whose deprotection fails and aborts the connection

(2) the second ClientHello is encrypted with the current record-protection
keys, in which case a TLS 1.2 server starts the "renegotiation" process and
a TLS 1.3 server aborts the connection for a protocol violation.

TLS 1.2 renegotiation semantics are not particularly well specified, which
is part of why renegotiation was removed from TLS 1.3.  In particular, many
people will argue that that the "renegotiated" handshake would completely
replace the original one in a logical sense, so that only one client
authentication would be active (the latest one).  What is clear is that
only one cryptographic context would be active, so you could not interleave
TLS records on the TCP stream that are protected by different encryption
keys.

Does that help?

-Ben

---

From: Chuck Lever <[email-masked]>
Date: Sun, 12 Apr 2020 12:50:17 -0400

> On Apr 12, 2020, at 12:32 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Yes this explanation does help, thank you! rpc-tls requires the use of TLS
1.3 or later, so it needn't be concerned with the TLS 1.2 renegotiation
case at all.

The RPC-on-TLS protocol already assumed only a single TLS session per
connection. It will simplify the text, I think, that the multiple
session case, though not supported, is right off the table.

Within the next day or two I intend to post updated text for Sections 4.1
and 5.1, based on the conversation from the past few days, for review and
comment.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Mon, 13 Apr 2020 10:03:47 -0400

Hi Craig-

I don't know of a functional dependency, but someone who would know best
(perhaps a member of the IESG, I don't remember exactly whom) requested that
this document REQUIRE the known most secure version of TLS, which at present
is 1.3, to avoid certain known security exposures in 1.2 and enable the use
of token binding as an OPTIONAL means of peer authentication.

The requirement has been present since draft-ietf-nfsv4-rpc-tls-00 was
submitted a year ago, but is absent in the predecessor personal draft.

I believe RPC-on-TLS can be implemented on TLS 1.2. It won't be spec-compliant
in that case, and it won't be as secure.

> On Apr 12, 2020, at 6:30 PM, Craig Everhart <[email-masked]> wrote:
> 
> Is there a reason to require TLS 1.3?  TLS 1.2 isn’t old in many contexts.
> 
> Best,
> Craig
> 
> 
>> On Apr 12, 2020, at 12:52 PM, Chuck Lever <[email-masked]> wrote:
>> 
>> 
>> 

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Tue, 14 Apr 2020 11:39:36 -0400

> potential protocol error, if indeed the current text can be interpreted

To address AD review comments 6, 7, and 8, here's what I propose for
Section 4.1:

4.1.  Discovering Server-side TLS Support

   The mechanism described in the current document interoperates fully
   with RPC implementations that do not support TLS.  Depending on
   policy, the use of TLS is automatically disabled in these cases.

   To achieve this, we introduce a new RPC authentication flavor called
   AUTH_TLS.  This new flavor signals that the client wants to initiate
   TLS negotiation if the server supports it.  Except for the
   modifications described in this section, the RPC protocol is unaware
   of security encapsulation at the transport layer.

   When an RPC client is ready to begin a TLS session, it sends a NULL
   RPC procedure with an auth_flavor of AUTH_TLS.  The value of AUTH_TLS
   is defined in Section 8.1.  The NULL request is made to the same port
   as if TLS were not in use.

   The length of the opaque data constituting the credential sent in the
   RPC Call message MUST be zero.  The verifier accompanying the
   credential MUST be an AUTH_NONE verifier of length zero.

   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.

   If the RPC server replies with a reply_stat of MSG_ACCEPTED and an
   AUTH_NONE verifier containing the "STARTTLS" token, the RPC client
   follows with a "ClientHello" message.  The client MAY proceed with
   TLS session establishment even if the Reply's accept_stat is not
   SUCCESS (for example, if the accept_stat is PROG_UNAVAIL).  Once the
   TLS handshake is complete, the RPC client and server have established
   a secure channel for communicating.

   If the Reply's reply_stat is MSG_ACCEPTED but the verifier does not
   contain the "STARTTLS" token, or if the Reply's reply_stat is
   MSG_DENIED, the RPC client MUST NOT send a "ClientHello" message.
   RPC operation can continue, but in the clear.

   If, after a successful RPC AUTH_TLS probe, the subsequent TLS
   handshake should fail for any reason, the RPC client reports this
   failure to the upper-layer application the same way it reports an
   AUTH_ERROR rejection from the RPC server.

   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 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.

And for Section 5.1:

5.1.  Base Transport Considerations

5.1.1.  RPC-on-TLS Operation on TCP

   The use of TLS [RFC8446] protects RPC on TCP connections.  Typically,
   once an RPC client completes the TCP handshake, it uses the mechanism
   described in Section 4.1 to discover RPC-on-TLS support for that
   connection.  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.

   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.

   Once a TLS session is established on a TCP connection, no further
   clear-text communication can occur on that connection until the
   session is terminated.  When operation is complete, an RPC peer
   terminates a TLS session by sending a TLS Closure Alert and then
   closes the TCP connection.

   Furthermore:

   o  The use of TLS does not alter RPC record framing used on TCP
      transports.

   o  If an RPC server responds with PROG_UNAVAIL to an RPC Call within
      an established TLS session, that does not imply that RPC server
      will subsequently reject the same RPC program on a different TCP
      connection.

   o  If a client uses an ephemeral source port for a TCP connection and
      does not present authentication material to initiate TLS host
      authentication, the server MUST abort the TLS handshake with a
      handshake_failure alert.

   Backchannel operation occurs only on connected transports such as
   TCP.  To protect backchannel operations, an RPC server uses the
   existing TLS session on that connection to send backchannel
   operations.  The server does not attempt to establish a TLS session
   on a TCP connection for backchannel operation.

5.1.2.  RPC-on-TLS Operation on UDP

   RPC over UDP is protected using DTLS [I-D.ietf-tls-dtls13].  As soon
   as a client initializes a UDP socket for use with an unfamiliar
   server, it uses the mechanism described in Section 4.1 to discover
   DTLS support for an RPC program, and then negotiate a DTLS session
   for that program.  Connected operation is RECOMMENDED.

   Once an RPC client establishes a DTLS session for an RPC program, the
   RPC server MUST reject UDP-transported Calls in that RPC prgram from
   that RPC client that are not protected by the established DTLS
   session.

   Sending a TLS Closure Alert terminates a DTLS session.  Subsequent
   RPC messages exchanged between the RPC client and server are no
   longer protected until a new DTLS session is established.

   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.  Using DTLS does not
   introduce reliable or in-order semantics to RPC on UDP.  The use of
   DTLS record replay protection is REQUIRED.

5.1.3.  RPC-on-TLS Operation on Other Transports

   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.

   RPC-over-RDMA 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 be other provisions
   to exchange client and server certificates, authentication material
   exchange needs to be provided by facilities within a future RPC-over-
   RDMA transport protocol.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 14 Apr 2020 15:05:11 -0400

I think your updates are fundamentally right but I will suggest some
wording changes that
I hope will clarify things.

> policy, the use of TLS is automatically disabled in these cases.

First of all, if the server does not suport TLS, its use is disabled
regardless of
policy,  which is confusing.  "automatically" adds to the confusion.

Suggest the following replacement text:

The mechanism described in the current document is capable of
interoperating fully with RPC implementations that do not support
TLS.  Subject to client or ULP-mandated policy, the use of the connection
is continued without TLS protection or the connection is discarded in

such cases.

> RPC over UDP is protected using DTLS [I-D.ietf-tls-dtls13].  As soon as a
client initializes
> a UDP socket for use with an unfamiliar server.

As written, this raises the issue of a UDP connection on a server that one
is familiar with.  I
think your intention is that clients always do the same thing so I suggest
changing "an
unfamiliar" to "a".

---

From: Chuck Lever <[email-masked]>
Date: Tue, 14 Apr 2020 16:51:27 -0400

> On Apr 14, 2020, at 3:05 PM, David Noveck <[email-masked]> wrote:
> 
> I think your updates are fundamentally right but I will suggest some wording changes that
> First of all, if the server does not suport TLS, its use is disabled regardless of

This section applies to TCP (connected) and UDP (connectionless) operation, thus
stating that "the use of the connection is continued ... or ... is discarded" is out of place
here. I'll try to adjust the second sentence.

> > RPC over UDP is protected using DTLS [I-D.ietf-tls-dtls13].  As soon as a client initializes 
> As written, this raises the issue of a UDP connection on a server that one is familiar with.  I 
> think your intention is that clients always do the same thing so I suggest changing "an 
> unfamiliar" to "a".

Fixed.

> On Tue, Apr 14, 2020 at 11:39 AM Chuck Lever <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On Apr 9, 2020, at 6:51 PM, Trond Myklebust <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> >>> On Apr 9, 2020, at 5:42 PM, Trond Myklebust <[email-masked] <mailto:[email-masked]>>
> >>> wrote:
> >>> 
> >>>>> On Apr 9, 2020, at 4:53 PM, David Noveck <[email-masked] <mailto:[email-masked]>>
> >>>>> wrote:
> >>>>> 
> >>>>> [email-masked] <mailto:[email-masked]>>
> >>>>> wrote:
> >>>>> 
> >>>>>> On Apr 1, 2020, at 4:27 AM, Magnus Westerlund <
> >>>>>> [email-masked] <mailto:[email-masked]>> wrote:
> >>>>>> 
> >>>>>> 8. Section 5.1.2:
> >>>>>> 
> >>>>>>  As soon as a client
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 Apr 2020 20:30:12 +0000

Hi, 

I have reviewed the text proposal and have this comment. 

>       authentication, the server MUST abort the TLS handshake with a

So what is this paragraph trying to say really. Is this a mix of OS/Socket level
concerns with the transport protocol level. Becasue from my perspective, I don't
see why it would matter if the NFS client use a single arbitrary source port for
its TCP connection to the server, where it determines that it has reached the
server with a requested SNI. After the TCP connection has been established it
will have a specific 5-tuple. Then the client use RPC level authentication to
prove to the server which user it is. Yes, that has certain weakness in that it
doesn't identify the client host system, however for cases where one don't
require that.  

So related to my AD reveiw comment:

> 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?

For TCP I think the new text addresses this to simply stating the fact that once
the TLS connection is established over the TCP connection it is impossible to
use it in an non-secured way. 

However, for UDP I think an aspect of this question remains. 

>    that RPC client that are not protected by the established DTLS

Is this on a per 5-tuple level? Can you make that explicit. If not can you
please specify in which way the server will make the deterination that they
should be in some other 5-tuple an the associated DTLS association? 

My understanding of DTSL is that over UDP for incoming packets it will look at
the 5-tuple, The destination port for which DTLS server/client that receives the
packet. And the source port + address for determining security context. After an
DTLS association has been created on a 5-tuple incoming UDP datagram payloads
needs to contain either DTLSplaintext or DTLS cipher text (see Section 4.1 of 
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/). If it doesn't match or
succesfully deprotects then the paylaod is rejected. Thus it will not be on the
same 5-tuple possible to receive any unprotected datagrams.

For issue 7, this fully addresses that one.

For issue 8. I think it is clear that you need to do the RPC call to find out
support and that is scoped to the transport protocol and 5-tuple the request was
done to. That is all fine with me. So issue resolved.  

Cheers

Magnus Westerlund

---

From: Chuck Lever <[email-masked]>
Date: Thu, 16 Apr 2020 16:49:00 -0400

> On Apr 16, 2020, at 4:30 PM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi, 
> 
> concerns with the transport protocol level.

NFS server implementations have traditionally required clients to use a
privileged source port when using weak authentication like AUTH_SYS.
When a client uses a flavor like krb5 that provides strong host
authentication, the privileged source port requirement is waived.

This bullet simply states that the server does not have to require a
privileged source port when using TLS, just like with krb5/i/p. So
a client using AUTH_SYS with TLS would be permitted to use an ephemeral
source port, which is a much less rare resource than a privileged source
port.

We could leave this statement for a subsequent NFS-specific document
but there are some non-NFS user space RPC implementations that have
the same requirement.

Or, I could move this bullet to the Security Considerations section.

> Becasue from my perspective, I don't

Sure. I will try to make this more specific. I'll propose something in a
day or two.

> done to. That is all fine with me. So issue resolved.

Thanks for your review. I think the clarifications you requested make this a
stronger document.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Thu, 16 Apr 2020 17:31:08 -0400

Following up -

> Is there a reason to require TLS 1.3?  TLS 1.2 isn’t old in many contexts.

My impression is that there are well-known security exposures with earlier versions of TLS and DTLS. Therefore new protocol specifications need to cite 1.3. I understood it to be a best security practice for protocol specifications to avoid enabling the consumption of known-to-be-insecure building blocks. I don't regard the TLS 1.3 requirement as any different from requiring SHA-256 instead of less secure ciphers.

rpc-tls has had two early SecDir reviews already, and there was no complaint about the TLS 1.3 requirement from those reviews. The one AD review comment relevant to this issue was that there should be a similar version requirement for DTLS, and so the next revision of rpc-tls will require DTLS 1.3 as well.

For those following at home, the text in question is this:

5.  TLS Requirements

  When peers negotiate a TLS session that is to transport RPC, the
  following restrictions apply:

  o  Implementations MUST NOT negotiate TLS versions prior to v1.3
     ([RFC8446] or [I-D.ietf-tls-dtls13]).  Support for mandatory-to-
     implement ciphersuites for the negotiated TLS version is REQUIRED.

How do others feel about this? Is the use of a current version of TLS merely an implementation quality issue? How have specifications of other upper layer consumers of TLS dealt with this issue?

My inclination, because we are already well-past WGLC for rpc-tls, is leave it to the IESG to adjudicate this issue.

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 16 Apr 2020 15:11:56 -0700

> My inclination, because we are already well-past WGLC for rpc-tls, is leave it to the IESG to adjudicate this issue.

FWIW, SAAG seems to have found a consensus position that at this point new
protocols should assume 1.3 or newer.  A properly configured TLS 1.2 is not
known to be broken (and thus probably okay to allow for existing
protocols), but improper configurations of TLS 1.2 have significant
weaknesses.  So sticking with 1.3 is quick and easy and gets to a
known-secure baseline (and, if I might add, a well-designed protocol that
benefitted from extensive review and formal analysis during its
development).

In short, I expect the text in question to sail through the IESG.

-Ben

---

From: David Noveck <[email-masked]>
Date: Thu, 16 Apr 2020 19:10:11 -0400

> concerns with the transport protocol level.

Unfortunately, it is. There are good reasons for it, that derive from the
history of NFS "authentication".

> prove to the server which user it is.

That's a reasonable perspective.  Unfortunately, it doesn't take account of
AUTH_SYS in which the authentication task is effectively delegated to the
client. In that case, knowing who the client is essential. Without that,
there is really no request authentication.

Yes, that has certain weakness in that it
> doesn't identify the client host system, however for cases where one don't

I suppose one could allow use of rpcsecgss and only restrict use of
AUTH_SYS on such connections.  However, I think Chuck's statement makes
things simpler on that it requires either that the source kernel take
responsibility for the client, be allowing use of a privileged port or the
client provides
authentication material to support unprivileged clients.

NFSV4 might choose to go further to deal with the possibility of untrusted
kernels.

---

From: Chuck Lever <[email-masked]>
Date: Fri, 17 Apr 2020 08:32:12 -0400

> On Apr 16, 2020, at 4:49 PM, Chuck Lever <[email-masked]> wrote:
> 
> 
> 

The mind wandered last night, and I realized that the privileged port
requirement applies in the connectionless case as well. I will move
this text somewhere that is appropriate for both transport types.

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Apr 2020 17:07:35 +0000

> this text somewhere that is appropriate for both transport types.

I think it is fine to include. Howver, I was missing context for this. So I
think if you provide slightly more context to the statement it will avoid
confusion from the future reviewers. 
 
Cheers

Magnus Westerlund

---

From: Chuck Lever <[email-masked]>
Date: Sun, 19 Apr 2020 11:40:37 -0400

Hi Magnus-

> doesn't identify the client host system, however for cases where one don't

I've concluded that because...

• It is widely recognized these days that the source port is no realistic
indication of any degree of authority on the client,
• The new requirement was proposed well after the end of WGLC for rpc-tls,
• The use of a privileged port is discussed in RFC 5531 as implementation
guidance, not as a normative requirement,
• There seems to be an ongoing lack of consensus about what exactly should be
said,

... I will drop this new text entirely.

Dave Noveck pointed out to me that Appendix A of rpc-tls already quotes the
final paragraph of RFC 5531 Appendix A, which suggested the use of the source
port.

IMHO Appendix A of rpc-tls really ought to make some kind of statement about
how weak it is to use the client's source port, as the purpose of the source
port test is to mitigate the weaknesses of AUTH_SYS that are discussed in that
section. However, given how late it is, I leave that discussion to subsequent
documents. The source port test can remain an implementation quality issue for
the time being.

> same 5-tuple possible to receive any unprotected datagrams.

I've tried to resolve this issue in the following ways:

- I've removed the problematic rejection requirement.
- I've introduced discussion of the use of a CID or 5-tuple to identify the
participating endpoints.

Here's the new text:

   RPC over UDP is protected using the Datagram Transport Layer Security
   (DTLS) protocol [I-D.ietf-tls-dtls13].

   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
   replay protection is REQUIRED when transporting RPC traffic.

   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.

   When using connectionless operation, each DTLS session endpoint is
   identified by its 5-tuple -- the source and destination IP address
   and port numbers, along with the UDP transport protocol number (17).
   When using connected operation, the DTLS session endpoints are
   identified by connection ID (CID), as described in
   [I-D.ietf-tls-dtls-connection-id].  Connected operation is strongly
   RECOMMENDED.

If this text is still inadequate, I can reach out to the authors of
I-D.ietf-tls-dtls-connection-id for further guidance.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Mon, 20 Apr 2020 05:51:11 -0400

> final paragraph of RFC 5531 Appendix A, which suggested the use of the

Actually, I didn't.  I got to Appendix A of 5531 directly, trying to
understand the current role of AUTH_SYS for my slides Wednesday.

> documents. The source port test can remain an implementation quality issue

I agree but think we could non-controversially draw attention to the
wealnesses of the existing approach by adding "(I.e. without
transport-level encryption or client authentication)" after "by itself".  I
think that is the kind of clarification that is reasonable even at this
late stage.

Ultimately this will need to be addressed by describing how the
authentication material provided by the client is to be used. I had been
thinking that would be done in NFSV4-specific documents but it might be
possible/necessary to do some of this at the RPC level, given what RFC 5531
already says

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 20 Apr 2020 08:45:38 -0400

On Mon, 2020-04-20 at 05:51 -0400, David Noveck wrote:
> > .... I will drop this new text entirely.
> > 
> > 
> > 
> transport-level encryption or client authentication)" after "by
> itself".  I think that is the kind of clarification that is
> reasonable even at this late stage.

Transport level encryption is not an indicator that this is a trusted
client, only that the transport itself is secure; I could still have
your server see a fudged client IP+port number (e.g. by routing through
a NAT).Client authentication is really the only way to ascertain that
the client is indeed the trusted entity without adding another layer of
strong authentication on top of TLS.
In short: I'd prefer dropping the 'transport-level encryption or' bit
in your proposal and just leave it as "(I.e. without client
authentication)".
> authentication material provided by the client is to be used. I had
> been thinking that would be done in NFSV4-specific documents but it
> might be possible/necessary to do some of this at the RPC level,
> given what RFC 5531 already says
> 
> 
> > --
> > 
> > Chuck Lever
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> _______________________________________________nfsv4 mailing 
> [email-masked]

---

From: Chuck Lever <[email-masked]>
Date: Mon, 20 Apr 2020 09:47:34 -0400

> On Apr 20, 2020, at 8:45 AM, Trond Myklebust <[email-masked]> wrote:
> 
>> Actually, I didn't.  I got to Appendix A of 5531 directly, trying to understand the current role of AUTH_SYS for my slides Wednesday.
>> 
>>> 
>> I agree but think we could non-controversially draw attention to the wealnesses of the existing approach by adding "(I.e. without transport-level encryption or client authentication)" after "by itself".  I think that is the kind of clarification that is reasonable even at this late stage.
> 
> Transport level encryption is not an indicator that this is a trusted client, only that the transport itself is secure; I could still have your server see a fudged client IP+port number (e.g. by routing through a NAT).
> Client authentication is really the only way to ascertain that the client is indeed the trusted entity without adding another layer of strong authentication on top of TLS.
> 
> In short: I'd prefer dropping the 'transport-level encryption or' bit in your proposal and just leave it as "(I.e. without client authentication)".

Here's how the middle section of Appendix A reads after this addition:

   Appendix A of [RFC5531] contains a brief explanation of security
   considerations:

      It should be noted that use of this flavor of authentication does
      not guarantee any security for the users or providers of a
      service, in itself.  The authentication provided by this scheme
      can be considered legitimate only when applications using this
      scheme and the network can be secured externally, and privileged
      transport addresses are used for the communicating end-points (an
      example of this is the use of privileged TCP/UDP ports in UNIX
      systems -- note that not all systems enforce privileged transport
      address mechanisms).

   It should be clear, therefore, that AUTH_SYS by itself (i.e., without
   strong client authentication) offers little to no communication
   security:

>> Ultimately this will need to be addressed by describing how the authentication material provided by the client is to be used. I had been thinking that would be done in NFSV4-specific documents but it might be possible/necessary to do some of this at the RPC level, given what RFC 5531 already says
>> 
>> 
>>> 
>>> --
>>> Chuck Lever
>>> 
>>> 
>>> 

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Apr 2020 07:46:25 +0000

Hi,

See inline. 

> documents. The source port test can remain an implementation quality issue for

Okay, I think that is fine. 

> > > reading

I think this is clear. I don't think I can provide better guidance. I think we
will get feedback on this when we go to IETF last call if it is insufficient. 

I hope the WG memeber can also check this also. 

Cheers

Magnus Westerlund

---

From: Chuck Lever <[email-masked]>
Date: Tue, 21 Apr 2020 11:15:25 -0400

> On Apr 21, 2020, at 3:46 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 
> See inline. 
> 

Thanks, Magnus.

I've pushed all of these updates to the rpc-tls github repo:

Editor's copy: https://chucklever.github.io/i-d-rpc-tls/draft-ietf-nfsv4-rpc-tls.html

rfcdiff with -06: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-nfsv4-rpc-tls.txt&url2=https://chucklever.github.io/i-d-rpc-tls/draft-ietf-nfsv4-rpc-tls.txt

Commit log with individual changes: https://github.com/chucklever/i-d-rpc-tls/commits/master

Dave has added a 10-minute slot to tomorrow's meeting for a final walk through
to discuss any remaining open controversies before I submit -07. Everyone,
please review the material at the above links so we can have firm closure on
this review process.

Thanks for everyone's time!

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Apr 2020 15:57:28 +0000

Hi,

I have reviewed the diff for the editor's copy and have the below comments. 
Only E I think needs any more significant consideration. My evaluation is that 
all my previous AD comments has been resolved or answered. Thanks for the 
work.

A. Section 4.1:

I would propose that this sentence is reformulated to make it even more 
evident that there are no security protection.

NEW:

RPC operation can continue, however it will be without any confidentiality, 
integrity or authentication protection from (D)TLS.

B. Section 4.2.1:

RPCSEC GSS can also protect per-request integrity or confidentiality.

I think the language is botched here. I guess something like this was 
intended:

NEW: RPCSEC GSS can also perform per-request integrity or confidentiality 
protection.

C. Section 5.

Implementations MUST NOT negotiate TLS versions prior to v1.3 ([RFC8446] or 
[I-D.ietf-tls-dtls13]).

I think it need to be more explicit about that the second reference is DTLS 
1.3. Propose

Implementations MUST NOT negotiate TLS versions prior to v1.3 (for TLS 
[RFC8446] or DTLS [I-D.ietf-tls-dtls13] respectively).

D. Section 5.:

Client implementations MUST include the 
"application_layer_protocol_negotiation(16)" extension in their "ClientHello" 
message and MUST include the protocol identifier defined in Section 8.2 in 
that message's ProtocolNameList value.

I propose to include an reference here to what the 
"application_layer_protocol_negotiation(16)" is. So proposed wording:

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.

Likely it makes sense to make a similar change to the next sentence to:

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.

E. Section 5.1.2:

When using connectionless operation, each DTLS session endpoint is identified 
by its 5-tuple -- the source and destination IP address and port numbers, 
along with the UDP transport protocol number (17). When using connected 
operation, the DTLS session endpoints are identified by connection ID (CID), 
as described in [I-D.ietf-tls-dtls-connection-id]. Connected operation is 
strongly RECOMMENDED.

So I don't know if I looked to quickly at DTLS 1.3 and the dtls-connection-id 
draft. However, I don't see any discussion of a connectionless operation. This 
might be a terminology issue primarily. However, my understanding which might 
be flawed are that the DTLS connection is created by the DTLS handshake. That 
DTLS connection can either be identified by the 5-tuple or use this CID 
extension.

The primary goal of the CID extension is to avoid need for a new DTLS 
handshake and creating a new DTLS connection if the 5-tuple changes, for 
example due to NAT port rebinding.

In addition my understanding is that [I-D.ietf-tls-dtls-connection-id] is 
defining the extension for CID for DTLS 1.2. Section 9 in the DTLS1.3 
specification imports that extension into DTSL 1.3. Thus, if you want to 
recommend its usage it might be better to point to Section 9 and only use 
[I-D.ietf-tls-dtls-connection-id] informationally.

Cheers

Magnus

---

From: Chuck Lever <[email-masked]>
Date: Wed, 22 Apr 2020 12:08:51 -0400

> On Apr 22, 2020, at 11:57 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 

Your proposed changes look sensible to me. I'll see to applying them after
today's meeting.

> [I-D.ietf-tls-dtls-connection-id] informationally.

Yes, I noticed that connection-id refers specifically to DTLS 1.2, but
assumed (erroneously) that it would also apply to DTLS 1.3. I didn't
think to look that the CID extension was already integrated into tls-dtls13.

I'll check into this further. It might be fine to simply drop the reference
to connection-id, replacing it as you suggest above.

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Apr 2020 17:50:06 +0000

Hi,

Regarding this last issue.

On Wed, 2020-04-22 at 12:08 -0400, Chuck Lever wrote:
> > identified 

I think the reference is rather simple to deal with. I think the real question
is if it is motivated to recommend using CID or not. There is after all an
overhead. And please remember that the first part of the CID value either needs
to map to differnet lengths or a server proxy us a single length. So for a
server UDP port that is used by many clients will have a large enough CID length
to avoid a lack. Thus the CID likley are 4+ bytes. And describe that in a way
that will not be missunderstood. 

But lets discuss this in today's interim meeting. 
 
Cheers

Magnus Westerlund

---

From: Chuck Lever <[email-masked]>
Date: Wed, 22 Apr 2020 15:49:40 -0400

> On Apr 22, 2020, at 1:50 PM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 

After reviewing Section 9 of tls-dtls37, IMO:

- the explicit reference to tls-dtls-connection-id can be removed
- the discussion of connectionless operation should be dropped
- the strong RECOMMENDATION to use connected operation should be dropped
- rpc-tls should REQUIRE the use of the CID extension for RPC-on-DTLS
- rpc-tls should provide implementation guidance to RPC server implementers
to use large CIDs for popular RPC services.

Does that sound right? If so I will propose replacement text here on list.

The other editorial items have already been fixed and pushed to github.

Tigran mentioned in the interim meeting chat room that the DESY RPC-on-TLS
implementation does indeed support DTLS. rpc-tls Section 6 needs to be
updated to reflect that. I've asked him for a pull request to take care of
it.

After that, I will submit a fresh revision.

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Apr 2020 07:27:52 +0000

Hi,

With the additional 

> - rpc-tls should REQUIRE the use of the CID extension for RPC-on-DTLS

To try to clarify this REQUIRE a bit. I think what you mean is that the proposal
is: It is mandatory to implement CID. Which implies that client include the CID
extension in the handshake. However if that indicates a CID non-zero value, or a
zero-length value indicating support but no desire to use it in server to client
direction is up to the client. Simular it will be up to the server to actually
use it. 

> Does that sound right? If so I will propose replacement text here on list.

I think it sounds okay. 

/Magnus

-- 
Cheers

Magnus Westerlund

---

From: Chuck Lever <[email-masked]>
Date: Thu, 23 Apr 2020 11:48:59 -0400

> On Apr 23, 2020, at 3:27 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 
> With the additional 
> 

For completion, here is the current text of Section 5.1.2:

5.1.2.  Protected Operation on UDP

   For RPC-on-DTLS, each DTLS handshake MUST include the connection_id
   extension described in Section 9 of [I-D.ietf-tls-dtls13].  RPC-on-
   DTLS peer endpoints SHOULD provide a ConnectionID with a non-zero
   length.  Endpoints implementing RPC programs that expect a
   significant number of concurrent clients should employ ConnectionIDs
   of at least 4 bytes in length.

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Apr 2020 08:47:57 +0000

Hi,

I think that text works. However, that now recommends using a non-zero
connection ID. From my perspective which have no implementation stake into this,
this is fine. However, I would note that this backtracks on what was said just a
few messages ago. 

I think other WG paricipants should provide input here. 

Cheers

Magnus 

-- 
Cheers

Magnus Westerlund

---

From: Chuck Lever <[email-masked]>
Date: Mon, 27 Apr 2020 10:19:24 -0400

Hi Magnus-

> On Apr 27, 2020, at 4:47 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 

It's always possible I've gotten something wrong. However, I realized that RPC
on UDP permits an RPC server to use a different network path to send a Reply
than the path the client used to send the matching Call. IIUC a substantial CID
is needed to deal correctly with that situation.

> I think other WG paricipants should provide input here.

I agree, comments welcome.

--
Chuck Lever

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 27 Apr 2020 11:11:14 -0400

> is needed to deal correctly with that situation.
I don't think that matters. The server should always authenticate to the
client during the D/TLS handshake, so there should be no ambiguity about
the source of the replies.

> >>> is: It is mandatory to implement CID. Which implies that client
> include the
> >>> CID
> >>> extension in the handshake. However if that indicates a CID non-zero
> value,
> >>> or a
> >>> zero-length value indicating support but no desire to use it in server
> to
> >>> client

---

From: Chuck Lever <[email-masked]>
Date: Mon, 27 Apr 2020 11:45:25 -0400

> On Apr 27, 2020, at 11:11 AM, Trond Myklebust <[email-masked]> wrote:
> 
> 
> 
> I don't think that matters. The server should always authenticate to the client during the D/TLS handshake, so there should be no ambiguity about the source of the replies.

The server is free to reply via any of its network interfaces. In other
words, it can perform the handshake using one 5-tuple, then send replies
via another (or send them via a mix of 5-tuples).

A CID is needed to handle NAT rebinding in any case. But IIUC rebinding
would look like the client's 5-tuple changing, not the server's.

The question in mind is whether a DTLS session will be perturbed by the
server's or client's 5-tuple changing. Magnus, can you elaborate on your
earlier request for a clear statement about this in this section? Is this
no longer a concern now that the REQUIREMENT to drop an out-of-session
RPC Call?

Also, I'm not certain if SHOULD is correct here. Instead, "should" or
"MUST" might be less ambiguous. However, if we all agree the statement is
totally unnecessary, it can be replaced or dropped.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Mon, 27 Apr 2020 11:56:11 -0400

Sorry, I'm not sure how Magnus got dropped.

> On Apr 27, 2020, at 11:45 AM, Chuck Lever <[email-masked]> wrote:
> 

"to drop an out-of-session RPC Call has been removed from this section?"

--
Chuck Lever

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 27 Apr 2020 16:37:47 -0400

> totally unnecessary, it can be replaced or dropped.
I'm saying that it doesn't matter from what network interface, or indeed
which breed of carrier pigeon the server chooses, The client can still
authenticate the reply as being genuine from the fact that the server
authenticated to it at the start of the DTLS session. As long as this is
still the same session, then the client can ignore any changes to the
network topology.

> > >>> To try to clarify this REQUIRE a bit. I think what you mean is that
> the
> > >>> proposal
> > >>> zero-length value indicating support but no desire to use it in
> server to
> > >>> client

---

From: Chuck Lever <[email-masked]>
Date: Mon, 27 Apr 2020 17:02:27 -0400

> On Apr 27, 2020, at 4:37 PM, Trond Myklebust <[email-masked]> wrote:
> 
> 
> 
> I'm saying that it doesn't matter from what network interface, or indeed which breed of carrier pigeon the server chooses, The client can still authenticate the reply as being genuine from the fact that the server authenticated to it at the start of the DTLS session. As long as this is still the same session, then the client can ignore any changes to the network topology.

My reading of draft-ietf-tls-dtls-connection-id suggests that is not
the case for DTLS 1.2 and later.

Abstract says:

   A CID is an identifier carried in the record layer header that gives
   the recipient additional information for selecting the appropriate
   security association.  In "classical" DTLS, selecting a security
   association of an incoming DTLS record is accomplished with the help
   of the 5-tuple.  If the source IP address and/or source port changes
   during the lifetime of an ongoing DTLS session then the receiver will
   be unable to locate the correct security context.

Further, the Introduction states:

   In the current version of DTLS, the IP address and port of the peer
   are used to identify the DTLS association.  Unfortunately, in some
   cases, such as NAT rebinding, these values are insufficient.  This is
   a particular issue in the Internet of Things when devices enter
   extended sleep periods to increase their battery lifetime.  The NAT
   rebinding leads to connection failure, with the resulting cost of a
   new handshake.

Unless I'm reading this wrong, if either peer sees a DTLS datagram from
a different IP address than was used during the DTLS handshake, it's not
going to be able to associate that with a previously established DTLS
session... unless there's a CID.

The DTLS handshake and the subsequent DTLS record exchanges are two
separate protocols. The CID is exactly the material that the peers need
to determine that the remote sender is the same peer that established
that DTLS session.

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Apr 2020 11:23:10 +0000

> to determine that the remote sender is the same peer that established

Exactly, my understanding was that DTLS without connection IDs uses the 5-tuple
and that needs to be reversed when replying. This is also definitely true in
environments with NATs and Firewalls to hit the stateful pinholes. I understand
that this is not the case in DC deployments. 

If it is common for RPC over UDP to not use reversed 5-tuples then I think using
non-zero CIDs is a requirement. I think you should write that little motivation
into the text to make people aware that this may not be the environment that
people from outside of NFSv4 are used to. Because that clearly surprises me. 

Cheers

Magnus Westerlund

---

From: <[email-masked]>
Date: Tue, 28 Apr 2020 12:54:07 +0000

-----Original Message-----
From: nfsv4 <[email-masked]> On Behalf Of Chuck Lever
Sent: Monday, April 27, 2020 5:02 PM
To: Trond Myklebust
Cc: [email-masked]
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

[EXTERNAL EMAIL] 

>> > > I think that text works. However, that now recommends using a 
>> > > non-zero connection ID. From my perspective which have no 
>> > > implementation stake into this, this is fine. However, I would 
>> > > note that this backtracks on what was said just a few messages ago.
>> > 
>> > It's always possible I've gotten something wrong. However, I 
>> > realized that RPC on UDP permits an RPC server to use a different 
>> > network path to send a Reply than the path the client used to send 
>> > the matching Call. IIUC a substantial CID is needed to deal correctly with that situation.
>> > 
>> > 
>> The server is free to reply via any of its network interfaces. In 
>> other words, it can perform the handshake using one 5-tuple, then 
>> send replies via another (or send them via a mix of 5-tuples).
>> 
>> A CID is needed to handle NAT rebinding in any case. But IIUC 
>> rebinding would look like the client's 5-tuple changing, not the server's.
>> 
>> The question in mind is whether a DTLS session will be perturbed by 
>> the server's or client's 5-tuple changing. Magnus, can you elaborate 
>> on your earlier request for a clear statement about this in this 
>> section? Is this no longer a concern now that the REQUIREMENT to drop 
>> an out-of-session RPC Call?
>> 
>> 
>> "MUST" might be less ambiguous. However, if we all agree the 
>> statement is totally unnecessary, it can be replaced or dropped.
>> 
> 

My reading of draft-ietf-tls-dtls-connection-id suggests that is not the case for DTLS 1.2 and later.

Abstract says:

Unless I'm reading this wrong, if either peer sees a DTLS datagram from a different IP address than was used during the DTLS handshake, it's not going to be able to associate that with a previously established DTLS session... unless there's a CID.

The DTLS handshake and the subsequent DTLS record exchanges are two separate protocols. The CID is exactly the material that the peers need to determine that the remote sender is the same peer that established that DTLS session.

[sf] I reviewed the latest draft and I have some questions and concerns related to section 7.2 it is defined the TLS management on clients:
"The RPC-on-TLS protocol by itself cannot protect against exposure of a user's RPC requests to
other users on the same client.
Moreover, client implementations are free to transmit RPC requests
for more than one RPC user using the same TLS session. Depending on
the details of the client RPC implementation, this means that the
client's TLS identity material is potentially visible to every RPC
user that shares a TLS session."

I see two issues with this:
1.	If there is a compromised user running on same client it is possible that the compromised user can "see" the identity material of the legitimate users.
2.	It is possible that a compromised user initiate a DDoS attack on the server and the server will not detect the attack as it comes from a legitimate host and encrypted. This may expose a server to undetected DDoS attacks.

Also the question is do we allow a mix of users using TLS and others not using TLS on same client? I understand that we don't support multiple TLS on same connection but do we support a mix? Some explanation/clarification text will be useful.

./Sorin
--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Tue, 28 Apr 2020 10:42:07 -0400

> On Apr 28, 2020, at 7:23 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> non-zero CIDs is a requirement.

It is not common, but it is not forbidden. In the field there have been
implementations that, when deployed on multi-homed hosts, do send Replies
via a different network path than the one on which Calls arrived.

> I think you should write that little motivation

Well, NFSv4 is explicitly forbidden from running on connectionless transports
like UDP. It's other RPC programs that might fall into this trap. I'll see
if I can come up with a sentence or two that summarize this situation.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Tue, 28 Apr 2020 10:55:26 -0400

Hi Sorin-

> On Apr 28, 2020, at 8:54 AM, [email-masked] wrote:
> 

> 1.	If there is a compromised user running on same client it is possible that the compromised user can "see" the identity material of the legitimate users.

I believe that's correct. Section 7.2 explains this point so that
implementers can be aware and address the issue appropriately. There
isn't anything the on-the-wire protocol can do to address it, as
far as I can tell.

> 2.	It is possible that a compromised user initiate a DDoS attack on the server and the server will not detect the attack as it comes from a legitimate host and encrypted. This may expose a server t…

IIUC, this attack is possible with RPC without TLS protection? Thus it
does not seem particular to the protocol defined in this document.

> Also the question is do we allow a mix of users using TLS and others not using TLS on same client? I understand that we don't support multiple TLS on same connection but do we support a mix? Some e…

The document does not forbid a mix of TLS-protected and unprotected
connections to the same server or even to the same RPC program on that
server.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Tue, 28 Apr 2020 17:32:04 -0400

> people from outside of NFSv4 are used to. Because that clearly surprises me.

I've made the following changes:

- REQUIRED the use of the connection_id extension, with a justification

- REQUIRED the use of a positive length CID

- Added an RFC Editor's Note to pick up the extension number of the
connection_id extension once that is known

The section now reads:

   RFC Editor: In the following section, please replace TBD with the
   connection_id extension number that is to be assigned in
   [I-D.ietf-tls-dtls-connection-id].  And, please remove this Editor's
   Note before this document is published.

   Multi-homed RPC clients and servers may send protected RPC messages
   via network interfaces that were not involved in the handshake that
   established the DTLS session.  Therefore, when protecting RPC
   traffic, each DTLS handshake MUST include the "connection_id(TBD)"
   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
   length.  Endpoints implementing RPC programs that expect a
   significant number of concurrent clients should employ ConnectionIDs
   of at least 4 bytes in length.

--
Chuck Lever