Project

General

Profile

Issue #2110

Remote Identity (IDr) in IKE AUTH Response is sent as hex-encoded binary value instead of text when setting leftid to type KEY_ID (leftid=@#xxxxxxx)

Added by Danny Kulchinsky about 4 years ago. Updated about 4 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.5.0
Resolution:

Description

strongSwan acts as a Responder, the IDr received from the initiator in the IKE AUTH Request is "ims" of type KEY_ID, so we defined in strongSwan leftid=@#696d73

The correct peer configuration is picked up but the IKE AUTH Response includes the hex-encoded binary value as defined in leftid (696d73), we were expecting it to send the text string (ims), initiator drops the connection as it is expecting to get "ims" and instead it gets "696d73"

Is it possible for strongSwan to send the text string instead of the hex-encoded binary value ?

replace-id-payload.patch (1.61 KB) replace-id-payload.patch Tobias Brunner, 13.09.2016 18:35

Related issues

Related to Issue #2099: charon.cert_id_binding patch for new versionsClosed

History

#1 Updated by Tobias Brunner about 4 years ago

  • Status changed from New to Feedback

Is it possible for strongSwan to send the text string instead of the hex-encoded binary value ?

What do you mean? Identities are transmitted in binary and "ims" in binary ASCII is 696d73. Or is the string "696d73", i.e. binary 363936643733, received by the peer?

#2 Updated by Noel Kuntze about 4 years ago

strongSwan acts as a Responder, the IDr received from the initiator in the IKE AUTH Request is "ims" of type KEY_ID, so we defined in strongSwan leftid=@#696d73

Why don't you use leftid = keyid:ims or something? (I've never used that feature, so I don't know if that's the correct syntax)

#3 Updated by Danny Kulchinsky about 4 years ago

Thank you both for your feedback.

Tobias, the value received on the client side is 696d73, so if they are transmitted in binary ASCII, I guess it's up to the Client to decode it.

Noel, good question - my understanding was that ID_KEY_ID identities must be defined as hex-encoded binaries with @# prefix. Is there any difference in the way it's currently configured and what you suggest ?

#4 Updated by Noel Kuntze about 4 years ago

The man page of ipsec.conf that I have here doesn't mention @ together with #. It only mentions :#, where the type of the identity is prefixed in front of the : and the # is optional. Using @ is a hack anyway. Using it makes charon interpret the whole ID as type FQDN.

#5 Updated by Danny Kulchinsky about 4 years ago

Noel Kuntze wrote:

The man page of ipsec.conf that I have here doesn't mention @ together with #. It only mentions :#, where the type of the identity is prefixed in front of the : and the # is optional. Using @ is a hack anyway. Using it makes charon interpret the whole ID as type FQDN.

I was setting it according to this IdentityParsing wiki.

If the string value contains an @ the type depends on the position of that character:
* If the string begins with @# the type is set to KEY_ID and the string following that prefix is assumed to be the hex-encoded binary value of the identity.

#6 Updated by Tobias Brunner about 4 years ago

Tobias, the value received on the client side is 696d73, so if they are transmitted in binary ASCII, I guess it's up to the Client to decode it.

How does the client expect it then? UTF-16? I don't really see how else it could decode that blob, or how else the string "ims" could be encoded as identity (ASCII and UTF-8 will result in the same binary encoding).

#7 Updated by Noel Kuntze about 4 years ago

Danny Kulchinsky wrote:

Noel Kuntze wrote:

The man page of ipsec.conf that I have here doesn't mention @ together with #. It only mentions :#, where the type of the identity is prefixed in front of the : and the # is optional. Using @ is a hack anyway. Using it makes charon interpret the whole ID as type FQDN.

I was setting it according to this IdentityParsing wiki.

[...]

Well, I'm sure the article is right. I just didn't read it, but only the part of the man page about leftid.

#8 Updated by Danny Kulchinsky about 4 years ago

I believe I was wrong in my initial analysis, so I will go back a few steps and describe the situation.

IKE Client (not strongSwan) has the following configuration:

Security Gateway address: <FQDN>
local ID: 0<IMSI>@nai.epc.mncXXX.mccYYY.3gppnetwork.org (USER_FQDN)
remote ID: ims (KEY_ID)
Authentication method: EAP-AKA
The Client also has a server's certificate (Public Key), where CN=<FQDN> (same as Security Gateway's FQDN).
Client doesn't support EAP-Only :(

