> > The point we are violently disagreeing on here is only the value of > using a distinct address format as the flag. The receiving > application > either requires a CGA address for validation or it doesn't. > There is no > inbetween here. If the receiver requires CGA for validation > and does not > have a matching PK, the connection will be rejected.
=> Just one point to clarify here. The bidding down attack can take place _before_ the node has a chance to send any pk. So the scenario you mention will only happen when there is no bidding down during the negotiation phase. The node does not necessarily send the pk in the first message. Hesham > > > > > If we do *not* do this distinction, a Man-in-the-Middle can claim, > > for *any* IP address, that CGA (or something similar) is not used. > > That reduces the security of all addresses to the same base line, > > effectively creating a situation where CGA (or similar) does not > > provide any additional value at all. Ergo, *something* > that divides > > the IP address set into two distinct sets *is* needed, or > otherwise > > CGA and related methods bring no additional value. > > The man-in-the-middle can't do anything if there are no bits to > manipulate. Either the reciever has a matching PK or it > doesn't. All it > has to do is check, and there is nothing that an attacker can do to > invalidate the process. > > > > > If everybody agrees that CGA (and any security that is *not* based > > on an external infrastructure but on "intrinsic cryptography") > > is a bad idea, then fine with me. Let's forget this discussion. > > But then we are effectively saying that > zero-configuration security > > is a bad idea and we don't want it. > > I am not saying that CGA is a bad idea. On the contrary it > is a great > idea. All I am pointing out is that we don't need anything more than > RFC3041 to accomplish it. > > > > > Thus, this all is really about zero-configuration security. Such > > security, by nature, is never "strong" by the strict definition of > > strong, but it can be *much* stronger than the current no-security > > situation. Basically, such security can provide quite a lot of > > defence against various DoS attacks. > > > > This two-address-space thing is only required for those recipients > > that support both the current nodes with no understanding about > > zero-conf security and the future nodes that do care > about zero-conf > > security. As I noted before, it requires that the > initiator commits > > a priori either to the "weak" method or the "strong" method. > > I am sorry, but this is misguided. Current nodes will never > care about > CGA, so they won't try to verify them. New nodes can verify the > addresses, so they know the originator either cared because the CGA > matched, or didn't care or was incapable of generating a > CGA. In either > case it has the appropriate info to decide to accept or reject. > > > > > The details differ, quite a lot in fact, depending on whether > > we speak about MIPv6 or something else, e.g. secure Neighbor > > Discovery. > > But the same need: dividing the address space into two > distinct sets, > > is there. Or at least that is my current understanding. > Maybe I am > > wrong. > > > > Personally, I do not believe that any bold statements help here. > > At least to me, this whole zero-conf security business is so new > > that at least I need to have very humble attitude here. I learn > > new issues all the time. On the other hand, IMHO we really want > > to go towards zero-conf security. And if we do, we need some kind > > of transition mechanism. Dividing the IPv6 address space seems to > > serve as an important piece of such a transition mechanisms. > > > > Of course, there are different ways of dividing the IPv6 address > > space. If everybody thinks that using a bit in the IID is a bad > > idea, then maybe we should consider distinct routing prefixes for > > mobile hosts, and distinct link local addresses for secure ND. > > All that is doing is asking for a set of bits. Bits are not > the problem > here. The receiver has to check for CGA validation if it cares, so > adding bits does not help. > > Tony > > > > > --Pekka > > > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
