[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKEv2: active user identity protection



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tero,

Tero Kivinen wrote:
| Jesse Alpert writes:
|
|>2. The polling attack mentioned below is of little concern in an EAP
(remote
|>access) scenario - the server is usually well known and the client should
|>not
|>respond to EAP phase 1 exchanges.
|
|
| Not all of the server addresses are globally well known. Some people
| for example do not put security gateways address to dns, and configure
| those so that they do not reply to anything than valid requests etc,
| so it makes harder for attackers to find those (i.e security by
| obscurity). This does not offer real security, but some people do want
| to have that kind of features. They do not like the idea that they
| need to give out proof that this is roadwarrior-sgw.company.com to all
| connections.

For mainstream remote access scenarios, and certainly for wireless
scenarios, the sgw is well known to its users, at least by IP address. I
can understand the desire to mitigate damage due to polling attacks
under some circumstances, but that risk does not outweigh the threat
posed by easy discovery of user identities in wlan scenarios. We really
should provide a method for concealing user identities in these scenarios.

|>3. Most importantly - exchanges which were used in IKEv1 DID support this
|>requirement. For example XAUTH requires the server to prove his
|>identity first and the client's identity is protected against active
|>attacks.
|>So protection which is around for current clients using IKEv1 will not be
|>there
|>after migrating to IKEv2.
|
|
| XAUTH is not part of IKEv1. So this feature was not in the IKEv1. Also
| the original XAUTH versions I looked at did the normal IKEv1 exchange
| and only then started the XAUTH. This meant that the client still
| needed to proof its identity before starting XAUTH. If people were
| using group pre shared keys, then anybody with the key (i.e anybody
| with the group) could by active attack get the identities (and
| if basic password authentication was used also the password).

XAUTH is not officially part of IKE, but it is the de facto IKEv1 remote
access solution. Hybrid-mode implementations are the most secure
embodiment of XAUTH, and these do require the client to prove its
identity prior to establishment of a secure channel. The fact that most
XAUTH deployments are susceptible to a MiM attack resulting from their
use of group preshared keys does not render Jesse's argument less valid.
We need identity protection for the initiator in remote access scenarios.

| Anyways you can still use the ID_KEY_ID (changing every time) as a
| identity in those EAP cases, and have very small program in the sgw
| end that will convert that ID_KEY_ID to the real EAP identity. This
| will offer completele protection to the initiators identity, without
| any change to the IKEv2 protocol, and with very minor changes to those
| implementations that actually require this.

This might meet some user's needs, but it does not scale well. It
requires synchronization between the sgw and the remote access clients,
and new lists of IDs must be provided to both on an ongoing basis. It is
not a good general solution.

Scott
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/AH4ZMtIdhO0pgN4RApu/AKD2lDyWV176ZAj9b4nbsgdqr2di0ACgpP0c
dq7th7rTUlmYg6Vj4c0Bbe8=
=HtzK
-----END PGP SIGNATURE-----