Re: [nfsv4] Last call start for "RPCSEC_GSS Version 2"

["Mike Eisler" <[e-mail]>]

On Fri, June 13, 2008 5:26 pm, Nicolas Williams wrote:
> On Fri, Jun 13, 2008 at 01:35:46PM -0700, Mike Eisler wrote:
>>
>> On Fri, June 13, 2008 12:00 pm, Nicolas Williams wrote:
>> > On Mon, Jun 02, 2008 at 11:30:43PM -0500, Spencer Shepler wrote:
>> >> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rpcsec-gss-v2-03.txt
>> >
>> > There's a rather minor, but easy to fix attack on RPCSEC_GSSv2 as
>> > described in -03.
>> >
>> > I started wondering what kind of games an attacker could play with the
>> > RPCSEC_GSS version number.  I think an MITM could modify RPCs from a
>> v1
>> > client, talking to a v2 server, to set the RPCSEC_GSS version to 2,
>> and
>> > in the process obtain a few MICs that it might, by sheer luck, cause
>> the
>> > server to accept in the channel binding portion of the protocol.
>>
>> I'm not seeing it. The MIC in the verifier of both v1 and v2
>> of RPCSEC_GSS is compute from the RPC header "up to and including
>>       the credential"
>
> The version number in the context token exchange messages is not
> protected.
>
> So:
>
>  - a v1 client
>  - an MITM
>  - a v1 and v2 server
>
>  - the MITM intercepts the client's v1 context token messages and
>    changes the version number to 2 before forwarding to the server, and
>    changes the version number back to 1 in the replies from the server
>
>     - neither the client nor the server notice
>
>  - eventually the context is established and the client sends its first
>    RPC protected by the established handle
>
>     - this RPC is bound to fail since the verifier MIC'ed data includes
>       the credential, which includes the RPCSEC_GSS version number
>
>     - but the MITM is an optimist, and so the MITM formats an
>       RPCSEC_GSS_BIND_CHANNEL RPC using the verifier from the client's
>       RPC, and then forwards this to the server in the hopes that
>       there's a collision
>
>        - most likely the MITM's RPC fails, so the MITM send back garbage
> 	 to the client and hopes the client will try again
>
>        - lather, rinse, repeat until collision happens, at which point
> 	 the MITM closes the connection to the client and then proceeds
> 	 to impersonate the client to the server, since at this point
> 	 the handle is bound to the MITM's channel with the server.

The MIC is 128 bits or more right? Isn't this is a 1 in 2^128
chance of collision? It seems to me that any solution one designs
is going to prone to this.

We could require that RPCSEC_GSS_BIND_CHANNEL send GSS_Wrap()'ed content
in the credential of the request, and the verifier of the response. Since
the credential is somewhat larger than 128 bits, this makes it more
difficult for the MITM to forge a RPCSEC_GSS_BIND_CHANNEL that contains
mostly ciphertext.
>
> The client sees lots of failures, perhaps, from its p.o.v., due to
> network problems.
>
> The server sees lots of failures too.  But finnally a success.
>
>> Since the credential contains the RPCSEC_GSS version number (field
>> rgc_version below) the RPCSEC_GSS target will reject the MITM's
>> modified RPCs.
>
> The version number in the context token exchange is the one that must be
> protected.
>
> Nico
> --
>


-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/



_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4