Hi Satish,
I read Appendix A of the spec you sent me. Yes, you are correct that you can guard against an active attack to obtain the initiator's identity if you use a frequently chaning key_id. I didn't mention this before, because most people who have talked about using the key_id in the past were advocating a static key_id.
You are correct that IKEv2 does not address this issue, but if you want to be resistant to this attack then maybe what you should do is to just not have the initiator send the identity at all, since it should be implicit from the key_id (and the responder is supposed to know what the binding is).
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.
Andrew,
Please find the attachment for 3GPP2 Wireless IP Standard. The standard proposes a method to dynamically configure preshared keys and use key-id to identify the preshared key. The preshared key will be changed freqently and so key-id ....
Satish
Andrew Krywaniuk <andrew.krywaniuk@alcatel.com> wrote:
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 presha! red key. If the optinal key-id fie ld is
present then the
shared secret will be based on DH and preshared key. Any thoughts ...
Andrew Krywaniuk 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 f! eature has several drawbacks:
< BR>- 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 successiv! e 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®
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®