Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

["Mkrtchyan, Tigran" <[e-mail]>]

----- Original Message -----
> From: "Dave Noveck" <[e-mail]>
> To: "Chuck Lever" <[e-mail]>
> Cc: "NFSv4" <[e-mail]>
> Sent: Wednesday, April 24, 2019 9:41:01 PM
> Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

>> The opportunistic approach is meant to be a step up, not
>> a full solution.
> 
> OK, but the question at hand is whether rpc-tls (or the RFC that results
> from it) is to be limited to the opportunistic approach.   I'm arguing that
> it should not, and much of what you say below seems to indicate
> that you agree.
> 
> However, other things you say lead me to a contrary conclusion, so it
> would be best if we got a clear answer on this point.
> 
>> We are bridging a gap here, and I think
>> we all expect/hope to have deeper solutions in the future.
> 
> To get those, I think we need do more than expect/hope for them.   I think
> we need to plan for them.   One way to do that is to allow rpc-tls to be
> used either opprtunistically or non-oportunistically. rather than
> restructing it to opprtuunistic use and expect something else to
> provide support for the non-opportunistic case.
> 
>> For instance, we could define an RPC on QUIC transport
>> type that requires host authentication and encryption from
>> the get-go.
> 
> I've heard some rumblings about QUIC and would like to see an RPC
> transport type defined.   However, we haven't yet seen even a
> fragmentary individual submission on this topic.   Yes, we could
> do this in the future, but it is unwise to count on it any time soon/
> 
>> The current rpc-tls document now RECOMMENDS that an RPC
>> client's security policy insists on the use of TLS (ie,
>> that they will immediately close a connection to a server
>> that does not support TLS).
> 
> If it does, then it is not opportunistic and there is a conflict with
> the abstract which says "opportunistically".
> 
> I've been unable to see where it says that.  I've searched the document
> for "RECOMMEND".  Also:
> 
> It does  say the following which seems to contradict it:
> 
> The mechanism described in this document interoperates fully with RPC
> implementations that do not support TLS.  The use of TLS is
> automatically disabled in these cases.
> 
> Tigran is looking for a discussion of this case and can't find it, so, in
> any case, it is not just me who isn't able to see this.

I think Chuck's proposal is not contradicting to what I am saying. In "opportunistic"
TLS model it's up to client to close the connection to a server that does not
support TLS and it up to server to reject RPC requests from the clients that
don't start conversation with STARTTLS. Such situation is well defined in rfc3207 (SMTP):


...
   After the client gives the STARTTLS command, the server responds with
   one of the following reply codes:

   220 Ready to start TLS
   501 Syntax error (no parameters allowed)
   454 TLS not available due to temporary reason


   If the client receives the 454 response, the client must decide
   whether or not to continue the SMTP session. Such a decision is
   based on local policy.
...

and

...

   A SMTP server that is not publicly referenced may choose to require
   that the client perform a TLS negotiation before accepting any
   commands.  In this case, the server SHOULD return the reply code:

   530 Must issue a STARTTLS command first
...


Again, I am not pushing for one or an other solution, but for a document
with a monosemantic description.

Tigran.

