Re: [Gen-art] Gen-art Telechat review of draft-ietf-nfsv4-rpcsec-gssv3-15

Martin Stiemerling <> Thu, 21 January 2016 05:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0D3161B2FA1; Wed, 20 Jan 2016 21:43:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DAVKK4ymvE_e; Wed, 20 Jan 2016 21:43:29 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB6401B2FA0; Wed, 20 Jan 2016 21:43:28 -0800 (PST)
Received: by with SMTP id r129so157693437wmr.0; Wed, 20 Jan 2016 21:43:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=rJc5tNlRk+FbsFQq8s1kjDeFQsElPR4We7omibrJ4yE=; b=k1hPz77eUQ3h4Q2ojIh5XKoYiwbjEdm+Cu6qaCZKfL1IZbBSKzqn9S8m7MpG3Wwu6G x7VffSvmoKRHYctb1Y6Z3DvpWrv+AjpS40dZtT2VGYsSJZesNWZbWTLeKwAGXDa4+/io kaHji6hpbEMd6u7/jt3M1RLzSPwzqEkmpPZ1Xdpw7py39tSD4WS3nlndgRhvdEN67w1w VpBlSJgaJmY+NADORCUVpLL79Jp/3nT7WTA8TM8gZhydbB3ngWHXZYucKWpGb3pVzZIa UMr6Al4bRkzRMp6eQMMe1G+f+iTCS+J5QJ7bw9KN5D2kFFu51XTGRQqIGMDNYPi9gwk9 qb9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=rJc5tNlRk+FbsFQq8s1kjDeFQsElPR4We7omibrJ4yE=; b=jkoOG/nsN4rsaBLrpERoyZ+CwNHyM5SF3/zRiHB492tmMIGGD5xIstMbQHDyskFUL6 jvYFE1F5ub1qQSPAKgqCCfRJ9pIleeZLi0gHtTvmqwP/axdFuVaCNWWw7sUqPtle4FfJ miC2awZ4d+SNSSuTgGbkBlOTHAjQ+lb+9mgLz1BQRsYzH4pIWhf57t4kNihliQEVdc1I QSvs9+61CmxZpPEX4GXHVQ7hF4IdXi4X52GRadYyrGmK92kJELwUoA6YCAgZa8Enb6Ry eJcJ0MGQTWmWkTrFZhL777il9jlo8AlsyMh0Qn+2/FG8kLsHrqlbQh4ib0pWs5AFLj4p E7OQ==
X-Gm-Message-State: AG10YOQG6tUNv1fu0FY3XaM8AJBf1Utm0+2k6xDC25ch5tAkaK6n5iMj+lhIY91bJH0K1w==
X-Received: by with SMTP id l129mr7495291wmd.38.1453355007421; Wed, 20 Jan 2016 21:43:27 -0800 (PST)
Received: from ([2001:1a80:280c:8300:c07d:5c19:369e:436c]) by with ESMTPSA id w1sm1171113wmd.2.2016. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 21:43:26 -0800 (PST)
To: "Adamson, Andy" <>, Elwyn Davies <>
References: <> <>
From: Martin Stiemerling <>
Message-ID: <>
Date: Thu, 21 Jan 2016 06:43:25 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: General area reviewing team <>, Tom Haynes <>, "" <>
Subject: Re: [Gen-art] Gen-art Telechat review of draft-ietf-nfsv4-rpcsec-gssv3-15
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jan 2016 05:43:31 -0000

Hi Andy,

The telechat is happening today (01/21) at 4pm CET.

However, my understanding from the email thread with Nico is that there 
is a solutiong that needs to be folded into the draft, isnt't it?

In this case, there is no need to join the telechat.



Am 20.01.16 um 20:49 schrieb Adamson, Andy:
>> On Jan 16, 2016, at 1:15 PM, Elwyn Davies <> wrote:
>> 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
>> <>.
>> 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
> Hi Elwyn
> Where can I find the telechat details (time off call and phone #)?
>> 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.
> NFSv4.2 does not use the multi-principal assertion.
> —>Andy
>> 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 <>
>>> Subject: Re: rpcsec-gssv3
>>> Date: January 11, 2016 at 8:01:52 PM EST
>>> To: Benjamin Kaduk <>
>>> Cc: Stephen Farrell <>, "" <>, Spencer Dawkins <>, Martin Stiemerling <>, "Adamson, Andy" <>
>>> 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
>>> --