Yaron Sheffer writes: > Regarding identity protection, I now realize I don't understand the relevant > paragraph. The text is: > > Redirecting based on the unauthenticated identities might leak out > information about the user when active attacker can get information > to which gateway user was redirected to. If redirection is based on > some internal information of the user, it might leak information to > attacker about the user which might not available otherwise. To > protect against this kind of attack the redirection based on the ID > should happen only after client has also authenticated himself. > > If the information leak you are worried about is simply the name/address of > the redirected-to gateway,
Yes. > then this is available to a passive attacker as > well, by simply observing the client's next message. Not without client. I.e. this is to prevent probing attack. I.e. attacker gets employee list of email addresses for some company. He guesses that company uses email addresses as identities in IKEv2, and knows there is two GWs finance and development where all IKE connections will be redirected to when employee connects to the primary server. Attacker now simply makes IKEv2 connections to the primary server and claims to be user [email protected], where xxx is the first email address of the list. If primary server does redirection before authenticating the client, the attacker will get information to which GW this specific user [email protected] was forwarded to, i.e. he knows whether [email protected] is part of the finance departement or part of the development departement. This allows attacker new information which was not available for him beforehand, and will leave no trace to the company, as those connections to primary server are just normal redirected connections, and primary server will never notice that none of those connections actually resulted new connection to be taken to that server where they were redirecteed to. This is leaking information and for some reason some companies are very keen on keeping such information private, and if the company is such then it needs to make sure it does redirection only on the last IKE_AUTH response. If company does not care about the issue, it can redirect during IKE_SA_INIT or during first IKE_AUTH message. > Or were you thinking > specifically of an attacker sitting next to the gateway? No. > Also note that the last sentence contradicts our choice to allow redirects > at the first IKE_AUTH response (for EAP). It does not contradict, it says that if you want to keep that information secret then you should not redirect during first IKE_AUTH (for EAP). If you do not care about that information then feel free to redirect at any time... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
