Date: Sun, 3 Aug 2014 02:04:31 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: "Adamson, Andy" <William.Adamson@netapp.com>
In-Reply-To: <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com>
Message-ID: <alpine.GSO.1.10.1408030153400.21571@multics.mit.edu>
References: <DC941FEB-725A-49E1-8C38-FF765454827C@netapp.com>
 <20140730163006.GG26316@fieldses.org>
 <alpine.GSO.1.10.1407311902230.21571@multics.mit.edu>
 <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
 BOUNDARY="-559023410-691950968-1407045871=:21571"
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/52ekwOefQlryBkYNexRyDwljSCA
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
 "kitten@ietf.org" <kitten@ietf.org>, NFSv4 <nfsv4@ietf.org>
Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review
Precedence: list

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-691950968-1407045871=:21571
Content-Type: TEXT/PLAIN; charset=Windows-1252; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Fri, 1 Aug 2014, Adamson, Andy wrote:

>
> On Jul 31, 2014, at 7:10 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
>> On Wed, 30 Jul 2014, J. Bruce Fields wrote:
>>
>>
>>> The RPCSEC_GSS_CREATE request should demonstrate that the caller knows
>>> both parent and child's credentials.  That's easy for the parent since
>>> an RPCSEC_GSS_CREATE request is also just an ordinary RPCSEC_GSS reques=
t
>>> sent as the parent.
>>>
>>> For the child the caller has to calculate the mic of a nonce using the
>>> child context, but as far as I can tell the choice of nonce is entirely
>>> up to the caller.
>>>
>>> Couldn't it then just choose as the nonce some data that it had
>>> previously seen a mic for?  If so, would it work to remove the nonce an=
d
>>> instead calculate, say, a mic of the rpc header (as we do when
>>> calculating the verifier?).
>>
>> Certainly it would help to include (something with) the sequence=20
>> number, as a proof of "liveness".  We may have to brainstorm a bit.
>
> I have always thought of Multi-principal authentication in terms of it=92=
s=20
> use in NFSv4.2 Inter server to server copy, where all of the=20
> RPCSEC_GSS_CREATE messages MUST use rpc_gss_svc_privacy=92=85. Good catch=
=20
> Bruce.
>
> So for this attack to occur the rgmp_nonce must be re-used by the same=20
> rgmp_handle (same user-principal). Insisting on using a random number=20
> generator to create nounce could be by-passed by a bad implementation...
>
> Bruces suggestion of using the new reply verifier data (rpc-header)=20
> should do the trick. Any objections to this approach?
>
>>
>>> The reply is already authenticated as
>>> the parent, the problem again is authenticating as the child
>
> You must mean the Multi-principal =93inner=94 handle.
>
> There is no =93child=92 as the child handle is the result of the successf=
ul=20
> RPCSEC_GSS_CREATE call, and we are defining how success is determined.
>
>
>>> , so I think
>>> it should be calculating a mic using the child context (maybe over the
>>> header data again, as in section 2.3?).
>
> The child handle is varified on the target (server) by a successful=20
> GSS_VerifyMIC using the user-principal GSS context and the nounce. This=
=20
> exchange is the target
>>
>
>> In particular, the server could decline to validate the nonce-MIC at=20
>> all, and grant access to anyone who claimed to be the user; we must=20
>> trust that it does the verification properly.  (A proper verification=20
>> confirms that the server does have a valid context handle for the inner=
=20
>> context.)
>
> Correct, and that verification is noted in the sentence prior to the=20
> quote above - this obviously could be clearer. I could separate the two=
=20
> verifications into two paragraphs.
>
>   The target verifies the multi-principal authentication by verifying
>   the rgmp_nouce_mic.

I'm not sure we're all on the same page about the concerns about the=20
"inner" RPCSEC context handle of the multi-principal authentication.

If I understand correctly, the child RPCSEC contex handle will use the=20
same GSS context as the parent RPCSEC context handle (i.e., using the=20
host's credentials, not the user's credentials).  This means that when=20
creating the child RPCSEC context, there must be some proof that the RPC=20
client controls the GSS context corresponding to the inner RPCSEC context=
=20
handle, since the child RPCSEC context will perform operations acting as=20
the user specified by the GSS context of the inner RPCSEC context.

My reading of the current draft is that the only attempt to do this is by=
=20
presenting a random nonce and a GSS_GetMIC of that nonce, created using=20
the GSS context of the inner RPCSEC context.  The server must verify that=
=20
the MIC is a valid mic, but I do not see any other binding to this GSS=20
context.  In particular, the nonce+MIC could be eavesdropped on the wire,=
=20
and inserted into an attacker's RPCSEC_GSS_CREATE call, where the attacker=
=20
provides its own parent RPCSEC context but does not actually have an inner=
=20
context at all.  The attacker can reuse the valid nonce+MIC that it has=20
intercepted, which will validate correctly on the server, and the server=20
will issue a child RPCSEC context that acts as the user indicated by the=20
GSS context of the inner RPCSEC context but uses the key material from the=
=20
attacker's GSS context.

-Ben
---559023410-691950968-1407045871=:21571--