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 PROTECTED]
--------------------------------------------------------------------

Reply via email to