RE: SKEYSEED in IKEv2

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

Satish,

The reason for not using a fixed key-id is that the key-id then becomes an
"identity equivalent". So once the attacker figures out that
u234352934=kumar_amara@yahoo.com, he can find out when you are logging on no
matter what IP you use.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.

-----Original Message-----
From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On
Behalf Of SatishK Amara
Sent: Sunday, March 24, 2002 4:53 PM
To: andrew.krywaniuk@alcatel.com
Cc: ipsec@lists.tislabs.com
Subject: RE: SKEYSEED in IKEv2


Andrew,
In IKEv2 I think identity protection can be provided by having an optional
key-id field in
message1 to identify the preshared key.  If the optinal key-id field is
present then the
shared secret will be based on DH and preshared key.  Any thoughts ...

  Andrew Krywaniuk <andrew.krywaniuk@alcatel.com> wrote:
> I am just wondering what is the reason for SKEYSEED in
> IKEv2 is based on only Nounce and DH parameters. In IKEv1 it
> is calculated differently depending upon preshared keys,
> signatures or public key encryption. In case of preshared key
> in IKEv1 by doing so we can protect the identities of both
> parties from active attack. But this is not possible in IKEv2 ...

Your assumption is incorrrect.

In IKEv1, the preshared key mode contained a special optimization in order
to make the key subjectively "better" (because the attacker could not derive
the session key even if he could crack the DH -- he would also have to crack
the preshared key). This is an additional security measure that it not
present in the PK signatures mode of IKE.

However, this feature has several drawbacks:

- When using main mode, the identity of the intitiator must be implicit from
the IP.
- When the initiator is a roaming client, the identity must be sent in the
clear (because it acts as an index for the key lookup).
- When the preshared key is wrong, the responder cannot send a meaninful
error message.

So as you can see, contrary to your suggestion, this feature of IKEv1
actually makes identity protection quite impossible when using pre-shared
keys, since the identity must either be sent on the wire or it must be
implicit from the key. A third option is to use a global pre-shared key, in
which you get the perverse situtation where you have identity protection but
you can't trust the id because it is too easy to forge.

If, for whatever reason, you absolutely need identity protection of the
initiator against an active attack, your best bet would be to implement a
private extension in which the id is changed on each successive login. For
example, you could make a session-based id by hashing an unpredictable
string together with a nonce or counter.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.






Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®