Subject: RE: Allocating a bit in the RFC2374 Interface Identifier

From: "Glenn Morrow"<[email-masked]>
Date: Fri, 22 Mar 2002 13:57:48 -0600

Right,

So do people understand why having it in the address provides more
protection?

Now let's assume that we did not allow just RR, this would avoid the bidding
down attack IFF there was only one strong method. But I suspect there may be
more than one strong method and arguments as to which strong method is
better will fourish and the bidding down attack may still be protrayed as
being there between the strong mechanisms. 

Again this putting the bit in the address for extra protection may be in
question over and over, IMHO. I.e. if a field that indicates which strong
method to use is in place above the address then it can be alterred as well
using the same logic for the bit being in the address now.

> -----Original Message-----
> From: gabriel montenegro [mailto:[email-masked]]
> Sent: Thursday, March 21, 2002 9:23 PM
> To: Keith Moore
> Cc: Jari Arkko; Mohan Parthasarathy; Pekka Nikander; Pekka Savola;
> [email-masked]; Erik Nordmark
> Subject: Re: Allocating a bit in the RFC2374 Interface Identifier
> 
> 
> Keith Moore wrote:
> 
> > > Note that the MitM can also change the IP address, but if he does
> > > so, he is *not* attacking the original host, as the address is
> > > changed.
> >
> > unless of course the MitM can convince that host to take on 
> that address
> > as an alias.
> 
> So Mallory says that his address M is an alias for Alice's 
> address A. Ok.
> What if Bob looking at A could know (yes, signalled by a bit) that A
> it is only aliasable by very secure mechanisms. That's the 
> whole point.
> Mallory would then be forced to break any of several very strong
> (using crypto and explicit trust relationships) mechanisms:
> 
>     - AAA
>     - PKI
>     - CGA
>     - etc
> 
> RR would definitely not be included here.
> 
> -gabriel
> 
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Mar 2002 10:59:55 +0100

> Glenn Morrow wrote:
> 
> Right,
> 
> So do people understand why having it in the address provides more protection?

No. Quoting Pekka Nikander's original description of the bidding-down attack:

 Note that an active attacker at the path between Alice and Bob is able
 o clear a set bit.  However, that changes the address, and Alice is
 not going to answer to any possible replies sent by Bob.  Thus, the
 bit prevents the attacker from impersonating as Alice and fooling Bob
 to use the less secure protocol.

This doesn't satisfy me. If the attacker is capable of clearing the bit
in the source address of packets from Alice to Bob, it is equally capable
of setting the bit in the destination address of packets from Bob to Alice.
(The proof of concept here is every NAT box sold so far.)
So I don't see why the attacker can't conduct a complete bidding-down attack
in which Alice sees only packets with the bit set, and Bob sees only packets
with the bit cleared. Alice will believe she has asserted "strong security
available", Bob will believe the opposite, and both will be fooled.

   Brian
 
> Now let's assume that we did not allow just RR, this would avoid the bidding down attack IFF there was only one strong method.
> But I suspect there may be more than one strong method and arguments as to which strong method is better will fourish and the
> bidding down attack may still be protrayed as being there between the strong mechanisms.
> 
> Again this putting the bit in the address for extra protection may be in question over and over, IMHO. I.e. if a field that
> indicates which strong method to use is in place above the address then it can be alterred as well using the same logic for
> the bit being in the address now.
>

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 25 Mar 2002 21:49:09 +0200

Brian,

> available", Bob will believe the opposite, and both will be fooled.

I am tired, and probably the situation is more complex, but this my initial
reaction.  It looks like in the scenario you describe Alice and Bob
would end up running different protocols:  Alice the strong one, which
the attacker presumedly cannot break, and Bob the not-so-strong one,
which the attacker presumedly can break.  Thus, Bob would end up running
the not-so-strong protocol with the attacker, but the address used would
not be Alice's address.

But I start to believe that I am missing here things, and that the
reality is more complex than what we thought at the MIPv6 DT.  That is,
at least we need a mechanism for Alice to securely learn about the
mechanisms Bob supports.  Maybe we could use "the bit" here, too, but
my brains just fail to analyze what happens to the address-spoofing
MitM in that case; maybe you could perform the attack in both directions?
But would that matter?  If there is an attacker that can spoof packets
and break the less secure protocol, it can create security associations
with the less-secure protocol anyway, be there the legitimite peer or not.

Erik, Jari, or Gab, I guess it's your turn :-)

--Pekka Nikander

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Mar 2002 19:05:15 +0100

> the not-so-strong protocol with the attacker, but the address used would
It depends on how smart the MITM is, but I think in the simplest case,
Alice will hear from pseudo-Bob "I can't support strong security" (this
will be fabricated by the MITM) so she will be bid down, but Bob never knows
about this because he falsely believes that Alice can't support strong security.

But I'm also tired; jet lag hasn't completely gone yet :-)

> MitM in that case; maybe you could perform the attack in both directions?

Exactly

> with the less-secure protocol anyway, be there the legitimite peer or not.

Yes. There's a recursion here, and also a moral I think: don't allow weak
security, period.

   Brian