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.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
