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