Re: [nfsv4] Thinking about an RFC5661bis.

[Benjamin Kaduk <[e-mail]>]

On Fri, Mar 01, 2019 at 07:17:09AM -0500, David Noveck wrote:
> >>     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").
> 
> > It will be interesting to see what the text around that looks like --
> > starting from just the Internet threat model of RFC 3552
> 
> I think I'll have to look at that document intensely.  Thanks for pointing
> me to it.

You're quite welcome!  I am so familiar with it that I end up assuming
everyone else knows about it, which is of course not the case...

> > it's hard for me
> > to imagine that behavior like AUTH_SYS would be anything other than
> "SHOULD
> > NOT".
> 
> You're right it does seem hard to imagine.  However, in this case
> imagination
> is not required.  You just have to look at what happened:
> 
>    - On 9/19/2008, this working group requested publication of
>    draft-ietf-nfsv4-minorversion1-26.txt which presented use of AUTH_SYS as
>    optional/allowed.
>    - On 12/19/2008, the IESG approved publication of
>    draft-ietf-nfsv4minorversion1-29.txt as a Proposed Standard, even though
>    that document still  presented use of AUTH_SYS as optional/allowed.
>    - On 1/14/2010, RFC5661 was published as a Proposed Standard with the
>    treatment of AUTH_SYS intact.
>    - Since then, implementations have been developed and deployed which
>    used AUTH_SYS, including many deployments in environments in which use of
>    AUTH_SYS could reasonably be felt to be imprudent, leading to a troubling
>    security situation for NFSv4.1.
> 
> People may well have different views as to how to assign the
> responsibility/blame for this situation and there is no real point in
> trying to  do so.  Clearly, the authors, the other members of the working
> group, and the IESG all had some role.
> 
> The descision not to say "SHOULD NOT" with regard to NFSv4.1 has already
> been made and I don't see how it can be changed even one thinks that the
> working roup was wrong to write RFC5661 that way or that the IESG was wrong
> to approve publication.   A Security Considerations section can still draw
> attention to the problems that use of AUTH_SYS can give rise to, and the
> steps necessary to mitigate them, where possible.

Well, we did publish some new IETF-consensus document in the intervening
ten (ish) years that could be taken to shift the balance on what behaviors
we do and do not tolerate in standards-track documents, things like BCP 188
("Pervasive Monitoring is an Attack") and BCP 195 ("Recommendations for
Secure use of TLS and DTLS").  So it's not really clear to me that we must
be strict slaves to precedent (but we do need to acknowledge existing
deployments in some fashion, of course).

> > But please to not take this as trying to discourage you from trying,
> > and rather as a chance to educate the security folk.
> 
> I'm not sure what education I can provide.   I'm sure people will want to
> know how this happened but all I can provide are guesses.   I think I can
> learn stuff about security from the exercise.
> 
> >>I think we need to frame the discussion around the three big
> >> 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,
> 
> Good point.
> 
> > rather than focusing specifically on mechanisms, yes...
> 
> We have had a number of situations in which some particular mechanism was
> felt to be salvific, but turned out not to be so :-(
> 
> >> 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.
> 
> True.  The conclusion I draw is that rpc-tls will have to be fairly far
> along
> in its development when the bis document is considered, even if it doesn't
> have to be published first.    If it seems that equal (or better) security
> is clearly
> on the horizon, I think the security people will be OK with a treatment
> that
> does not stigmtize AUTH_SYS per se, but instead draws attention to the
> exposure of data in transit, the lack of integrity protection, and the
> execution
> of unautheticated requests.

Speaking just for myself, documents that accurately describe the current
properties and have a path to better properties are generally tolerable,
and I am pragmatic enough to not hold things up for ideological purity.

> Given the need for rpc-tls to be fairly far along, the delays that Tom is
> worried
> about do not seem to be all that troubling, since there is really no rush
> to get
> 5661bis out, even if we think it is needed/desirable.

That said, I'm not sure whether I want to hope that I am or am not still
on the IESG when the purported bis document shows up there :)

-Ben