[IPsec] Fw: Preshared key authentication in IKEv2

["Valery Smyslov" <[e-mail]>]

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" <[e-mail]>
To: <[e-mail]>
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.
>
>