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

["Adamson, Andy" <[e-mail]>]

> On Jan 22, 2016, at 11:18 AM, Elwyn Davies <[e-mail]> 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

> 
> Regards,
> Elwyn
> 
> On 20/01/2016 19:49, Adamson, Andy wrote:
>>> On Jan 16, 2016, at 1:15 PM, Elwyn Davies <[e-mail]> 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
>>> 
>>> <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
>> 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 <[e-mail]>
>>>> Subject: Re: rpcsec-gssv3
>>>> Date: January 11, 2016 at 8:01:52 PM EST
>>>> To: Benjamin Kaduk <[e-mail]>
>>>> Cc: Stephen Farrell <[e-mail]>, "[e-mail]" <[e-mail]>, Spencer Dawkins <[e-mail]>, Martin Stiemerling <[e-mail]>, "Adamson, Andy" <[e-mail]>
>>>> 
>>>> 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
>>>> --
>>> 
>