[Gen-art] Gen-art Telechat review of draft-ietf-nfsv4-rpcsec-gssv3-15
Elwyn Davies <elwynd@dial.pipex.com> Sat, 16 January 2016 18:15 UTC
Return-Path: <elwynd@dial.pipex.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E5C1A009C; Sat, 16 Jan 2016 10:15:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
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 pAFq-oiYuXeI; Sat, 16 Jan 2016 10:15:40 -0800 (PST)
Received: from a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51691A0020; Sat, 16 Jan 2016 10:15:39 -0800 (PST)
Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from <elwynd@dial.pipex.com>) id 1aKVNu-0002Z3-62; Sat, 16 Jan 2016 18:15:37 +0000
From: Elwyn Davies <elwynd@dial.pipex.com>
To: General area reviewing team <gen-art@ietf.org>
Message-ID: <569A88B9.3020804@dial.pipex.com>
Date: Sat, 16 Jan 2016 18:15:21 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Painless-Spam-Score: -1.5
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/Xce6EghnOrlmWvHiN5OdECBWC5c>
Cc: Tom Haynes <thomas.haynes@primarydata.com>, "draft-ietf-nfsv4-rpcsec-gssv3.all@ietf.org" <draft-ietf-nfsv4-rpcsec-gssv3.all@ietf.org>
Subject: [Gen-art] Gen-art Telechat review of draft-ietf-nfsv4-rpcsec-gssv3-15
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jan 2016 18:15:43 -0000
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-nfsv4-rpcsec-gssv3-15.txt Reviewer: Elwyn Davies Review Date: 2016/01/16 IETF LC End Date: 2015/12/09 IESG Telechat date: 2016/01/21 Summary: Almost ready. Thank you for addressing my comments from the last call review. For the record there are a couple of other points that have been raised elsewhere that need to be addressed. Major issues: s2.7.1/s4: There is a security issue with RPCSEC_GSS_CREATE when multi-principal authentication is required. See mail [1] below. This may have a (minor) knock-on effect of the NFSv4.2 specification where this is used; as currently specified (draft-ietf-nfsv4-minorversion2-40) use of privacy is already mandated for at least some of the relevant uses of RPCSEC_GSS_CREATE in NFSv4.2 which will mitigate the problem. I have raised this issue in the Telechat review of the NFSv4.2 draft to ensure that privacy is mandated in *all* relevant cases - and to ensure changes are coordinated. Minor issues: s2.7.1.4: Some refinement of the constraints on the rp_name string marked as 'human readable' would be desirable. Nits/editorial comments: None ======================================== [1] > From: Nico Williams <nico@cryptonector.com> > Subject: Re: rpcsec-gssv3 > Date: January 11, 2016 at 8:01:52 PM EST > To: Benjamin Kaduk <kaduk@mit.edu> > Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "sec-ads@ietf.org" <sec-ads@ietf.org>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, Martin Stiemerling <mls.ietf@gmail.com>, "Adamson, Andy" <William.Adamson@netapp.com> > > On Thu, Jan 07, 2016 at 02:14:01PM -0600, Nico Williams wrote: >> Ok, thanks. I'll post a write up this Saturday. > > Or on Monday. > > OK, so, a while back Ben Kaduk noticed that there is a security problem > with the RPCSEC_GSS_CREATE procedure with multi-principal > authentication. > > The attack varies from easy to difficult to mount depending on whether > the server implements a global or per-connection GSS context handle > namespace, and whether it assigns them in a way that the attacker can > get a specific context handle number assigned to it. > > There are two fixes, the simplest of which is to require that the > RPCSEC_GSS_CREATE procedure be called with privacy protection when using > the multi-principal authentication feature. > > To recap how the RPCSEC_GSS_CREATE procedure with multi-principal > authentication feature works, the client first makes a MIC token with a > GSS context that authenticates the user to the server, then it it uses > that MIC in the payload of the RPCSEC_GSS_CREATE procedure. The > RPCSEC_GSS_CREATE procedure is itself protected with a GSS context that > authenticates the client. > > The problem is that the data that the user GSS context MICs is > insufficiently strong a statement of intent because it only identifies > the client host GSS context by its RPCSEC_GSS context handle ID and > nothing more. An attacker that can intercept an RPCSEC_GSS_CREATE > procedure and cause the RPCSEC_GSS context handle to get re-assigned > will be able to steal the victim's identity. > > There are a number of solid fixes that fall into two classes: > > 1) Add to the data that the user context MICs in order to improve the > quality of the statement of intent. > > E.g., add the client host principal's name. Or add a MIC made with > the client host's GSS context. > > 2) Make it so the attacker cannot steal the MIC made with the user GSS > context. > > E.g., use privacy protection for the RPCSEC_GSS_CREATE procedure, > thus the MIC made with the user GSS context cannot be obtained by the > attacker without having the client host's or server's credentials. > Stephen proposed this. > > (The OpenAFS rxgk protocol uses GSS_Pseudo_random() [RFC4401] to > similar effect.) > > At this stage the simplest thing to do is to require that clients always > use privacy protection for the RPCSEC_GSS_CREATE procedure. Note > that there is nothing that the server can do to prevent this attack if > clients don't use privacy protection for this, but the server should > still reject RPCSEC_GSS_CREATE procedure calls without privacy > protection. (All of this is only for the multi-principal authentication > case.) > > Nico > --
- [Gen-art] Gen-art Telechat review of draft-ietf-n… Elwyn Davies
- Re: [Gen-art] Gen-art Telechat review of draft-ie… Adamson, Andy
- Re: [Gen-art] Gen-art Telechat review of draft-ie… Martin Stiemerling
- Re: [Gen-art] Gen-art Telechat review of draft-ie… Adamson, Andy
- Re: [Gen-art] Gen-art Telechat review of draft-ie… Elwyn Davies
- Re: [Gen-art] Gen-art Telechat review of draft-ie… Adamson, Andy