Re: [secdir] Secdir last call review of draft-ietf-nfsv4-mv1-msns-update-04
David Noveck <davenoveck@gmail.com> Fri, 08 March 2019 23:52 UTC
Return-Path: <davenoveck@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F8F12788F; Fri, 8 Mar 2019 15:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 gVvMd907AOTP; Fri, 8 Mar 2019 15:52:46 -0800 (PST)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 F2D56126DFA; Fri, 8 Mar 2019 15:52:45 -0800 (PST)
Received: by mail-oi1-x232.google.com with SMTP id t82so17239719oie.12; Fri, 08 Mar 2019 15:52:45 -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=pTFDMWtIKHuM1Hmsmz5hpGhCqwN7HwGOoA9vQoJGzYU=; b=gWuW/zaGNcgqtWIt/dGuTj/uTFLVVvTLr9Z7Kiu/1yYTuJW1f25EuJaF2M3sCpv7kt HRw0s5XgeGNcL6enx+2K8zqnMpAK0fX22StZ2uOzviSsww0oNKJzZbnmwFFMRbkBSLrp lAu+VsT8I7EsNpV2XHwfnne2zGOBGaewVHl12RhILy3zltRXKsIR93JWYZI07P0hrmAa 7gVa+2DDlhaBbN8mLju/FyOq8N6hPUbw959wxrYdP21f8SKHExgUV7LMRbvXRlj3Ex9h 9PJfBcfDWvO2Fj2ub/6F0ilFEhgMY1PcZt5V03O2LPYm1EzAvGumOt7C8NS127plp3TK r16Q==
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=pTFDMWtIKHuM1Hmsmz5hpGhCqwN7HwGOoA9vQoJGzYU=; b=UHkPhTzKukSjvC/JlEttKjxeB/FkpIt9TNTQjnqMHBRPzyRkNcVr232ciTT8Y6HDLU tmD2RDIeDckw8DGPxYPDJiSR8BY+0rIbcAD8O4zAY0fZJM5HKwRbz1ffW8zr7CKTHDvO FH5taEginG26uMd8QVP5pAzDKdpj/BpNFQMZ8HiDlmkFgsc4cawsVvxmpJd+pwMdZvlW 2dMrh4aVBmecd/VHVbhEpJfKQyoyB6YwRPRv6juDzBYD56xK84bTjk3p54d2Y9dF4Wod wo50ySZ66xp9TngKOzmLNAyj0o53se7TdrNmA+/1ylcTa+tZqw7MxQZs3Ox1Yt6xrcFB 7CMQ==
X-Gm-Message-State: APjAAAU7hRFjjVsstu39yd1gBlg6Be5TGM4DNf86EZQ5rtddAC+ycY9n RjQVfGkt7vVTVaPzICkoj58/uNvabpixUT8QOzA=
X-Google-Smtp-Source: APXvYqxmJCYd29Vb5KuqtuegyYpxaVqoCeutcNYnYlDfovlDGYyCtopEthpoDo8vVf3/MlJww21BnIeDnrsTnuAwKwo=
X-Received: by 2002:aca:f0c3:: with SMTP id o186mr9312874oih.101.1552089164963; Fri, 08 Mar 2019 15:52:44 -0800 (PST)
MIME-Version: 1.0
References: <155128908237.14053.17188619727012241844@ietfa.amsl.com> <CADaq8jeQJi+azCcuMCRN8h+quqvx+NM2kiOAMq9E-n+Kp6eWRw@mail.gmail.com>
In-Reply-To: <CADaq8jeQJi+azCcuMCRN8h+quqvx+NM2kiOAMq9E-n+Kp6eWRw@mail.gmail.com>
From: David Noveck <davenoveck@gmail.com>
Date: Fri, 08 Mar 2019 18:52:33 -0500
Message-ID: <CADaq8jd9iAmsUO_Heyk8RMRiEue97W_TPwx_65YAxaS-ksR4OQ@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: secdir@ietf.org, ietf@ietf.org, NFSv4 <nfsv4@ietf.org>, draft-ietf-nfsv4-mv1-msns-update.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000566aac05839debbf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/nkc4JITrVBJqeEFjL2P3OufEzdw>
Subject: Re: [secdir] Secdir last call review of draft-ietf-nfsv4-mv1-msns-update-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2019 23:52:51 -0000
I previously said: > Will address nits 0)-4) and 6)-10) in -05. However when I looked more closely at 9), I've found that I cannot make the requested change. > 9) s12.2.3: replace ietf.org with example.org (not supposed to use > real domains even if it is “ours”). This is not an example. The use of ietf,org is intentional and is intended as a way to provide the ability to define globally usable variable definition as well as domain-specific ones. This is specified in section 22.5 of RFC5661. I'm not sure about the details of the prohibition of the use of real domain names but I can;t see how it would apply in this case where this form of vatibl specification, including a real domain name has already been adopted. On Thu, Feb 28, 2019 at 8:30 PM David Noveck <davenoveck@gmail.com> wrote: > > These > > instructions will really help when work on a fully revised NFS RFC gets > > going. > > That's the intention. The working group is now discussing the possibility > of an rfc5661bis > that would use those instructions. Note that the current document would > be the source of > a large set of the changes but there are also others: The > internationalization section needs to > be updated as it was in RFC7530. Section 12 needs to be updated to > reflect the work done by > RFC8434. Also, there are a lot of erratta that would need to be applied. > > > 0) The big issue being addressed in the security considerations is the > fact > > that RPSEC_GSS is must support not must use > > That reflects choices made for RFC3530 and carried over until now. This > has resulted in > a situation in which AUTH_SYS is very commonly used despite its obvious > security weaknesses. > > > So what do you do when RFC 5661 says: > > > The fetching of attributes containing file system location > > information SHOULD be performed using RPCSEC_GSS with integrity > > protection, > > Not much, since there is not much I can do about that. > > > And, you don’t now change to MUST use RPSEC_GSS? > > No I don't. Currently use of AUTH_SYS is allowed and the working > group has not made any decision to change that. > > > Well I think at a minimum you should do some 2119 language: > > OK, but note that this is a widely-deployed protocol and we are not > in a position to invalidate deployment choices made in line with RFC5661, > even if we think they were ill-advised. > > > 0) s16 (after the bullets): 2119 this should: > > If you are suggesting changing "should" to "SHOULD" in this parapgraph, > I'm OK with making that change in -05, although I will raise the issue with > the working group to check about existing implemtations. > > > 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT: > > I intend to shift this to "SHOULD NOT" in -05. > > > 2) s16 (last bullet): 2119 this should: > > Given that this bullet appears in a summary, I think the "should" is > misleading. Converting it to "SHOULD" would lead to recommemmending > filtering without specifying the filtering to be done. What I propose to > do in -05 is replace "should be subect to filtering" by "is made subject to > filtering as described above". > > > The use of requests issued without RPCSEC_GSS (i.e. using > > the known to be insecure AUTH_SYS), while undesirable and > > Insecure, may not be avoidable in all cases. > > While I approve of drawing more attention to the weaknesses of > AUTH_SYS, I feel the use of the word "insecure" is too vague. > "Insecure" covers a range of problems whereby traffic is either > exposed to prying eyes, subject to corruption in transit, or acted > upon without authentiction. Given the context, I think we need to > be clear about what the actual problem is even though AUTH_SYS, > in what has to be considered a virtuoso performance :-), manages > to acomplish the hat trick of protocol insecurity. > > So I propose writing this as follows: > > The use of requests issued without RPCSEC_GSS (i.e. using AUTH_SYS which > has no provision to avoid corruption of data in flight), while undesirable > and a potential security exposure, may not be avoidable in all cases. > > > > It’s probably also worth discussing whether s14.3 should drop > > support for includes id-sha1 > > The text you are referring to was carried over from RFC5661 as-is since > there was no issue known with it. > > Regarding the potential deletion of id-sha1, the issue, given that server > support is currently REQUIRED, is whether there are clients using this who > might be impacted by a change. I'll check with the working group. > > > 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed. > > These are really OPTIONAL althouh the word "RECOMMENDED" is (confusingly) > used. > Will delete. > > > 5) s4.3 (penultimate para): Seems like r/should/SHOULD. > > It is probably the case that RFC5661 made a poor choice here. However, I > don't think we can change it now. > > > 10) s16 (3rd bullet): Why is requirement is caps? > > It's because I was under the misapprehension that statement that things > were REQUIRED or RECOMMENDED could be referred to as "REQUIREMENTS" or > "RECOMMENDATIONS". It turns out not to be so. > > Will address nits 0)-4) and 6)-10) in -05. > > On Wed, Feb 27, 2019 at 12:38 PM Sean Turner <sean@sn3rd.com> wrote: > >> Reviewer: Sean Turner >> Review result: Has Issues >> >> This draft updates NFSv4.1 to correct handling of the fs_locations and >> fs_locations_info attributes; NFSv4.1 weighs in at 617 pages and this >> draft weighs in a relatively spry 106; let’s say I was really, really >> hoping >> for some multi-page ASCII art, but also no pretty much all text. The >> draft does a good job of explaining what’s being replaced and why, but >> I have to say that I did not check all of section pointers. These >> instructions will really help when work on a fully revised NFS RFC gets >> going. Unfortunately for me, I do not have NFSv4.1 in my head so let’s >> just say that I did my best … >> >> Summary: This draft is probably worthy of some type of DISCUSS based >> on the following: >> >> 0) The big issue being addressed in the security considerations is the >> fact >> that RPSEC_GSS is must support not must use and the other mechanism >> referred to by RFC 5661 are: >> >> - AUTH_NONE - nada authentication >> >> - AUTH_SYS as described in Appendix A is known to be insecure due to >> the lack of a verifier to permit the credential to be validated. >> AUTH_SYS SHOULD NOT be used for services that permit clients to >> modify data. AUTH_SYS MUST NOT be specified as RECOMMENDED or >> REQUIRED for any Standards Track RPC service. >> >> - AUTH_DH as mentioned in Sections 8.2 and 13.4.2 is considered >> obsolete and insecure; see [RFC2695]. AUTH_DH SHOULD NOT be used for >> services that permit clients to modify data. AUTH_DH MUST NOT be >> specified as RECOMMENDED or REQUIRED for any Standards Track RPC >> service. >> >> So what do you do when RFC 5661 says: >> The fetching of attributes containing file system location >> information SHOULD be performed using RPCSEC_GSS with integrity >> protection, >> And, you don’t now change to MUST use RPSEC_GSS? Well I think at a >> minimum you should do some 2119 language: >> >> 0) s16 (after the bullets): 2119 this should: >> >> In light of the above, a server should present file system >> location entries that correspond to file systems on other servers >> using a host name. >> >> 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT: >> >> As a >> result, the client should not use such unverified location entries >> as a basis for migration, even though RPCSEC_GSS might be >> available on the destination. >> >> 2) s16 (last bullet): 2119 this should: >> >> Where the use of the returned information cannot be >> avoided, it should be subject to filtering to eliminate the >> possibility that the client would treat an invalid address as >> if it were a NFSv4 server. >> >> And, I guess since AUTH_SYS is insecure can I suggest a friendly >> amendment to the following sentence: >> >> OLD: >> The use of requests issued without RPCSEC_GSS (i.e. using >> AUTH_SYS), while undesirable, may not be avoidable in all >> cases. >> >> NEW: >> >> The use of requests issued without RPCSEC_GSS (i.e. using >> the known to be insecure AUTH_SYS), while undesirable and >> Insecure, may not be avoidable in all cases. >> >> It’s probably also worth discussing whether s14.3 should drop >> support for includes id-sha1. >> >> >> These are the nits: >> >> 0) Update to use new 2119 paragraph: >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >> "OPTIONAL" in this document are to be interpreted as described in BCP >> 14 [RFC2119] [RFC8174] when, and only when, they appear in all >> capitals, as shown here. >> >> 1) s3.1 (wordy): r/since the >> ports to be used for various types of connections might be >> required to be different/since the >> ports to be used for various types of connections might be >> different. >> >> 2) s3.1 (missing period): r/Two such addresses support the use of clientid >> ID trunking, as described in [RFC5661]/Two such addresses support the >> use of clientid >> ID trunking, as described in [RFC5661]. >> >> 3) s4.2 (missing word): r/which may accessed/which may be accessed >> >> 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed. >> >> 5) s4.3 (penultimate para): Seems like r/should/SHOULD. >> >> 6) s4.5: r/present , is/present, is >> >> 7) s4.5: Note sure you need the parenthetical in the following: >> a server may (but is not required to) >> >> 8) s4.5.4: r/In the event that server failures,/In the event that >> server fails, >> or >> r/In the event that server failures,/In the event of server failures, >> >> 9) s12.2.3: replace ietf.org with example.org (not supposed to use >> real domains even if it is “ours”). >> >> 10) s16 (3rd bullet): Why is requirement is caps? >> >>
- [secdir] Secdir last call review of draft-ietf-nf… Sean Turner
- Re: [secdir] Secdir last call review of draft-iet… David Noveck
- Re: [secdir] Secdir last call review of draft-iet… David Noveck
- Re: [secdir] Secdir last call review of draft-iet… Spencer Dawkins at IETF
- Re: [secdir] Secdir last call review of draft-iet… Brian E Carpenter