Re: [nfsv4] Thinking about an RFC5661bis.
David Noveck <davenoveck@gmail.com> Fri, 01 March 2019 12:17 UTC
Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4B9130E73 for <nfsv4@ietfa.amsl.com>; Fri, 1 Mar 2019 04:17:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8nPO-DUJLKS for <nfsv4@ietfa.amsl.com>; Fri, 1 Mar 2019 04:17:21 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3564E129441 for <nfsv4@ietf.org>; Fri, 1 Mar 2019 04:17:21 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id e15so11175964otk.6 for <nfsv4@ietf.org>; Fri, 01 Mar 2019 04:17:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ph2liauByApI1T4w5aK08EVy12PkWVyrjRfgap1hx/c=; b=GehgOhG2DnfX6iNNWjzv+9ftY4SAyuSJstFQBAE7+NYIJfXVGBouif3KOpAlYi3NZ9 zsa1CrnrcyUS8A1eQKurJnqcTjOF9+yQ/kjFsU2oTW6edZzrFFzewmepC4HTcnLidA2/ Nymvg2QFsJDVsgi7EeqFBL4RUAN9W5LN+zrU+kWg77HpivY62l8HYAdFZJmToLI9pYxk KYcAN/PIdAVhJmswJ6wlGP4PEM/fi4Ucw+nQIqDrPsGL54p+n/T3HODU1FVasSzTmvod pwnh+DnflMpMpuHWAajh7FmjJDtDTjiC6AcMzuA2dh60PCH3v3tiMLQmGwasY3WMCqdk 5zbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ph2liauByApI1T4w5aK08EVy12PkWVyrjRfgap1hx/c=; b=nUqrJ63zyIzSqDXj8JMBG6b18Dx/Rn7IghxvQpS1BdV0FrvH2CaiEJ0xOjTCfXTKBp hJ2BtqaMpRHD4nJyeAzM8XtdaB0tycGGUbcv6nqs1vbPVxdifAgM+2HfWm8f/emW3q// HSwIGyGTKFSVRCTBliNvkCsf5yiyl9zgWFRasZW3PBSww3spIOTXGTVZEFKrys+rF6Pj BAoF4Cwj1Iz+fm9GiH2uXR3rWN3YriUDXBTP0w4C1c+m7QQSFU3rgzL+8Dfirguaceir Gp+Njvjm6+3MWOP4f7+KrSeFL+Ydjwl5sBY/0NdH+fkMjdoIJEIMRHGcHBlYLgmbWoaG UQog==
X-Gm-Message-State: APjAAAXEvGlPN/rius8KSmT1ZjGrw7xxMZWQDh0nZCHbbU1r4XRzAUxj 0+tphHWg4MuC65rq97yYI5VL04CzU1fH1Cwb6Ik=
X-Google-Smtp-Source: APXvYqwGurpvg3HA9uuCoyUBBYw9QpA7uOWCSpnzPgebBFmUy98uszoVsK7fmczYYgv2am/Dnnn6yHflwwRohG+RNe8=
X-Received: by 2002:a05:6830:1193:: with SMTP id u19mr3122832otq.221.1551442640261; Fri, 01 Mar 2019 04:17:20 -0800 (PST)
MIME-Version: 1.0
References: <CADaq8je5pzF7m+4oVCNfSeeBDQ98kBwAdCN_o1hBrfDob=SBaA@mail.gmail.com> <20190301005957.GK53396@kduck.mit.edu>
In-Reply-To: <20190301005957.GK53396@kduck.mit.edu>
From: David Noveck <davenoveck@gmail.com>
Date: Fri, 01 Mar 2019 07:17:09 -0500
Message-ID: <CADaq8je2Ec=xM2TiGH0Cj7dJte120=9YauneEUmkf77nHkamVA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000076567805830763c1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/qtLgRQ6j8PlypefBYElCfgE-evE>
Subject: Re: [nfsv4] Thinking about an RFC5661bis.
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2019 12:17:24 -0000
>> 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. > 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. > 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. 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. On Thu, Feb 28, 2019 at 8:00 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > 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 >
- [nfsv4] Thinking about an RFC5661bis. David Noveck
- Re: [nfsv4] Thinking about an RFC5661bis. Tom Haynes
- Re: [nfsv4] Thinking about an RFC5661bis. Chuck Lever
- Re: [nfsv4] Thinking about an RFC5661bis. David Noveck
- Re: [nfsv4] Thinking about an RFC5661bis. Tom Haynes
- Re: [nfsv4] Thinking about an RFC5661bis. David Noveck
- Re: [nfsv4] Thinking about an RFC5661bis. David Noveck
- Re: [nfsv4] Thinking about an RFC5661bis. Benjamin Kaduk
- Re: [nfsv4] Thinking about an RFC5661bis. David Noveck
- Re: [nfsv4] Thinking about an RFC5661bis. Chuck Lever
- Re: [nfsv4] Thinking about an RFC5661bis. J. Bruce Fields
- Re: [nfsv4] Thinking about an RFC5661bis. David Noveck
- Re: [nfsv4] Thinking about an RFC5661bis. Tom Haynes
- Re: [nfsv4] Thinking about an RFC5661bis. Benjamin Kaduk