Feature #1380
INITIAL_CONTACT doesn't work with EAP authentication methods
Description
Initial contact notifications don't clear old connections sharing the same identity. No logs of duplicate checking are seen.
config setup
uniqueids = no
conn ikev2server
left=%any
right=%any
keyexchange=ikev2
rekey=no
dpddelay=90s
dpdtimeout=150s
dpdaction=clear
closeaction=clear
leftsubnet=0.0.0.0/0
rightfirewall=yes
leftfirewall=yes
rightdns=8.8.8.8,8.8.4.4
leftsendcert=always
rightsendcert=never
conn ikev2psk
auto=add
also=ikev2server
leftid=@vpn.somehost.co.za
leftauth=psk
rightauth=psk
rightsourceip=10.152.0.0/16
conn ikev2eap
auto=add
also=ikev2server
leftcert=host.crt
leftid=@vpn.somehost.co.za
rightauth=eap-md5
eap_identity=%any # this doesn't make a difference
rightsourceip=10.152.0.0/16
Two android devices with the strongswan app connecting to this server doesn't kick each other off. If uniqueids=yes is set, then obviously it works, but not due to INIT_CONTACT.
But a strange scenario is when my android phone connects with it's built-in IKEv2 PSK connection (which also sends INIT_CONTACT) it doesn't kick off the strongswan connection, even though the same ID is used and even though uniqueids=yes.
Two connections from the phone's built-in PSK connection kick each other off with uniqueids=yes or no. Logs show that INIT_CONTACT causes the kickoff in both cases.
History
#1 Updated by Tobias Brunner over 9 years ago
- Subject changed from Initial contact doesn' to Initial contact doesn't work with EAP authentication methods
- Description updated (diff)
- Status changed from New to Feedback
Two android devices with the strongswan app connecting to this server doesn't kick each other off. If uniqueids=yes is set, then obviously it works, but not due to INIT_CONTACT.
As far as I can tell from the code the uniqueness check caused by the INITIAL_CONTACT notify happens during the server's own authentication when preparing the first IKE_AUTH response (i.e. before the client is authenticated via EAP). But it will compare the remote peer's EAP identities, if available. Therefore, there is probably a comparison between the IKE identity of the new SA and the EAP identity of any existing SA, which might not match (however in case of the Android app they should actually be the same as the username is used as IKE identity). Could you post the log and status output of two such sessions?
There is another uniqueness check after all authentication rounds have completed but that only is enforced with uniqueids=yes.
But a strange scenario is when my android phone connects with it's built-in IKEv2 PSK connection (which also sends INIT_CONTACT) it doesn't kick off the strongswan connection, even though the same ID is used and even though uniqueids=yes.
Two connections from the phone's built-in PSK connection kick each other off with uniqueids=yes or no. Logs show that INIT_CONTACT causes the kickoff in both cases.
Aren't these two paragraphs contradictory?
#2 Updated by Pieter Jordaan over 9 years ago
- File output.log output.log added
- File statusall.log statusall.log added
- File log2.txt log2.txt added
- File log1.txt log1.txt added
As far as I can tell from the code the uniqueness check caused by the INITIAL_CONTACT notify happens during the server's own authentication when preparing the first IKE_AUTH response (i.e. before the client is authenticated via EAP). But it will compare the remote peer's EAP identities, if available. Therefore, there is probably a comparison between the IKE identity of the new SA and the EAP identity of any existing SA, which might not match (however in case of the Android app they should actually be the same as the username is used as IKE identity). Could you post the log and status output of two such sessions?
Please find them attached
But a strange scenario is when my android phone connects with it's built-in IKEv2 PSK connection (which also sends INIT_CONTACT) it doesn't kick off the strongswan connection, even though the same ID is used and even though uniqueids=yes.
Two connections from the phone's built-in PSK connection kick each other off with uniqueids=yes or no. Logs show that INIT_CONTACT causes the kickoff in both cases.
Aren't these two paragraphs contradictory?
To clarify, when both use PSK then INIT_CONTACT works. If one of them use EAP instead then INIT_CONTACT doesn't work either.
In all uses of EAP both the leftid and eap_identity is the same (except maybe the ID type)
#3 Updated by Tobias Brunner over 9 years ago
- Tracker changed from Issue to Feature
- Subject changed from Initial contact doesn't work with EAP authentication methods to INITIAL_CONTACT doesn't work with EAP authentication methods
- Category set to libcharon
- Assignee set to Tobias Brunner
- Target version set to 5.5.0
As far as I can tell from the code the uniqueness check caused by the INITIAL_CONTACT notify happens during the server's own authentication when preparing the first IKE_AUTH response (i.e. before the client is authenticated via EAP). But it will compare the remote peer's EAP identities, if available. Therefore, there is probably a comparison between the IKE identity of the new SA and the EAP identity of any existing SA, which might not match (however in case of the Android app they should actually be the same as the username is used as IKE identity). Could you post the log and status output of two such sessions?
Please find them attached
Thanks. I had another look at the code and INITIAL_CONTACT notifies in the first IKE_AUTH request are actually ignored if the client uses EAP. I'm not sure exactly why that is, but it has been like this for a very long time. We definitely didn't use XAuth/EAP identities for uniqueness checks back then, so perhaps it just wasn't an option.
You could try the patch in the 1380-init-contact-eap branch. With it the uniqueness check is forced if an INITAL_CONTACT is received and with uniqueids=yes or uniqueids=no any existing other IKE_SAs between the same identities are silently destroyed (with uniqueids=never the INITIAL_CONTACT has no effect). On the other hand, with uniqueids=yes but without INITIAL_CONTACT notify existing IKE_SAs between the same identities are deleted with proper DELETE exchanges.
But a strange scenario is when my android phone connects with it's built-in IKEv2 PSK connection (which also sends INIT_CONTACT) it doesn't kick off the strongswan connection, even though the same ID is used and even though uniqueids=yes.
Two connections from the phone's built-in PSK connection kick each other off with uniqueids=yes or no. Logs show that INIT_CONTACT causes the kickoff in both cases.
Aren't these two paragraphs contradictory?
To clarify, when both use PSK then INIT_CONTACT works. If one of them use EAP instead then INIT_CONTACT doesn't work either.
I see.
In all uses of EAP both the leftid and eap_identity is the same (except maybe the ID type)
And as you saw in #1381 the type could make a whole lot of difference.
#4 Updated by Pieter Jordaan over 9 years ago
You could try the patch in the 1380-init-contact-eap branch. With it the uniqueness check is forced if an INITAL_CONTACT is received and with uniqueids=yes or uniqueids=no any existing other IKE_SAs between the same identities are silently destroyed (with uniqueids=never the INITIAL_CONTACT has no effect). On the other hand, with uniqueids=yes but without INITIAL_CONTACT notify existing IKE_SAs between the same identities are deleted with proper DELETE exchanges.
This works perfectly now thanks!
But a strange scenario is when my android phone connects with it's built-in IKEv2 PSK connection (which also sends INIT_CONTACT) it doesn't kick off the strongswan connection, even though the same ID is used and even though uniqueids=yes.
Two connections from the phone's built-in PSK connection kick each other off with uniqueids=yes or no. Logs show that INIT_CONTACT causes the kickoff in both cases.
Aren't these two paragraphs contradictory?
To clarify, when both use PSK then INIT_CONTACT works. If one of them use EAP instead then INIT_CONTACT doesn't work either.
I see.
In all uses of EAP both the leftid and eap_identity is the same (except maybe the ID type)
And as you saw in #1381 the type could make a whole lot of difference.
EAP now also closes (silently) the phone PSK connection, but the reverse doesn't work. Connecting the PSK phone connection, the EAP one remains untouched.
As another scenario I've just tested, Windows 10 IKEv2 sends a different ID than the EAP_ID. Here is a summary of what happens:- Connect strongswan app on tablet
- Connect phone PSK connection (uses KEY_ID) - at this stage nothing is kicking anything off
- Connect Windows 10 - it doesn't send INIT_CONTACT so nothing is kicked off
- Reconnect strongswan app - this closes both windows 10 and PSK.
So again summarizing:
strongswan app with EAP (FQDN left ID) closes all other combinations even though different ID types exist (windows 10 uses IPv4 and eap_identity, and PSK uses KEY_ID and eap_identity)
phone PSK (KEY_ID) can close windows 10 (EAP_IDENTITY) but not EAP strongwan app (maybe EAP ID isn't tested here? perhaps it tests on FQDN ID instead because PSK doesn't have an EAP id)
Another strongswan instance using EAP and KEYID also closes everything - in this case I believe the EAP Id is used, otherwise FQDN and KEYID wouldn't work.
So my assumption is that EAP identity is not used for uniqueness tests unless both parties have it, but I cannot be sure.
#5 Updated by Pieter Jordaan over 9 years ago
I think I've figured the conditions out perhaps, you can correct me if I'm wrong...
EAP identity can force uniqueness on other EAP identities and KEYID it seems.
This explains every situation we've been seeing.
What doesn't happen though is that KEYID doesn't force uniqueness on EAP identity, which I think it should, because they are both text based.
#6 Updated by Tobias Brunner over 9 years ago
EAP identity can force uniqueness on other EAP identities and KEYID it seems.
Not really. It all depends on the types of the compared identities, whether it's an EAP-Identity or not doesn't really matter (if a peer is not authenticated with EAP/XAuth its IKE identity is used for the comparison). However, as I explained in #1381 the EAP-Identity payload has no type associated with identities, so due to the parsing the types of these identities might be different than those used as IKE identities.
That an EAP connection is able to delete a PSK connection that uses an ID_KEY_ID identity but not the other way around is quite interesting. It is due to a difference in identity object comparison. While identities of type ID_KEY_ID use a binary comparison that also compares the identity type (equals_binary at source:src/libstrongswan/utils/identification.c#L597) identities of type ID_FQDN and ID_RFC822_ADDR don't check the identity type and use stncasecmp() to do the comparison (equals_strcasecmp at source:src/libstrongswan/utils/identification.c#L723). I think this is a bug, equals_strcasecmp should check the type before attempting to compare the encoding. I pushed that change to the same branch. With it the PSK connection with ID_KEY_ID won't be affected by the EAP connection and vice-versa.
What doesn't happen though is that KEYID doesn't force uniqueness on EAP identity, which I think it should, because they are both text based.
Actually, no. The definition according to RFC 7296 is as follows:
ID_KEY_ID 11
An opaque octet stream that may be used to pass vendor-
specific information necessary to do certain proprietary
types of identification.
#7 Updated by Pieter Jordaan over 9 years ago
Excellent I'm happy with the results now. Thanks for your brilliant support!
#8 Updated by Tobias Brunner over 9 years ago
- Status changed from Feedback to Closed
- Resolution set to Fixed