Re: [DNA] Small security flaw in Hash FastRA (with proposal)

[Christian Vogt <chvogt@tm.uka.de>]

Greg,

this is an important observation.  I have one comment about your
proposed solution:

Your approach is based on randomizing the XOR input that comes from the
MN.  Given that your proposed security solution is based on SEND, how
about verifying the XOR input that comes from routers?

Specifically, a router identifies neighboring routers by listening to
transmitted RAs.  Currently, it accepts all received RAs.  But if SEND
is used, that router could drop received RAs if they cannot be
authenticated to originate from a legitimate router.  The router would
thus ignore the attacker's FastRA token when doing the XOR.

This approach should have an effect comparable to your proposed solution
(unless I am missing something).  Yet, the order of transmitted RAs
would not change due to randomization.

What do you think?

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/



Greg Daley wrote:
> 
> Hi All,
> 
> There's a small security flaw in Hash FastRA which
> can be used to force all routers to respond
> more slowly than the bogus router for a particular
> solicitor.
> 
> With an initially passive attacker, the host can identify
> all good routers on the link, and identify which of
> the routers will be the first responder, by XORing
> each of the routers' hashes with that of the host,
> and then generating new addresses whose XORs beat
> the leader.
> 
> This takes on average O(2^L) passive address generations
> where L is the number of leading one bits in the best
> router's XOR.  For a small number of routers, this is
> likely to be achieveable, with limited computational
> cost for an attacker.
> 
> This can be improved greatly for SEND hosts if any
> Nonce received in a solicitation is incorporated into
> the soliciting Host's hash generation.
> 
> This will change the hashed value for each incoming RS
> and consequently randomize the XOR values for the
> responding routers.
> 
> No router or host will be able to predict which responder
> will be first, until the RS is received.
> 
> Original Host token generation:
> 
> left_64(SHA-1( host link-local address  ))
> 
> Modified Host token generation:
> 
> left_64(SHA-1( host link-local address, Nonce  ))
> 
> Hosts which don't send Nonces (non-send hosts?) don't
> receive the benefit.
> 
> This is detailed in my thesis (not yet submitted :-/ )
> but I'm placing it here now because it may be important
> to consider as people are assuming predictable scheduling
> for all of a host's received RAs.
> 
> Greg

--------------enig3527CF4CA7948099E5A62557
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFERAfhwstEk8gl2rURAqInAKCLV1sXqSGW3Ov2riAfWcdmCoQjjwCdGGhX
fVoZbOba6dwu7vYyq92A7rI=
=Exdb
-----END PGP SIGNATURE-----

--------------enig3527CF4CA7948099E5A62557--