Telechat Review of draft-ietf-nfsv4-rpcsec-gssv3-15

Request Review of draft-ietf-nfsv4-rpcsec-gssv3
Requested rev. no specific revision (document currently at 17)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-01-19
Requested 2016-01-07
Authors Andy Adamson, Nicolás Williams
Draft last updated 2016-01-22
Completed reviews Genart Last Call review of -13 by Elwyn Davies (diff)
Genart Telechat review of -15 by Elwyn Davies (diff)
Secdir Telechat review of -14 by Radia Perlman (diff)
Opsdir Last Call review of -13 by Victor Kuarsingh (diff)
Assignment Reviewer Elwyn Davies 
State Completed
Review review-ietf-nfsv4-rpcsec-gssv3-15-genart-telechat-davies-2016-01-22
Reviewed rev. 15 (document currently at 17)
Review result Ready
Review completed: 2016-01-22


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

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:

> From: Nico Williams <nico at>
> Subject: Re: rpcsec-gssv3
> Date: January 11, 2016 at 8:01:52 PM EST
> To: Benjamin Kaduk <kaduk at>

> Cc: Stephen Farrell <stephen.farrell at>, "sec-ads at" 

<sec-ads at>, Spencer Dawkins <spencerdawkins.ietf at>, 

Martin Stiemerling <mls.ietf at>, "Adamson, Andy" 

<William.Adamson at>

> 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
> --