ramaswamy writes: > Proposed new negotiations > > Before initial exchange begins initiator looks up to the pre shared > secret with the intended responder and does the hash value on first > half of pre shared secret, nonce of the initiator. Once the > responder receives the request it looks up the correspondence pre > shared key in its table and it takes the nonce form initiator > request message then it does a hash value to authenticate the > initiator.
This is bit like how IKEv1 did it, and it has same problem than IKEv1 had with that, meaning it does not provide ANY identity protection at all. The responder needs to find the pre-shared key for the initiator based only with the information that are in the first IKE_SA_INIT packet. This DOES NOT include identity of the initiator, and SAi1, KEi, and Ni does not help at all in this process. The only information that responder has which it can use is the source IP-address of the IKE_SA_INIT packet. This has the effect that the pre-shared key will be tied to the source IP-address of the initiator, which mean every passive listener will also see that same IP-address and will know the identity of the initiator. The method in IKEv2 where the PSK is not tied to the IP-address of the initiator offers much better identity protection, as now the responder identity is only releaved to the active attacker. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
