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

From: "Dave Thaler" <[email-masked]>
Date: Thu, 21 Mar 2002 12:15:34 -0800

Keith Moore writes:
> > Well, the original idea was to reserve a bit to indicate that the
> > address is Cryptographically Generaged Address (CGA), basically
> > meaning that
> >
> >     if the bit is set, then
> >        interface id = low64(hash(PK, stuff)) & mask
> >
> >     where
> >        PK      is a public key to be used as an identifier for the
host
> >        stuff   is contains other parameters (see the earlier
messages)
> >        hash    is a cryptographic hash function, e.g. SHA1
> >        low64   is a function that takes lowest 64 bits
> >        mask    indicates that we have to clear/set some bits of the
iid
> >
> > In essense, that would allow anyone to determine if a given public
> > key belongs to a host, just inspecting the public key, the address,
> > and the "stuff" above.  See e.g.
> 
> given that you need all of that "stuff" in order to verify the key
> anyway, why not make the CGA bit part of that "stuff" also?

Because that has a big security hole known as "bidding down".

A node receiving a packet from a spoofer, who can put whatever they
want in the packet, wants to verify one thing: that the packet was
sent by an entity which really "owns" (i.e. has a private key 
corresponding to) the source address, with extremely high probability.

For transition (and maybe other reasons), the receiving node wants to
also be able to communicate with nodes which do not do the above, and
hence 
needs to distinguish upon receipt of the packet in question whether it
should drop the packet because the "owner" of the source address
(which may or may not be reachable at that instant) would have
always included the authentication data, or not.  

Since a spoofer can construct any packet they like, and NOT include
any authentication data, a bit in the source address seems to be the
only way for a receiver who cares, to know whether to drop it (because
auth 
data is missing) or accept it (because it's a legacy insecure address).

-Dave
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Thu, 21 Mar 2002 21:51:22 +0100

I have three concerns about this CGA/KBA idea:
 - first this idea is about interface IDs, not addresses (so for Mobile
   IPv6 we need Return Routability too). Kempf's I-D about neighbor
   discovery is about real addresses and ABK (address based keys) which
   has not this and the last concerns.
 - second the verification implies an expensive crypto operation
   (typically a signature check) so the scheme is subject to trival DoS
   attack, especially if each packet has to be checked (so or a session
   key is negociated with an even more expensive and complex protocol,
   or the use of CGA/KBA is very limited).
 - last I don't believe you can manage real trust with only one bit
   and if you need more bits to negociate someting the IPv6 address
   will become quickly too small. IMHO this is a dead-end.
And please apply some "commercial" considerations to this kind of
schemes: if the burden is for someone and the benefit is for another one,
this shall never work in the real world.

Regards

[email-masked]

PS: Dave, this message has nothing to do with you...

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Mar 2002 23:27:45 +0200 (EET)

On Thu, 21 Mar 2002, Dave Thaler wrote:
> hence needs to distinguish upon receipt of the packet in question
> whether it should drop the packet because the "owner" of the source
> address (which may or may not be reachable at that instant) would have
> Since a spoofer can construct any packet they like, and NOT include any
> authentication data, a bit in the source address seems to be the only
> way for a receiver who cares, to know whether to drop it (because auth

What about the receiver having two IP-addresses, one for legacy and one 
for "secure-only" source addresses?

Then the receiver can at least be sure that the packets received at the
"secure" IP address would not be spoofed as they will always be verified.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Pekka Savola <[email-masked]>
Date: Thu, 21 Mar 2002 23:28:46 +0200 (EET)

>    will become quickly too small. IMHO this is a dead-end.

100% agree.

> this shall never work in the real world.

110% agree.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Mar 2002 23:59:49 +0200

>    or the use of CGA/KBA is very limited).

This issue can be handled. For an example in the mipv6 space, see
draft-roe-mobileip-updateauth-02.txt.

>    will become quickly too small. IMHO this is a dead-end.

Actually, I think a single bit is sufficient. Given that any

information can be included in the hash besides the public
key, the usage of the bit is not limited to the one who first
claims it. Of course, we probably would want to limit its use
but there are no technical problems in using the same hash scheme
for multiple purposes.

The same applies also to DNS-based and AAA-based schemes as well.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Mar 2002 23:17:00 +0100

>    or the use of CGA/KBA is very limited).
   
   This issue can be handled.

=> I don't believe without one of the two options in the parenthesis.

   For an example in the mipv6 space, see
   draft-roe-mobileip-updateauth-02.txt.
   
=> in this I-D all mechanisms build session keys (typically with a
Deffie-Hellman exchange, i.e. IKE-like).

=> infrastructure based systems don't need a bit per idea, sorry (:-).

PS: I am very unsatisfied by the result of today meeting: we are
going nowhere (which is not the same thing than not moving).
--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Thu, 21 Mar 2002 17:21:59 -0500

> auth data is missing) or accept it (because it's a legacy insecure 
> address).

yes, but an MitM can lie about the source address also, or launder
packets between the the real source and destination.  the source address 
is not much more reliably associated with the source than any other 
information that might be in a packet. 
--------------------------------------------------------------------
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]
--------------------------------------------------------------------