> On Jan 16, 2016, at 1:15 PM, Elwyn Davies <[email protected]> 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 <[email protected]> > > Subject: Re: rpcsec-gssv3 > > Date: January 11, 2016 at 8:01:52 PM EST > > To: Benjamin Kaduk <[email protected]> > > Cc: Stephen Farrell <[email protected]>, "[email protected]" > > <[email protected]>, Spencer Dawkins <[email protected]>, Martin > > Stiemerling <[email protected]>, "Adamson, Andy" > > <[email protected]> > > > > 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
