Bug #141
eap-simaka: Repeated AT_ANY_ID_REQ
| Status: | Closed | Start date: | 15.09.2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | Martin Willi | % Done: | 0% |
|
| Category: | libcharon | |||
| Target version: | - | |||
| Affected version: | 4.5.3 | Resolution: |
Description
eap-simaka module will repeat AT_ANY_ID_REQ if it did not recognize the AT_IDENTITY response for the first request.
According to [[http://www.ietf.org/rfc/rfc4186.txt]], in the last paragraph in 4.2.5 section this must not happen.
Check sections 4.2.5 through 4.2.7 about the identity processing. According to those rules AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ AT_PERMANENT_ID_REQ must not be repeated, nor can AT_ANY_ID_REQ be sent after AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ, nor can AT_FULLAUTH_ID_REQ be sent after AT_PERMANENT_ID_REQ.
When this happen our client responds with EAP-Response/SIM/Client-Error packet, according to section 6.3.1 and authentication fails.
Below are the packet traces on the client side showing this issue (IKEv2 decrypted payloads).
I can include strongswan log if needed.
First packet containing AT_ANY_ID_REQ:
00000000 00 00 00 18 01 5c 00 14 12 0a 00 00 0f 02 00 02 ................
00000010 00 01 00 00 0d 01 00 00 ........
Response to this packet (ID not recognized by the server)
00000000 00 00 00 38 02 5c 00 34 12 0a 00 00 0e 05 00 10 ...8...4........
00000010 61 39 62 30 38 32 32 34 35 61 64 61 32 61 64 33 a9b082245ada2ad3
00000020 07 05 00 00 51 8a 34 6a 5f 22 16 f8 28 23 dd 54 ....Qè4j_".°(#▌T
00000030 98 e8 c6 83 10 01 00 01 ÿΦ╞â....
Repeated AT_ANY_ID_REQ from the server (notice that it is not a repeated EAP packet, since EAP ID is different):
00000000 00 00 00 18 01 5d 00 14 12 0a 00 00 0f 02 00 02 .....]..........
00000010 00 01 00 00 0d 01 00 00 ........
History
Updated by Martin Willi 8 months ago
eap-simaka module will repeat AT_ANY_ID_REQ if it did not recognize the AT_IDENTITY response for the first request.
Do you have a little more details what exactly you did? I can't reproduce this issue.
The server first sends a AT_ANY_ID_REQ. If the received identity is not recognized as reauthentication or pseudonym identity and does not have quintuplets for such a permanent identity, it requests AT_PERMANENT_ID_REQ:
02[ENC] parsed IKE_AUTH request 2 [ EAP/RES/AKA ] 02[IKE] 'c0398926cb45a208' is not a reauth identity 02[IKE] 'c0398926cb45a208' is not a pseudonym 02[IKE] received identity 'c0398926cb45a208' 02[IKE] no EAP key found for c0398926cb45a208 to authenticate with AKA 02[LIB] tried 0 SIM providers, but none had a quintuplet for 'c0398926cb45a208' 02[IKE] failed to map pseudonym/reauth identity 'c0398926cb45a208', fallback to permanent identity request 02[ENC] generating IKE_AUTH response 2 [ EAP/REQ/AKA ]
Updated by Martin Willi 8 months ago
Similar behavior for EAP-SIM:
08[ENC] parsed IKE_AUTH request 2 [ EAP/RES/SIM ] 08[IKE] received unknown reauthentication identity 'af894bc78b985ce5', initiating full authentication 08[ENC] generating IKE_AUTH response 2 [ EAP/REQ/SIM ] 08[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.1[4500] 07[NET] received packet: from 192.168.0.1[4500] to 192.168.0.2[4500] 07[ENC] parsed IKE_AUTH request 3 [ EAP/RES/SIM ] 07[IKE] received pseudonym or permanent identity 'cf0c16158360504c' 07[LIB] tried 3 SIM providers, but none had a triplet for 'cf0c16158360504c' 07[IKE] failed to map pseudonym identity 'cf0c16158360504c', fallback to permanent identity request 07[ENC] generating IKE_AUTH response 3 [ EAP/REQ/SIM ] 07[NET] sending packet: from 192.168.0.2[4500] to 192.168.0.1[4500] 08[NET] received packet: from 192.168.0.1[4500] to 192.168.0.2[4500] 08[ENC] parsed IKE_AUTH request 4 [ EAP/RES/SIM ] 08[IKE] received permanent identity 'moon@strongswan.org'
Updated by Stefan Tomas 8 months ago
This was evidently mistake on my end. This is a non-issue, please close it.
Sorry for the mishap.
Updated by Martin Willi 8 months ago
- Status changed from New to Closed
- Assignee set to Martin Willi