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

[Nicolas Williams <[e-mail]>]

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 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
-- 
_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4