|Main Archive Page > Month Archives > ipsec archives|
I'd like to reiterate my early message, which I haven't got answer to. My concerns are:
> Hi all,
> I found text describing preshared key authentication in IKEv2 a bit
> 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
> 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
> 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
> be known at the time of providing pre-shared key by user - it becomes
> only after IKE_SA_INIT exchange is finished. It is possible to compute
> 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
> I suspect that the latter is right answer, but this probably must be
> Valery Smyslov.