Possible issue: "ims" is not defined in the Certificate Subject or altSubjectName.

On strongSwan (responder), we defined the following in ipsec.conf:

conn <some name>
    # left - local (server) side
    left=%any
    leftid=keyid:ims
    leftauth=pubkey
    leftcert=<certificate>
    leftsubnet=10.x.x.x/24

    # right - remote (client) side
    right=%any
    rightid=%any
    rightsendcert=never
    rightauth=eap-radius
    rightsourceip=%wifi-pool
    auto=add

I had to define leftid=keyid:ims since this is what the client is sending in the IDr of the IKE_AUTH Request.

However, with this setup, strongSwan is unable to select this peer config since the Remote ID (ims) sent by the client is not in leftcert certificate Subject or altSubjectName, changing the certificate on Client side is very difficult at this point :_(

2016-09-11 18:29:22.334 17[CFG] <2> looking for peer configs matching <Security Gateway IP>[ims]...<Remote Client IP>[<Remote Client Identity>]
2016-09-11 18:29:22.334 17[CFG] <2> no matching peer config found

I have attempted to resolve this by using a patch (https://wiki.strongswan.org/projects/strongswan/repository/revisions/9c84c5e113307e1805783a4e58905dc68ed2e944) that provides an option to allow mismatches between IKE identity and certificates, this helped on the responder (strongSwan) side, but since the identity (IDr) provided in IKE_AUTH Response is "ims", it fails verification on Client side, since there is no such value in the Subject/altSubjectName of the certificate.

with cert_id_binding = no

2016-09-11 18:40:31.196 24[CFG] <2> looking for peer configs matching <Security Gateway IP>[ims]...<Remote Client IP>[<Remote Client Identity>]
2016-09-11 18:40:31.196 24[CFG] <2>   candidate "<some name>", match: 20/1/28 (me/other/ike)
2016-09-11 18:40:31.196 24[CFG] <some name|2> selected peer config '<some name>'
2016-09-11 18:40:31.198 24[CFG] <some name|2> enforcing local cert 'C=XX, ST=YYYYY, L=ZZZZZ, O=ABCD, CN=<FQDN>' mismatching IKE identity 'ims'
2016-09-11 18:40:31.200 24[IKE] <some name|2> authentication of 'ims' (myself) with RSA_EMSA_PKCS1_SHA256 successful
2016-09-11 18:40:31.200 24[ENC] <some name|2> generating IKE_AUTH response 1 [ IDr AUTH EAP/REQ/AKA ]
2016-09-11 18:40:31.272 10[ENC] <some name|2> parsed INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
2016-09-11 18:40:31.272 10[ENC] <some name|2> generating INFORMATIONAL response 2 [ N(AUTH_FAILED) ]

Some details for client side (with cert_id_binding = no on strongSwan):

IKEv2 payload sent: len=  336, mID=1, HDR, IDi, CERTREQ, IDr, CP, SA, TSi, TSr, N(HTTP_CERT_LOOKUP_SUPPORTED), N(INITIAL_CONTACT), N(ESP_TFC_PADDING_NOT_SUPPORTED), N(NON_FIRST_FRAGMENTS_ALSO)
IKEv2 payloads received: mID=1, HDR, IDr, CERT, AUTH, EAP
Validation failed for remote identity '696d73' against trust anchor '<details of the CA>'

If I could have strongSwan send the IDr in IKE_AUTH Response with the Certificate's subject instead of leftid value (ims), I believe this would have solved this problem but I'm unable to find a working solution for this.

I apologize for not starting with the general problem description and jumped to conclusion, I was somewhat mislead by the Client's vendor.

This unfortunate setup works with another Security Gateway we have (a 3rd party proprietary solution) and I'm "forced" to make this work with strongSwan as well without introducing any changes on the Client side.

#9 Updated by Noel Kuntze about 4 years ago

However, with this setup, strongSwan is unable to select this peer config since the Remote ID (ims) sent by the client is not in leftcert certificate Subject or altSubjectName, changing the certificate on Client side is very difficult at this point :_(

You're writing about leftcert and the remote ID sent by the client. Why don't you just include the SAN "ims" in the certificate you're using to authenticate strongSwan?

#10 Updated by Tobias Brunner about 4 years ago

Possible issue: "ims" is not defined in the Certificate Subject or altSubjectName.

That's definitely an issue as identities of type KEY_ID, that don't match the subjectKeyIdentifier, won't ever be subject of a certificate (subjectAltNames can only take certain types and these are mapped pretty much 1:1 to IKE identity types).

I had to define leftid=keyid:ims since this is what the client is sending in the IDr of the IKE_AUTH Request.

If you do that, and without the cert-id-binding-option patches, you'll get the following warning when the configuration is loaded:

[CFG]  id 'ims' not confirmed by certificate, defaulting to 'C=XX, ST=YYYYY, L=ZZZZZ, O=ABCD, CN=<FQDN>'

So now your config with leftid=<subject DN> won't be considered when the client with IDr 'ims' tries to connect.

but since the identity (IDr) provided in IKE_AUTH Response is "ims", it fails verification on Client side, since there is no such value in the Subject/altSubjectName of the certificate.

Hm, how did that work before? What does the client expect as IDr exactly?

If I could have strongSwan send the IDr in IKE_AUTH Response with the Certificate's subject instead of leftid value (ims), I believe this would have solved this problem but I'm unable to find a working solution for this.

That's not so easy to change. Well, at least not in a nice way. For your purposes you could patch the pubkey authenticator, so besides just changing the identity for the certificate lookup it also replaces the identity in the IKE_AUTH response. Something like this (applies on top of the two patches in the cert-id-binding-option branch:

diff --git a/src/libcharon/sa/ikev2/authenticators/pubkey_authenticator.c b/src/libcharon/sa/ikev2/authenticators/pubkey_authenticator.c
index 3ca5a2ee0c3e..9b366ae7820a 100644
--- a/src/libcharon/sa/ikev2/authenticators/pubkey_authenticator.c
+++ b/src/libcharon/sa/ikev2/authenticators/pubkey_authenticator.c
@@ -19,6 +19,7 @@

 #include <daemon.h>
 #include <encoding/payloads/auth_payload.h>
+#include <encoding/payloads/id_payload.h>
 #include <sa/ikev2/keymat_v2.h>
 #include <asn1/asn1.h>
 #include <asn1/oid.h>
@@ -350,6 +351,9 @@ METHOD(authenticator_t, build, status_t,
     status_t status;
     auth_payload_t *auth_payload;
     auth_method_t auth_method = AUTH_NONE;
+    enumerator_t *enumerator;
+    id_payload_t *id_payload;
+    payload_t *payload;

     id = get_cert_id(this->ike_sa, TRUE);
     auth = this->ike_sa->get_auth_cfg(this->ike_sa, TRUE);
@@ -359,7 +363,18 @@ METHOD(authenticator_t, build, status_t,
         DBG1(DBG_IKE, "no private key found for '%Y'", id);
         return NOT_FOUND;
     }
-    id = this->ike_sa->get_my_id(this->ike_sa);
+    enumerator = message->create_payload_enumerator(message);
+    while (enumerator->enumerate(enumerator, &payload))
+    {
+        if (payload->get_type(payload) == PLV2_ID_RESPONDER)
+        {
+            message->remove_payload_at(message, enumerator);
+            break;
+        }
+    }
+    enumerator->destroy(enumerator);
+    id_payload = id_payload_create_from_identification(PLV2_ID_RESPONDER, id);
+    message->add_payload(message, (payload_t*)id_payload);
     if (this->ike_sa->supports_extension(this->ike_sa, EXT_SIGNATURE_AUTH))
     {
         auth_method = AUTH_DS;

This unfortunate setup works with another Security Gateway we have (a 3rd party proprietary solution) and I'm "forced" to make this work with strongSwan as well without introducing any changes on the Client side.

How does the other gateway handle this? Can you configure two identities there? Or does it generally ignore the client's IDr and just respond with the certificate's subject as identity?

#11 Updated by Danny Kulchinsky about 4 years ago

Thank you Tobias!

How does the other gateway handle this? Can you configure two identities there? Or does it generally ignore the client's IDr and just respond with the certificate's subject as identity?

We did another round of testing now to compare the Client's behavior with our different Security Gateways.

It seems that in case of the other Security Gateway as suspected it seems to ignore client's IDr and send the certificate's subject identity in the IKE_AUTH Response:

pad_ike_certs.c:1329: Remote identity <FQDN>
IDr(type = fqdn (2), len = 15, value = <FQDN>)

So the certificate is validated successfully.

I'm now implementing the patch above, will update on the result.

#12 Updated by Danny Kulchinsky about 4 years ago

Just to confirm, I applied the following patches (from cert-id-binding-option branch):
https://wiki.strongswan.org/projects/strongswan/repository/revisions/9c84c5e113307e1805783a4e58905dc68ed2e944
https://wiki.strongswan.org/projects/strongswan/repository/revisions/75b264d2c2b0ae5299d8763b516b307f5348e4cd

and on top, the patch you provided above.

We executed the same test and we were able to progress in the flow, the client was able to validate the Responder's identity with the certificate and an EAP-AKA authentication was done with the Radius server.

However, when we sent the final IKE_AUTH Response with the Configuration Payload, the Client generated the following error:

error: Auth payload contents does not match

Seems like there's mismatch in the AUTH payload between the two responses we send ? (i.e. responses 1 & 4) !?

2016-09-12 17:23:08.044 21[ENC] <some name|3> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/AKA ]
2016-09-12 17:23:09.752 15[ENC] <some name|3> generating IKE_AUTH response 4 [ AUTH CPRP(ADDR) SA TSi TSr ]

I can see that strongSwan authenticates itself twice, first with RSA using Certificate's DN as the identity and second with EAP using 'ims' as the identity, perhaps this is the missmatch ?

First this:

2016-09-12 17:23:08.042 21[CFG] <some name|3> enforcing local cert 'C=XX, ST=YYYYY, L=ZZZZZ, O=ABCD, CN=<FQDN>' mismatching IKE identity 'ims'
2016-09-12 17:23:08.044 21[IKE] <some name|3> authentication of 'C=XX, ST=YYYYY, L=ZZZZZ, O=ABCD, CN=<FQDN>' (myself) with RSA signature successful
2016-09-12 17:23:08.044 21[IKE] <some name|3> sending end entity cert "C=XX, ST=YYYYY, L=ZZZZZ, O=ABCD, CN=<FQDN>" 

and later this:

2016-09-12 17:23:09.742 15[IKE] <some name|3> authentication of 'ims' (myself) with EAP

Here's strongSwan's full log:

2016-09-12 17:23:07.758 22[ENC] <3> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) V ]
2016-09-12 17:23:07.758 22[CFG] <3> looking for an ike config for <Security Gateway IP>...<Client IP>
2016-09-12 17:23:07.758 22[CFG] <3> ike config match: 28 (<Security Gateway IP> <Client IP> IKEv2)
2016-09-12 17:23:07.758 22[CFG] <3>   candidate: %any...%any, prio 28
2016-09-12 17:23:07.758 22[CFG] <3> ike config match: 28 (<Security Gateway IP> <Client IP> IKEv2)
2016-09-12 17:23:07.758 22[CFG] <3>   candidate: %any...%any, prio 28
2016-09-12 17:23:07.758 22[CFG] <3> ike config match: 28 (<Security Gateway IP> <Client IP> IKEv2)
2016-09-12 17:23:07.758 22[CFG] <3>   candidate: %any...%any, prio 28
2016-09-12 17:23:07.758 22[CFG] <3> found matching ike config: %any...%any with prio 28
2016-09-12 17:23:07.758 22[ENC] <3> received unknown vendor ID: <vendor ID>
2016-09-12 17:23:07.758 22[IKE] <3> <Client IP> is initiating an IKE_SA
2016-09-12 17:23:07.758 22[CFG] <3> selecting proposal:
2016-09-12 17:23:07.758 22[CFG] <3>   proposal matches
2016-09-12 17:23:07.758 22[CFG] <3> received proposals: IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
2016-09-12 17:23:07.758 22[CFG] <3> configured proposals: IKE:AES_CBC_256/HMAC_MD5_96/HMAC_SHA1_96/PRF_HMAC_MD5/PRF_HMAC_SHA1/MODP_1024
2016-09-12 17:23:07.758 22[CFG] <3> selected proposal: IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
2016-09-12 17:23:07.759 22[IKE] <3> remote host is behind NAT
2016-09-12 17:23:07.759 22[ENC] <3> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(MULT_AUTH) ]
2016-09-12 17:23:08.039 21[ENC] <3> unknown attribute type (16384)
2016-09-12 17:23:08.039 21[ENC] <3> parsed IKE_AUTH request 1 [ IDi CERTREQ IDr CPRQ(MASK ADDR DNS (16384)) SA TSi TSr N(HTTP_CERT_LOOK) N(INIT_CONTACT) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
2016-09-12 17:23:08.039 21[IKE] <3> received cert request for "<Certificate Authority>" 
2016-09-12 17:23:08.039 21[CFG] <3> looking for peer configs matching <Security Gateway IP>[ims]...<Client IP>[0xxxxxxxxxxxxxxx@nai.epc.mnc###.mcc###.3gppnetwork.org]
2016-09-12 17:23:08.039 21[CFG] <3> peer config match local: 0 (ID_KEY_ID -> 69:6d:73)
2016-09-12 17:23:08.040 21[CFG] <3> peer config match remote: 1 (ID_RFC822_ADDR -> <Client Identity>)
2016-09-12 17:23:08.040 21[CFG] <3> ike config match: 28 (<Security Gateway IP> <Client IP> IKEv2)
2016-09-12 17:23:08.040 21[CFG] <3> peer config match local: 20 (ID_KEY_ID -> 69:6d:73)
2016-09-12 17:23:08.040 21[CFG] <3> peer config match remote: 1 (ID_RFC822_ADDR -> <Client Identity>)
2016-09-12 17:23:08.040 21[CFG] <3> ike config match: 28 (<Security Gateway IP> <Client IP> IKEv2)
2016-09-12 17:23:08.040 21[CFG] <3>   candidate "some name", match: 20/1/28 (me/other/ike)
2016-09-12 17:23:08.040 21[CFG] <3> peer config match local: 1 (ID_KEY_ID -> 69:6d:73)
2016-09-12 17:23:08.040 21[CFG] <3> peer config match remote: 1 (ID_RFC822_ADDR -> <Client Identity>)
2016-09-12 17:23:08.040 21[CFG] <3> ike config match: 28 (<Security Gateway IP> <Client IP> IKEv2)
2016-09-12 17:23:08.040 21[CFG] <3>   candidate "Test", match: 1/1/28 (me/other/ike)
2016-09-12 17:23:08.040 21[CFG] <some name|3> selected peer config 'some name'
2016-09-12 17:23:08.040 21[CFG] <some name|3> sending RADIUS Access-Request to server '<Radius Server>'
2016-09-12 17:23:08.042 21[CFG] <some name|3> received RADIUS Access-Challenge from server '<Radius Server>'
2016-09-12 17:23:08.042 21[IKE] <some name|3> initiating EAP_AKA method (id 0x01)
2016-09-12 17:23:08.042 21[IKE] <some name|3> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
2016-09-12 17:23:08.042 21[CFG] <some name|3> enforcing local cert 'C=XX, ST=YYYYY, L=ZZZZZ, O=ABCD, CN=<FQDN>' mismatching IKE identity 'ims'
2016-09-12 17:23:08.044 21[IKE] <some name|3> authentication of 'C=XX, ST=YYYYY, L=ZZZZZ, O=ABCD, CN=<FQDN>' (myself) with RSA signature successful
2016-09-12 17:23:08.044 21[IKE] <some name|3> sending end entity cert "C=XX, ST=YYYYY, L=ZZZZZ, O=ABCD, CN=<FQDN>" 
2016-09-12 17:23:08.044 21[ENC] <some name|3> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/AKA ]
2016-09-12 17:23:08.045 21[ENC] <some name|3> splitting IKE message with length of 1868 bytes into 4 fragments
2016-09-12 17:23:08.045 21[ENC] <some name|3> generating IKE_AUTH response 1 [ EF(1/4) ]
2016-09-12 17:23:08.045 21[ENC] <some name|3> generating IKE_AUTH response 1 [ EF(2/4) ]
2016-09-12 17:23:08.045 21[ENC] <some name|3> generating IKE_AUTH response 1 [ EF(3/4) ]
2016-09-12 17:23:08.045 21[ENC] <some name|3> generating IKE_AUTH response 1 [ EF(4/4) ]
2016-09-12 17:23:08.626 22[ENC] <some name|3> parsed IKE_AUTH request 2 [ EAP/RES/AKA ]
2016-09-12 17:23:08.626 22[CFG] <some name|3> sending RADIUS Access-Request to server '<Radius Server>'
2016-09-12 17:23:09.015 22[CFG] <some name|3> received RADIUS Access-Challenge from server '<Radius Server>'
2016-09-12 17:23:09.015 22[ENC] <some name|3> generating IKE_AUTH response 2 [ EAP/REQ/AKA ]
2016-09-12 17:23:09.532 05[ENC] <some name|3> parsed IKE_AUTH request 3 [ EAP/RES/AKA ]
2016-09-12 17:23:09.532 05[CFG] <some name|3> sending RADIUS Access-Request to server '<Radius Server>'
2016-09-12 17:23:09.534 05[CFG] <some name|3> received RADIUS Access-Accept from server '<Radius Server>'
2016-09-12 17:23:09.534 05[IKE] <some name|3> RADIUS authentication of '0xxxxxxxxxxxxxxx@nai.epc.mnc###.mcc###.3gppnetwork.org' successful
2016-09-12 17:23:09.534 05[IKE] <some name|3> EAP method EAP_AKA succeeded, MSK established
2016-09-12 17:23:09.534 05[ENC] <some name|3> generating IKE_AUTH response 3 [ EAP/SUCC ]
2016-09-12 17:23:09.742 15[ENC] <some name|3> parsed IKE_AUTH request 4 [ AUTH ]
2016-09-12 17:23:09.742 15[IKE] <some name|3> authentication of '0xxxxxxxxxxxxxxx@nai.epc.mnc###.mcc###.3gppnetwork.org' with EAP successful
2016-09-12 17:23:09.742 15[IKE] <some name|3> authentication of 'ims' (myself) with EAP
2016-09-12 17:23:09.747 15[IKE] <some name|3> IKE_SA some name[3] established between <Security Gateway IP>[ims]...<Client IP>[0xxxxxxxxxxxxxxx@nai.epc.mnc###.mcc###.3gppnetwork.org]
2016-09-12 17:23:09.747 15[IKE] <some name|3> scheduling rekeying in 85701s
2016-09-12 17:23:09.747 15[IKE] <some name|3> maximum IKE_SA lifetime 86241s
2016-09-12 17:23:09.748 15[IKE] <some name|3> peer requested virtual IP %any
2016-09-12 17:23:09.748 15[CFG] <some name|3> acquired address 10.y.y.1 from HA pool 'wifi-pool-4'
2016-09-12 17:23:09.748 15[IKE] <some name|3> assigning virtual IP 10.y.y.1 to peer '0xxxxxxxxxxxxxxx@nai.epc.mnc###.mcc###.3gppnetwork.org'
2016-09-12 17:23:09.748 15[CFG] <some name|3> looking for a child config for 0.0.0.0/0 === 0.0.0.0/0
2016-09-12 17:23:09.748 15[CFG] <some name|3> proposing traffic selectors for us:
2016-09-12 17:23:09.748 15[CFG] <some name|3>  10.x.x.0/24
2016-09-12 17:23:09.748 15[CFG] <some name|3> proposing traffic selectors for other:
2016-09-12 17:23:09.748 15[CFG] <some name|3>  10.y.y.1/32
2016-09-12 17:23:09.748 15[CFG] <some name|3>   candidate "some name" with prio 1+1
2016-09-12 17:23:09.748 15[CFG] <some name|3> found matching child config "some name" with prio 2
2016-09-12 17:23:09.748 15[CFG] <some name|3> selecting proposal:
2016-09-12 17:23:09.748 15[CFG] <some name|3>   proposal matches
2016-09-12 17:23:09.748 15[CFG] <some name|3> received proposals: ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ/EXT_SEQ
2016-09-12 17:23:09.748 15[CFG] <some name|3> configured proposals: ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
2016-09-12 17:23:09.748 15[CFG] <some name|3> selected proposal: ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ
2016-09-12 17:23:09.748 15[CFG] <some name|3> selecting traffic selectors for us:
2016-09-12 17:23:09.748 15[CFG] <some name|3>  config: 10.x.x.0/24, received: 0.0.0.0/0 => match: 10.x.x.0/24
2016-09-12 17:23:09.748 15[CFG] <some name|3> selecting traffic selectors for other:
2016-09-12 17:23:09.748 15[CFG] <some name|3>  config: 10.y.y.1/32, received: 0.0.0.0/0 => match: 10.y.y.1/32
2016-09-12 17:23:09.748 15[CFG] <some name|3> handling HA CHILD_SA some name{3} 10.x.x.0/24 === 10.y.y.1/32 (segment in: 2*, out: 1*)
2016-09-12 17:23:09.748 15[IKE] <some name|3> CHILD_SA some name{3} established with SPIs cfae8f43_i 918a492e_o and TS 10.x.x.0/24 === 10.y.y.1/32
2016-09-12 17:23:09.748 15[CFG] <some name|3> sending RADIUS Accounting-Request to server '<Radius Server>'
2016-09-12 17:23:09.752 15[CFG] <some name|3> received RADIUS Accounting-Response from server '<Radius Server>'
2016-09-12 17:23:09.752 15[ENC] <some name|3> generating IKE_AUTH response 4 [ AUTH CPRP(ADDR) SA TSi TSr ]
2016-09-12 17:26:27.832 12[IKE] <some name|3> sending DPD request
2016-09-12 17:26:27.833 12[ENC] <some name|3> generating INFORMATIONAL request 0 [ ]
2016-09-12 17:26:31.833 22[IKE] <some name|3> retransmit 1 of request with message ID 0
2016-09-12 17:26:39.033 24[IKE] <some name|3> retransmit 2 of request with message ID 0
2016-09-12 17:26:51.994 28[IKE] <some name|3> retransmit 3 of request with message ID 0
2016-09-12 17:27:15.322 28[IKE] <some name|3> giving up after 3 retransmits
2016-09-12 17:27:15.322 28[CFG] <some name|3> sending RADIUS Accounting-Request to server '<Radius Server>'
2016-09-12 17:27:15.325 28[CFG] <some name|3> received RADIUS Accounting-Response from server '<Radius Server>'
2016-09-12 17:27:15.326 28[CFG] <some name|3> released address 10.y.y.1 to HA pool 'wifi-pool-4'

#13 Updated by Tobias Brunner about 4 years ago

I can see that strongSwan authenticates itself twice, first with RSA using Certificate's DN as the identity and second with EAP using 'ims' as the identity, perhaps this is the missmatch ?

Possibly. Try adding the following line, right before enumerator = message->create_payload_enumerator(message):

this->ike_sa->set_my_id(this->ike_sa, id->clone(id));

#14 Updated by Danny Kulchinsky about 4 years ago

Tobias Brunner wrote:

I can see that strongSwan authenticates itself twice, first with RSA using Certificate's DN as the identity and second with EAP using 'ims' as the identity, perhaps this is the missmatch ?

Possibly. Try adding the following line, right before enumerator = message->create_payload_enumerator(message):

[...]

Done, I'm waiting for someone to test on Client side.

However, I have an additional connection configured on strongSwan and use a strongSwan Android client to connect (sort of a Canary, only using EAP-MSCHAPv2 auth), just to verify basic things are working, with this line added - I hit the following issue :_(

2016-09-13 12:15:14.913 29[CFG] <Test|3> selected peer config 'Test'
2016-09-13 12:15:14.913 29[IKE] <Test|3> initiating EAP_MSCHAPV2 method (id 0xB9)
2016-09-13 12:15:14.913 29[IKE] <Test|3> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
2016-09-13 12:15:14.913 29[IKE] <Test|3> peer supports MOBIKE
2016-09-13 12:15:14.913 29[LIB] <Test|3> signature verification:
2016-09-13 12:15:14.913 29[DMN] <Test|3> thread 29 received 11
2016-09-13 12:15:14.914 29[LIB] <Test|3>  dumping 1 stack frame addresses:
2016-09-13 12:15:14.914 29[LIB] <Test|3>   /lib64/libpthread.so.0 @ 0x7f404db65000 [0x7f404db74100]
2016-09-13 12:15:14.918 29[LIB] <Test|3>     -> sigaction.c:?
2016-09-13 12:15:14.921 29[DMN] <Test|3> killing ourself, received critical signal

Here's the full log:

2016-09-13 12:15:14.792 12[ENC] <3> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2016-09-13 12:15:14.792 12[CFG] <3> looking for an ike config for <Security Gateway IP>...<Client IP>
2016-09-13 12:15:14.792 12[CFG] <3>   candidate: %any...%any, prio 28
2016-09-13 12:15:14.793 12[CFG] <3>   candidate: %any...%any, prio 28
2016-09-13 12:15:14.793 12[CFG] <3>   candidate: %any...%any, prio 28
2016-09-13 12:15:14.793 12[CFG] <3> found matching ike config: %any...%any with prio 28
2016-09-13 12:15:14.793 12[IKE] <3> <Client IP> is initiating an IKE_SA
2016-09-13 12:15:14.793 12[CFG] <3> selecting proposal:
2016-09-13 12:15:14.793 12[CFG] <3>   proposal matches
2016-09-13 12:15:14.793 12[CFG] <3> received proposals: IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_MD5_96/HMAC_SHA1_96/AES_XCBC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_2048_256/MODP_1024, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_2048_256/MODP_1024
2016-09-13 12:15:14.793 12[CFG] <3> configured proposals: IKE:AES_CBC_256/HMAC_MD5_96/HMAC_SHA1_96/PRF_HMAC_MD5/PRF_HMAC_SHA1/MODP_1024
2016-09-13 12:15:14.793 12[CFG] <3> selected proposal: IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
2016-09-13 12:15:14.793 12[LIB] <3> size of DH secret exponent: 252 bits
2016-09-13 12:15:14.793 12[IKE] <3> remote host is behind NAT
2016-09-13 12:15:14.794 12[IKE] <3> sending cert request for "<Certificate Authority>" 
2016-09-13 12:15:14.794 12[ENC] <3> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
2016-09-13 12:15:14.913 29[ENC] <3> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
2016-09-13 12:15:14.913 29[CFG] <3> looking for peer configs matching <Security Gateway IP>[<FQDN>]...<Client IP>[<User>]
2016-09-13 12:15:14.913 29[CFG] <3>   candidate "Test", match: 1/1/28 (me/other/ike)
2016-09-13 12:15:14.913 29[CFG] <Test|3> selected peer config 'Test'
2016-09-13 12:15:14.913 29[IKE] <Test|3> initiating EAP_MSCHAPV2 method (id 0xB9)
2016-09-13 12:15:14.913 29[IKE] <Test|3> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
2016-09-13 12:15:14.913 29[IKE] <Test|3> peer supports MOBIKE
2016-09-13 12:15:14.913 29[LIB] <Test|3> signature verification:
2016-09-13 12:15:14.913 29[DMN] <Test|3> thread 29 received 11
2016-09-13 12:15:14.914 29[LIB] <Test|3>  dumping 1 stack frame addresses:
2016-09-13 12:15:14.914 29[LIB] <Test|3>   /lib64/libpthread.so.0 @ 0x7f404db65000 [0x7f404db74100]
2016-09-13 12:15:14.918 29[LIB] <Test|3>     -> sigaction.c:?
2016-09-13 12:15:14.921 29[DMN] <Test|3> killing ourself, received critical signal

Here's the ipsec.conf part for conn Test:

conn Test
    # left - local (server) side
    left=%any
    leftid=%any
    leftauth=pubkey
    leftcert=<certificate>
    leftsubnet=10.x.x.0/24

    # right - remote (client) side
    right=%any
    rightid=%
    rightsendcert=never
    rightauth=eap-mschapv2
    rightsourceip=%wifi-pool-1,%wifi-pool-2,%wifi-pool-3,%wifi-pool-4
    auto=add

#15 Updated by Danny Kulchinsky about 4 years ago

Quick update, with the Client in question it seems to work perfectly :) still doing tests, but so far so good.

But it has broken something... since EAP-MSCHAPV2 causes the daemon to crash...

#16 Updated by Tobias Brunner about 4 years ago

Quick update, with the Client in question it seems to work perfectly :) still doing tests, but so far so good.

I noticed there is a memory leak in the patch above (the original ID payload is not destroyed). I've attached an updated patch.

But it has broken something... since EAP-MSCHAPV2 causes the daemon to crash...

Yes, this happens if the identity that's used is the one from the IKE_SA. When it then gets replaced with a clone the original identity is destroyed and the reference gets invalid. The updated patch fixes this (it basically doesn't remove the get_my_id() call and adds the set_my_id() call right before that).

#17 Updated by Danny Kulchinsky about 4 years ago

Ok, with the new patch things look good :)

I'm waiting for the team to finish their round of tests to verify everything is working as expected.

Tobias, many thanks for your incredible support!

#18 Updated by Tobias Brunner over 3 years ago

  • Related to Issue #2099: charon.cert_id_binding patch for new versions added

Also available in: Atom PDF