Project

General

Profile

Feature #1380

INITIAL_CONTACT doesn't work with EAP authentication methods

Added by Pieter Jordaan over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Category:
libcharon
Target version:
Start date:
05.04.2016
Due date:
Estimated time:
Resolution:
Fixed

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.

statusall.log (3.18 KB) statusall.log status output Pieter Jordaan, 05.04.2016 16:03
output.log (528 KB) output.log server log Pieter Jordaan, 05.04.2016 16:03
log2.txt (25 KB) log2.txt device 1 log Pieter Jordaan, 05.04.2016 16:07
log1.txt (25.7 KB) log1.txt device 2 log Pieter Jordaan, 05.04.2016 16:07

Associated revisions

Revision a6289d93 (diff)
Added by Tobias Brunner about 4 years ago

ikev2: Handle INITIAL_CONTACT notifies also when peer is authenticated with EAP

Fixes #1380.

Revision a366fa36 (diff)
Added by Tobias Brunner about 4 years ago

identification: Compare identity types when comparing ID_FQDN/ID_RFC822_ADDR identities

References #1380.

History

#1 Updated by Tobias Brunner over 4 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 4 years ago

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 4 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 4 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 4 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 4 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 4 years ago

Excellent I'm happy with the results now. Thanks for your brilliant support!

#8 Updated by Tobias Brunner about 4 years ago

  • Status changed from Feedback to Closed
  • Resolution set to Fixed

Also available in: Atom PDF