> On Jan 21, 2016, at 12:43 AM, Martin Stiemerling <[email protected]> wrote: > > 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.
OK. I’ll provide an updated doc —>Andy > > Thanks, > > Martin > > > Am 20.01.16 um 20:49 schrieb Adamson, Andy: >> >>> 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
