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

From: Elwyn Davies <[email-masked]>
Date: Sat, 16 Jan 2016 18:15:21 +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 <[email-masked]>
 > Subject: Re: rpcsec-gssv3
 > Date: January 11, 2016 at 8:01:52 PM EST
 > To: Benjamin Kaduk <[email-masked]>
 > Cc: Stephen Farrell <[email-masked]>, "[email-masked]" 
<[email-masked]>, Spencer Dawkins <[email-masked]>, 
Martin Stiemerling <[email-masked]>, "Adamson, Andy" 
<[email-masked]>
 >
 > 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
 > --

---

From: "Adamson, Andy" <[email-masked]>
Date: Wed, 20 Jan 2016 19:49:26 +0000

> On Jan 16, 2016, at 1:15 PM, Elwyn Davies <[email-masked]> wrote:
> 

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
> 
> > Cc: Stephen Farrell <[email-masked]>, "[email-masked]" <[email-masked]>, Spencer Dawkins <[email-masked]>, Martin Stiemerling <[email-masked]>, "Adamson, Andy" <[email-masked]>
> >

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 21 Jan 2016 06:43:25 +0100

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.

Thanks,

   Martin

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 21 Jan 2016 15:18:07 +0000

> On Jan 21, 2016, at 12:43 AM, Martin Stiemerling <[email-masked]> wrote:
> 
> Hi Andy,
> 
> 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?
> 

OK. I’ll provide an updated doc

—>Andy

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 22 Jan 2016 16:18:48 +0000

Hi, Andy.

Thanks for the update.

Version 16 is fine by me - all done.

As regards minorversion2, I'm afraid I misunderstood the implications 
(or otherwise) of the discussions of multiple principals.  As you say, 
minorversion2 doesn't use the multiprincipal option.

Regards,
Elwyn

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 22 Jan 2016 16:25:15 +0000

> On Jan 22, 2016, at 11:18 AM, Elwyn Davies <[email-masked]> wrote:
> 
> Hi, Andy.
> 
> Thanks for the update.

Hi Elywn
> Version 16 is fine by me - all done.

Good - Thanks again for all the help. You really cleared up sections of the draft.

> 
> As regards minorversion2, I'm afraid I misunderstood the implications (or otherwise) of the discussions of multiple principals.  As you say, minorversion2 doesn't use the multiprincipal option.

At one time, NFSv4.2 did use the multi-principal assertion…...

—>Andy