Subject: [IPsec] Fw: Preshared key authentication in IKEv2

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 30 Oct 2009 09:58:44 +0300

Hi all,

I'd like to reiterate my early message, which I haven't got answer to.
My concerns are:

1. How padding pre-sahred key with string "Key Pad for IKEv2"
    could help to avoid storing pre-shared key in IKE implementation
    if prf is not known untill IKE_SA_INIT exchange is finished?
2. It is a bit unclear whether EAP generated key should also
    be padded before use in IKE, or used directly.

Thanks,
Valery Smyslov.

----- Original Message -----
From: "Valery Smyslov" <[email-masked]>
To: <[email-masked]>
Subject: [IPsec] Preshared key authentication in IKEv2

> Hi all,
>
> I found text describing preshared key authentication in IKEv2 a bit
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 shared key 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 strange, because which prf should be used
cannot
> be known at the time of providing pre-shared key by user - it becomes
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, I think, 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( SK_p*, "Key Pad for
> IKEv2").
> I suspect that the latter is right answer, but this probably must be
written
> excplicitly.
> Regards,
> Valery Smyslov.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 30 Oct 2009 10:04:55 -0700

>    if prf is not known untill IKE_SA_INIT exchange is finished?

The PRF (or set of PRFs) is known by the receiving party. If the two parties always only use one PRF, it is known. The padding is not a universal solution for the reasons you give, but it works in the common case of peers who know each other's crypto choices.

>    be padded before use in IKE, or used directly.

I'm pretty sure the key is used in its PRF form, not in its "as is" form, but I would want to hear from one or two implementers on that.

--Paul Hoffman, Director
--VPN Consortium