Subject: [IPsec] Handling Redirect Loops

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 29 Jul 2009 15:32:54 -0700

Hello,

During the IESG review of draft-ietf-ipsecme-ikev2-redirect, it was brought
up that the text about handling redirect loops should be in the main body of
the draft instead of the security considerations section. One of the ADs
also wanted some default values to detect a loop. Here is the modified text.
The changes to the original text are minor, basically adding the default
values and using "SHOULD" and "MUST" (RFC 2119 language).

7.  Handling Redirect Loops

   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 than a certain number of redirects (MAX_REDIRECTS) within
   a short time period (REDIRECT_LOOP_DETECT_PERIOD) for a particular
   IKEv2 SA setup.  The default value for MAX_REDIRECTS configuration
   variable is 5.  The default value for REDIRECT_LOOP_DETECT_PERIOD
   configuration variable is 300 seconds.  These values MUST be
   configurable on the client.

Please let me know if any one has comments on this.

Vijay

---

From: Yoav Nir <[email-masked]>
Date: Thu, 30 Jul 2009 07:13:57 +0300

Hi Vijay.

"default" is usually associated with a particular implementation or product. I think it would be better to say "suggested value" rather than "default value". Also, I don't see a point in mandating that all products should have an extra knob for setting this value. For example, for an IKEv2 client you usually try to have as little local configuration as possible, so this value may very well be hard coded.

                    The suggested value for MAX_REDIRECTS configuration
   variable is 5.  The suggested value for REDIRECT_LOOP_DETECT_PERIOD
   configuration variable is 300 seconds.  These values MAY be
   configurable on the client.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
Sent: Thursday, July 30, 2009 1:33 AM
To: [email-masked]
Subject: [IPsec] Handling Redirect Loops

Hello,

Vijay

Email secured by Check Point

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 29 Jul 2009 22:00:13 -0700

Hi Yoav,

On 7/29/09 9:13 PM, "Yoav Nir" wrote:

> Hi Vijay.
> 
> "default" is usually associated with a particular implementation or product. I
> think it would be better to say "suggested value" rather than "default value".

"default value" is the right terminology to use here.

> Also, I don't see a point in mandating that all products should have an extra
> knob for setting this value. For example, for an IKEv2 client you usually try
> to have as little local configuration as possible, so this value may very well
> be hard coded.
> 

If you want to change it "MAY", you might as well say nothing about it. A
sentence that says "These values MAY be configurable on the client" doesn't
say much. I would be fine with "SHOULD" instead of "MUST".

Vijay

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 30 Jul 2009 11:36:22 +0300

>    configurable on the client.

Is there really any reason to have the last "MUST" I.e. what is the
reason to force those parameters to be changeable? I do not really see
reason to change those in most cases, and if someone really uses some
really wierd setup where 5 is not enough for the max redirects, then
he can use some implementation where those are configurable...
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 30 Jul 2009 11:55:36 +0300

Vijar Devarapalli wrote:

>> "default" is usually associated with a particular implementation or
>> product. I think it would be better to say "suggested value" rather 
>> than "default value".
>

Disagree. A default is what you get in a particular implementation if you don't change it. For example, IKE SA default lifetimes are 2 hours in Check Point products, and 8 hours in Microsoft products. A standard cannot have a default.

>> Also, I don't see a point in mandating that all products should have an
>> extra knob for setting this value. For example, for an IKEv2 client you
>> usually try to have as little local configuration as possible, so this
>> value may very well be hard coded.
>> 

Disagree again. No client will have this configuration, because clients are made to be used by non-technical people. Clients that are centrally-configured may have such a setting, but we can't put that in a MUST, or even a SHOULD.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 30 Jul 2009 14:54:38 -0700

> he can use some implementation where those are configurable...

Modified the last sentence to

  Client implementations may allow these variables to be
  configured depending on a specific deployment or system
  configuration.

Vijay

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 31 Jul 2009 11:58:29 +0400

Hi all,

I found text describing preshared key authentication in IKEv2 confusing.

First, in section 2.15 four different terms are used: "shared secret",
"Shared Secret" (with capital letters), "shared key" and "pre-shared key".
This is a bit confusing, especially taking into consideration that terms
"shared keys" and "shared secret" are also used in the draft for SK_* and
result of ephemeral Diffie-Hellman exchange. I'd propose to use
only one term, "pre-shared key".

Then, in section 2.15 the very first sentence states:

     When not using extensible authentication (see Section 2.16), the
     peers are authenticated by having each sign (or MAC using a shared
     secret as the key) a block of data.

But in the last paragraph of this section it is shown, that not sole "shared
secret"
is used as the key, but the following construction:

    prf( Shared Secret,"Key Pad for IKEv2")

So, the first sentence of 2.15 is misleading.

Then, the following rationale for padding is given:

     The pad string is added so that if the shared secret is derived from a
     password, the IKE implementation need not store the password in
     cleartext, but rather can store the value prf(Shared Secret,"Key Pad
     for IKEv2"), which could not be used as a password equivalent for
     protocols other than IKEv2.

I found this rationale a bit weired, because which prf should be used cannot
be known at the time of entering pre-shared key - it is known only after
IKE_SA_INIT exchange is finished. It is possible to compute values
for all possible prfs, but this doesn't work in all cases - for example
in case of pluggable crypto. So, in general, storing of "Shared
Secret"/password
in unavoidable.

And last, but not least. The following section 2.16, describing
authentication
with EAP, states:

     For EAP methods that create a shared key as a side effect of
     authentication, that shared key MUST be used by both the initiator
     and responder to generate AUTH payloads in messages 7 and 8 using the
     syntax for shared secrets specified in Section 2.15.

and later:

     If EAP methods that do not generate a
     shared key are used, the AUTH payloads in messages 7 and 8 MUST be
     generated using SK_pi and SK_pr, respectively.

It is a bit unclear, whether these shared secrets (EAP generated or SK_p*)
must be used as key "as is", or as  prf( Shared Secret, "Key Pad for
IKEv2").
I suspect that the latter is right answer, but this probably must be written
excplicitly.

Regards,
Valery Smyslov.