IKEv2 EAP Identity vs client ID matching for per-client settings with local users
With IKEv2, the EAP Identity does not necessarily match the
rightid supplied by the client. For most common use cases, however, it does (or should) match, especially for local users.
The way the code for per-identity settings was added in #8292 and #8644, it relies on the client to tell the server what its identifier is for this matching and it doesn't necessarily match the identifier used during authentication when using local users. This situation varies based on the client and chosen EAP authentication type (local, radius, etc) for example, the EAP Identity is what is passed to a RADIUS server when authenticating that way.
This leads to a situation with local EAP users where if they set a local EAP identity in the client that differs from the username, the EAP Identifier is taken for matching the per-user settings. Their username/password are still valid, but the client may pull different settings than expected.
This does not apply to EAP-RADIUS, where if a user supplies a custom local EAP identity, that is sent to the RADIUS server as the username, thus their authentication is rejected as incorrect when it does not match.
- Setup mobile IKEv2 with EAP-MSChapv2 auth
- Setup two entries on the Pre-Shared Key tab, user1 and user2, each with a different PSK and IP address pool than the main mobile pool
- From the client, attempt to connect with the local identifier (a) blank, (b) set the same as the username, and (c) set to the other user (e.g. when testing user1, set to user2)
Without the patch, user1 will authenticate as user1 and then can get either user1 or user2 settings depending on the local EAP identifier set in the client. With the attached patch, if user1 presents a mismatching EAP identifier, they receive an address from the general pool instead since it will fail to match any of the configured entries.
When confirming if the fix work, also test against EAP-RADIUS with a similar situation.
Updated by Jim Pingle almost 5 years ago
If we determine that there is a use case for allowing the other method, we can setup GUI controls for it later as a separate feature request. There may be a valid use case that requires the looser matching or that requires a separate strict EAP ID that differs from the username.