Well, I find the attack laughable. But anyway, if it takes 5 paragraphs to explain this one paragraph, I guess better clarification is in order.
Thanks,
Yaron
> -----Original Message-----
> From: Tero Kivinen [mailto:[email protected]]
> Sent: Monday, May 18, 2009 12:01
> To: Yaron Sheffer
> Cc: Vijay Devarapalli; [email protected]
> Subject: Re: [IPsec] Redirect -09 comments
>
> 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]
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
