Re: [nfsv4] Thinking about an RFC5661bis.

[Benjamin Kaduk <[e-mail]>]

On Thu, Feb 28, 2019 at 09:37:28AM -0500, David Noveck wrote:
> A number of review comments regarding draft-ietf-nfsv4-mv1-msns-update have
> raised the issue of a possible bis document for NFSv4.1.   These range all
> the way from those assuming that mv1-msns-update is a stepping stone on the
> way to the bis document, which I agree with, to those that are asking us to
> explain why we haven't already done that.   I will have to respond to that
> latter comment, but I'm hoping to delay that until after the telechat.

Thanks for starting this thread.  Since I am reading already...

> In any case, it seems that we have accumulated enough changes to and issues
> with RFC5661 that we need to start thinking about producing a bis
> document.  These include:
> 
[...]
> 
> The joker in this particular pack is the Security Considerations section.
>  While we have to address the Security Directorate's notorious, "collection
> of random observations" comment, I think we need to do so in a way that is
> compatible with the expected draft-nfsv4-rpc-tls (hint, hint), even though
> we want to be able to publish without waiting for rpc-tls to become an
> RFC.  While draft-cel-rpc-tls-02 states that use of AUTH_SYS is currently
> "discouraged" and that is a fair summary, I don't think RF5661 ever does
> that explicitly.   It may be that we will need to explicitly discourage use
> of AUTH_SYS  in an rfc5661bis (without, I hope, going so far as "SHOULD
> NOT").  I think we need to frame the discussion around the three big

It will be interesting to see what the text around that looks like --
starting from just the Internet threat model of RFC 3552 it's hard for me
to imagine that behavior like AUTH_SYS would be anything other than "SHOULD
NOT".  But please to not take this as trying to discourage you from trying,
and rather as a chance to educate the security folk.

> security deficits present using AUTH_SYS in the clear (exposing your data
> to prying eves, using  data that has traversed the newtwork without
> integrity protection, acting on unauthenticated requests) and not on the
> use of AUTH_SYS per se.  If we do this, we can publish and implement

Dividing things into risks and countermeasures is usually a good strategy,
rather than focusing specifically on mechanisms, yes...

> rpc-tls without needng to further deal with the security considerations
> section of the NFSv4.1 spec.

...since once you start talking about *properties* of the protocol
components, it's easier to slot different backends into place, provided
that they provide the same (or better) properties.

-Ben