Subject: [IPsec] Redirect -09 comments

From: Yaron Sheffer <[email-masked]>
Date: Thu, 14 May 2009 08:01:15 +0300

Hi,

While preparing to progress the draft to AD review, I reread it once again.
Here are a few comments. Although not all are nits, none of them should
block the document now.

Thanks,

            Yaron

Not-quite-nits:

General: a long way back we discussed loop avoidance, but this never made
its way into the draft. The document implicitly allows multiple redirections
in sequence. We should specify somewhere that the client MUST have a
threshold value X (possibly 1), where it is willing to redirect at most X
times in sequence. This is meant to deal with faulty configuration, not with
active attacks.

9. I believe the last sentence "To protect against this kind of attack the
redirection based on the ID should happen only after client has also
authenticated himself." should read "after the *gateway* has also
authenticated itself".

10. Please add at the end of the section: A specification that extends this
registry MUST also define in which notification(s) the new values are
allowed.

Nits:

1. "connect to the IP address of the VPN gateways", change "gateways" to
"gateway".

3. "In practice, this means the new gateway either", remove one "either".

6. mesage -> message

6. "presented by the client in the first IKE_AUTH exchange itself." - this
text is duplicated.

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 15 May 2009 14:30:39 -0700

Hi Yaron,

On 5/13/09 10:01 PM, "Yaron Sheffer" wrote:

> Here are a few comments. Although not all are nits, none of them should block
> the document now.
>  
> Thanks,
>             Yaron
>  
> Not-quite-nits:
>  
> General: a long way back we discussed loop avoidance, but this never made its
> way into the draft. The document implicitly allows multiple redirections in
> sequence. We should specify somewhere that the client MUST have a threshold
> value X (possibly 1), where it is willing to redirect at most X times in
> sequence. This is meant to deal with faulty configuration, not with active
> attacks.

I added the following text to the Security Considerations section.

  The client could end up getting redirected multiple times in a
  sequence, either because of wrong configuration or a DoS attack. The
  client could even end up in a loop with two or more gateways
  redirecting the client to each other. This could deny service to the
  client. To prevent this, the client should be configured not to
  accept more a certain number of redirects within a short time
  period. This should be configurable on the client.

Freel free to modify the text.
  
> authenticated himself." should read "after the *gateway* has also

Hmm.. This is about revealing information about the user. So I don't see how
this can be avoided if the gateway is authenticating itself.
  
> registry MUST also define in which notification(s) the new values are allowed.
>  
> Nits:
>  

Fixed all of the above. Thanks.

Vijay

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 17 May 2009 00:37:04 +0300

Hi Vijay,

Regarding loop avoidance, please use RFC 2119, capitalized should's.

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, then this is available to a passive attacker as
well, by simply observing the client's next message. Or were you thinking
specifically of an attacker sitting next to the gateway? 

Also note that the last sentence contradicts our choice to allow redirects
at the first IKE_AUTH response (for EAP).

Thanks,
	Yaron

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Saturday, May 16, 2009 0:31
> To: Yaron Sheffer; [email-masked]
> Subject: Re: [IPsec] Redirect -09 comments
> 
> Hi Yaron,
> 
> block
> Scanned by Check Point Total Security Gateway.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 May 2009 12:00:43 +0300

Yaron Sheffer writes:
> 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-masked], 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-masked] was forwarded to, i.e. he knows
whether [email-masked] 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

No.

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

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 18 May 2009 15:58:05 +0300

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

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Monday, May 18, 2009 12:01
> To: Yaron Sheffer
> Cc: Vijay Devarapalli; [email-masked]

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 18 May 2009 14:20:59 -0400

Hi Yaron,

> From: Yaron Sheffer [mailto:[email-masked]] 
> Sent: Saturday, May 16, 2009 2:37 PM
> To: Vijay Devarapalli; [email-masked]
> Subject: RE: [IPsec] Redirect -09 comments
> 
> Hi Vijay,
> 

Conversational English is ok sometimes. We don't always have to use
SHOULDs and MUSTs. Using RFC 2119 terminology becomes important only if
it affects interoperability between two nodes. In this particular case,
we are talking about configuration on the client not to accept too many
redirects within a short period of time. It should throw an exception
which might require manual intervention. There is no need to use
"SHOULD" or "MUST" here.

FWIW, RFC 2460 (the main IPv6 specification) does not use "SHOULD" or
"MUST" anywhere in the entire document.

> specifically of an attacker sitting next to the gateway? 

I will let Tero respond to this. He had proposed this paragraph. I
didn't see any harm in including text about this attack.

Vijay

> > > While preparing to progress the draft to AD review, I 
> reread it once
> > again.
> > > General: a long way back we discussed loop avoidance, but 
> this never
> > made its
> > > way into the draft. The document implicitly allows 
> multiple redirections
> > in
> > > sequence. This is meant to deal with faulty 
> configuration, not with
> > active
> > > attacks.
> > 
> > > 9. I believe the last sentence "To protect against this 
> kind of attack
> > the
> > Hmm.. This is about revealing information about the user. 
> So I don't see
> > how
> > > 10. Please add at the end of the section: A specification 
> that extends
> > this
> > > 6. "presented by the client in the first IKE_AUTH 
> exchange itself." -
> > this
> > > text is duplicated.
> >