> 
>> That is a reasonable way to
>> address active attackers while there is still a large fleet
>> of RPC implementations without TLS support.
> 
> I don't see that you can RECOMMEND that unconditionally,
> especially in an RPC-generic document.   When there are
> a large set   of RPC implementations without TLS support,
> is precisely when the alternative (i.e. opportunistic) approach
> has its greatest value.
> 
>> We could also strongly RECOMMEND the use of authentication.
> 
> I don't think we should do that in the context of an RPC-generic
> document.  Each protocol might reasonbly have its own needs and
> policies.
> 
> The decision to proceed with an rpc-generic document was intended to
> accellerate development of rpc-tls.  That's worked so far but I think that
> to
> maintain progress we have to avoid the temptation to put protocol-
> specific material (most likely for NFSv4) into what should be an rpc-
> generic document.   That would essentially undo the decision to make
> this an rpc-generic document.
> 
> I've thought about something like this for v4-oriented document but
> I think that there the need/requirement for authentication of the client
> is best tied to use of AUTH_SYS.    If you are using RPCSEC GSS and
> have an encrypted channel, you would have adequate NFSv4 security, even
> in an internet environment. :-). At that point, client authentication, which
> might be work to add to the work already done to implement RPCSEC GSS,
> is better seen as OPTIONAL.
> 
> On Wed, Apr 24, 2019 at 10:55 AM Chuck Lever <[e-mail]> wrote:
> 
>>
>>
>> > On Apr 24, 2019, at 10:48 AM, David Noveck <[e-mail]> wrote:
>> >
>> > >> The summary of the reasoning for the use of this term is basically
>> that it
>> > >> does not provide protection in the face of an *active* attacker (that
>> can
>> > >> force downgrade to the previous/insecure technology), but does protect
>> > >> against passive observation.
>> >
>> > > Indeed, this looks directly on point.
>> >
>> > It does but having read this document and considering Ben's statement
>> > that "it :does not provide protection in the face of an 'active'
>> attacker, I'm
>> > wondering if the 'opportunistic" nature of this approach should be
>> mentioned
>> > quite as prominently as it is in -01.
>> >
>> > For example, Tigran is basically asking for a description of how this
>> mechanism
>> > would be used non-opprtunistically and it seems clear to me that
>> eventually
>> > there will be a need such deployments.   If and when this mechanism is
>> widely
>> > deployed the failure to establish an encrypted connection is more likely
>> to be
>> > due to an active attacker rather than a non-rpc-tls-supporting server.
>> >
>> > It is not clear to me why, in that event the client should behave
>> passively in the
>> > face of an active attack.   As i understand it, an eventual Security
>> Consideraations
>> > is going to have to consider all possible attacks and we want to avoid a
>> situation
>> > in which an accurate Security Consideration would need to say, in
>> essence, "omigod,
>> > it's hopeless". :-(
>>
>> The opportunistic approach is meant to be a step up, not
>> a full solution. We are bridging a gap here, and I think
>> we all expect/hope to have deeper solutions in the future.
>>
>> For instance, we could define an RPC on QUIC transport
>> type that requires host authentication and encryption from
>> the get-go.
>>
>>
>> The current rpc-tls document now RECOMMENDS that an RPC
>> client's security policy insists on the use of TLS (ie,
>> that they will immediately close a connection to a server
>> that does not support TLS). That is a reasonable way to
>> address active attackers while there is still a large fleet
>> of RPC implementations without TLS support.
>>
>> We could also strongly RECOMMEND the use of authentication.
>>
>>
>> > On Wed, Apr 24, 2019 at 9:53 AM Chuck Lever <[e-mail]>
>> wrote:
>> >
>> >
>> > > On Apr 22, 2019, at 11:48 AM, Benjamin Kaduk <[e-mail]> wrote:
>> > >
>> > > On Tue, Apr 16, 2019 at 01:11:54PM -0400, Chuck Lever wrote:
>> > >>
>> > >>> On Apr 16, 2019, at 1:09 PM, David Noveck <[e-mail]>
>> wrote:
>> > >>>
>> > >>> I'm confused by the addition of the word "opportunistically" in the
>> abstract.   This document defines an important way of providing security to
>> RPC-based protocols such as NFSv4, so as to deal with the very real
>> security problemms that these protocols have.    While these facilities can
>> only be used when both client and the server provides support, I don't
>> think that fact alone make the use of these facilties "opportunistic".
>> What exactlty is this word intended to imply?
>> > >>
>> > >> "Opportunistic" is a term of art. See:
>> > >>
>> > >> https://en.wikipedia.org/wiki/Opportunistic_TLS
>> > >
>> > > RFC 7435 is also a good reference for this topic (and one that has IETF
>> > > consensus, FWIW).
>> > >
>> > > The summary of the reasoning for the use of this term is basically
>> that it
>> > > does not provide protection in the face of an *active* attacker (that
>> can
>> > > force downgrade to the previous/insecure technology), but does protect
>> > > against passive observation.
>> >
>> > Indeed, this looks directly on point.
>> >
>> > --
>> > Chuck Lever
>> >
>> >
>> >
>>
>> --
>> Chuck Lever
>>
>>
>>
>>
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4