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 protected]>
To: <[email protected]>
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.
>
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
