Issue #963: server certificate does not match to 'moon.int.XX.au' - strongSwan

Issue #963

server certificate does not match to 'moon.int.XX.au'

Added by G S over 10 years ago. Updated about 10 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Martin Willi

Category:

configuration

Affected version:

5.3.0

Resolution:

No change required

Description

I am trying to integrate Strongswan xauth-eap/eap-ttls with FreeRadius.

Strongwan is configured with rightauth2=xauth-eap.

Logs from Strongswan:

May 21 09:22:01 localhost charon: 15[CFG] sending RADIUS Access-Request to server 'server-a'
May 21 09:22:01 localhost charon: 15[CFG] received RADIUS Access-Challenge from server 'server-a'
May 21 09:22:01 localhost charon: 15[TLS] EAP_TTLS version is v0
May 21 09:22:01 localhost charon: 15[CFG] sending RADIUS Access-Request to server 'server-a'
May 21 09:22:01 localhost charon: 15[CFG] received RADIUS Access-Challenge from server 'server-a'
May 21 09:22:01 localhost charon: 15[TLS] negotiated TLS 1.0 using suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
May 21 09:22:01 localhost charon: 15[CFG] sending RADIUS Access-Request to server 'server-a'
May 21 09:22:01 localhost charon: 15[CFG] received RADIUS Access-Challenge from server 'server-a'
May 21 09:22:01 localhost charon: 15[TLS] server certificate does not match to 'moon.int.XX.au'
May 21 09:22:01 localhost charon: 15[TLS] sending fatal TLS alert 'access denied'
May 21 09:22:01 localhost charon: 15[CFG] sending RADIUS Access-Request to server 'server-a'
May 21 09:22:02 localhost charon: 15[CFG] received RADIUS Access-Reject from server 'server-a'
May 21 09:22:02 localhost charon: 15[IKE] RADIUS authentication of 'xx.xx' failed
May 21 09:22:02 localhost charon: 15[IKE] XAuth authentication of 'xx.xx' failed
May 21 09:22:02 localhost charon: 15[ENC] generating TRANSACTION request 723118549 [ HASH CPS(X_STATUS) ]
May 21 09:22:02 localhost charon: 15[NET] sending packet: from 55.55.55.55[500] to 10.8.0.41[500] (76 bytes)
May 21 09:22:02 localhost charon: 16[NET] received packet: from 10.8.0.41[500] to 55.55.55.55[500] (92 bytes)
May 21 09:22:02 localhost charon: 16[ENC] parsed TRANSACTION response 723118549 [ HASH CPA(X_STATUS) ]
May 21 09:22:02 localhost charon: 16[IKE] destroying IKE_SA after failed XAuth authentication

Logs from FreeRadius:

 Executing group from file /etc/freeradius/sites-enabled/default
+group authenticate {
[eap] Request found, released from the list
[eap] EAP/ttls
[eap] processing type ttls
[ttls] Authenticate
[ttls] processing EAP-TLS
  TLS Length 7
[ttls] Length Included
[ttls] eaptls_verify returned 11 
[ttls] <<< TLS 1.0 Alert [length 0002], fatal access_denied  
TLS Alert read:fatal:access denied
    TLS_accept: failed in SSLv3 read client certificate A
rlm_eap: SSL error error:14094419:SSL routines:SSL3_READ_BYTES:tlsv1 alert access denied
SSL: SSL_read failed inside of TLS (-1), TLS session fails.
TLS receive handshake failed during operation
[ttls] eaptls_process returned 4 
[eap] Handler failed in EAP/ttls
[eap] Failed in EAP select
++[eap] = invalid
+} # group authenticate = invalid
Failed to authenticate the user.
Login incorrect (TLS Alert read:fatal:access denied): [xx.xx/<via Auth-Type = EAP>] (from client localhost port 2 cli 10.8.0.41[500])
Using Post-Auth-Type Reject
 Executing group from file /etc/freeradius/sites-enabled/default
+group REJECT {
[attr_filter.access_reject]     expand: %{User-Name} -> xx.xx
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] = updated
+} # group REJECT = updated
Delaying reject of request 3 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 3
Sending Access-Reject of id 45 to 127.0.0.1 port 49366
    EAP-Message = 0x04030004
    Message-Authenticator = 0x00000000000000000000000000000000
Waking up in 3.9 seconds.
Cleaning up request 0 ID 42 with timestamp +6
Cleaning up request 1 ID 43 with timestamp +6
Cleaning up request 2 ID 44 with timestamp +6
Waking up in 0.9 seconds.
Cleaning up request 3 ID 45 with timestamp +6
Ready to process requests.

I was thinking that the problem was on the FR side and I even posted to FR mail list http://freeradius.1045715.n5.nabble.com/ttls-lt-lt-lt-Unknown-TLS-version-length-0002-td5734046.html They claim that this is some OpenSSL issue. I use OpenSSL 1.0.1f. It is worth to mention that both FR and Strongswan are installed and were compiled on the same machine. I also tried to set aaa_identity to equal the vaule from the subject name cert used by FR.

Can you provide some clue?

History

#1 Updated by Tobias Brunner over 10 years ago

Description updated (diff)
Status changed from New to Feedback

Does your certificate contain moon.int.XX.au as subjectAltName extension? If not, did try setting aaa_identity to the complete subject DN of the certificate (if so, could you post the log)? Could you post the certificate?

The error on the FreeRADIUS side might be due to the client aborting the authentication and thus not providing a certificate on its own (thus the "TLS_accept: failed in SSLv3 read client certificate").

#2 Updated by G S over 10 years ago

Tobias Brunner wrote:

Does your certificate contain moon.int.XX.au as subjectAltName extension?

FreeRadius cert does not contain subjectAltName.

If not, did try setting aaa_identity to the complete subject DN of the certificate (if so, could you post the log)?

Yes, I tried aaa_identity and it did not help. What logs do you want to see? I already posted interesting logs in my original post.

Could you post the certificate?

Public key would be enough?

The error on the FreeRADIUS side might be due to the client aborting the authentication and thus not providing a certificate on its own (thus the "TLS_accept: failed in SSLv3 read client certificate").

It is EAP-TTLS not EAP-TLS, so clients do not need to provide their own certs.

#3 Updated by G S over 10 years ago

Just want to add that I use IKEv1.

#4 Updated by Martin Willi over 10 years ago

I am trying to integrate Strongswan xauth-eap/eap-ttls with FreeRadius.

Just want to add that I use IKEv1.

Please note that the xauth-eap bridge is used to verify the XAuth username/password combination using an EAP method. This requires that you have a username/password EAP method as backend, such as EAP-MD5 or EAP-MSCHAPv2 (usually over eap-radius).

Our EAP-TTLS plugin supports tunneling other EAP methods only, it currently does not support tunneled CHAP/PAP authentication. So if you use EAP-TTLS in xauth-eap you'll need to do an inner EAP method to verify the password. I'd guess this should work, but I don't think I've ever tried that combination.

Regards
Martin

#5 Updated by G S over 10 years ago

UPDATE:

1) aaa_identity does not help ;/ Do you know why?
2) I just tried to use on the RADIUS side the same cert that is being used on the Strongswan side. It contains SubjectAltName set to moon.int.XX.au and now... I have another problem :) It complains that it cannot find "TLS public key" which in fact is sent from FR (received TLS server certificate 'C=PD, OU=XXX, CN=moon.int.XX.au')

May 21 11:40:52 localhost charon: 16[TLS] EAP_TTLS version is v0
May 21 11:40:52 localhost charon: 16[CFG] sending RADIUS Access-Request to server 'server-a'
May 21 11:40:52 localhost charon: 16[CFG] received RADIUS Access-Challenge from server 'server-a'
May 21 11:40:52 localhost charon: 16[TLS] negotiated TLS 1.0 using suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
May 21 11:40:52 localhost charon: 16[CFG] sending RADIUS Access-Request to server 'server-a'
May 21 11:40:52 localhost charon: 16[CFG] received RADIUS Access-Challenge from server 'server-a'
May 21 11:40:52 localhost charon: 16[CFG] sending RADIUS Access-Request to server 'server-a'
May 21 11:40:52 localhost charon: 16[CFG] received RADIUS Access-Challenge from server 'server-a'
May 21 11:40:52 localhost charon: 16[TLS] received TLS server certificate 'C=PD, OU=XXX, CN=moon.int.XX.au'
May 21 11:40:52 localhost charon: 16[TLS] received TLS intermediate certificate 'CN=SUBCA'
May 21 11:40:52 localhost charon: 16[TLS] received TLS intermediate certificate 'C=DK, L=Aarhus, O=frogger CA, CN=theheat.dk'
May 21 11:40:52 localhost charon: 16[TLS] no TLS public key found for server 'moon.int.XX.au'
May 21 11:40:52 localhost charon: 16[TLS] sending fatal TLS alert 'certificate unknown'
May 21 11:40:52 localhost charon: 16[CFG] sending RADIUS Access-Request to server 'server-a'
May 21 11:40:53 localhost charon: 16[CFG] received RADIUS Access-Reject from server 'server-a'
May 21 11:40:53 localhost charon: 16[IKE] RADIUS authentication of 'xx.xx' failed
May 21 11:40:53 localhost charon: 16[IKE] XAuth authentication of 'xx.xx' failed
May 21 11:40:53 localhost charon: 16[ENC] generating TRANSACTION request 3884677090 [ HASH CPS ]
May 21 11:40:53 localhost charon: 16[NET] sending packet: from 55.55.55.55⁵⁰⁰ to 10.8.0.41⁵⁰⁰ (76 bytes)
May 21 11:40:53 localhost charon: 05[NET] received packet: from 10.8.0.41⁵⁰⁰ to 55.55.55.55⁵⁰⁰ (92 bytes)
May 21 11:40:53 localhost charon: 05[ENC] parsed TRANSACTION response 3884677090 [ HASH CPA ]
May 21 11:40:53 localhost charon: 05[IKE] destroying IKE_SA after failed XAuth authentication

#6 Updated by G S over 10 years ago

Martin Willi wrote:

I am trying to integrate Strongswan xauth-eap/eap-ttls with FreeRadius.

Just want to add that I use IKEv1.

Please note that the xauth-eap bridge is used to verify the XAuth username/password combination using an EAP method. This requires that you have a username/password EAP method as backend, such as EAP-MD5 or EAP-MSCHAPv2 (usually over eap-radius).

Our EAP-TTLS plugin supports tunneling other EAP methods only, it currently does not support tunneled CHAP/PAP authentication. So if you use EAP-TTLS in xauth-eap you'll need to do an inner EAP method to verify the password. I'd guess this should work, but I don't think I've ever tried that combination.

Clear, I am about to use EAP-GTC inside EAP-TTLS.

#7 Updated by Tobias Brunner over 10 years ago

1) aaa_identity does not help ;/ Do you know why?

Because it only applies to configs with EAP authentication, not XAuth authentication.

2) I just tried to use on the RADIUS side the same cert that is being used on the Strongswan side. It contains SubjectAltName set to moon.int.XX.au and now... I have another problem :) It complains that it cannot find "TLS public key" which in fact is sent from FR (received TLS server certificate 'C=PD, OU=XXX, CN=moon.int.XX.au')

That's because during EAP processing in the xauth-eap plugin the regular credential sets are not used, so the EAP-TTLS method has no access to the globally loaded root certificates and thus cannot verify the server certificate.

#8 Updated by Martin Willi over 10 years ago

16[TLS] received TLS server certificate 'C=PD, OU=XXX, CN=moon.int.XX.au'
16[TLS] received TLS intermediate certificate 'CN=SUBCA'
16[TLS] received TLS intermediate certificate 'C=DK, L=Aarhus, O=frogger CA, CN=theheat.dk'
16[TLS] no TLS public key found for server 'moon.int.XX.au'

When thinking about it one more time, most likely this won't gonna work. The xauth-eap backend uses two EAP methods to verify your XAuth password, a frontend and a backend. The frontend is the EAP client, the backend the EAP server (usually over eap-radius).

The frontend must act on behalf of the IKE client, though, this is why it disables access to all credentials except the XAuth password. If it wouldn't do so, the frontend could authenticate with credentials from the gateway. We really have to avoid that as it is not unlikely we have the XAuth password available through the credential manager.

In theory we could allow any available certificate credentials during frontend authentication, and just block access to private- and shared-keys. But this is currently not done, we restrict access to any other credentials during frontend authentication.

To keep it simple: EAP-TTLS currently won't work as an xauth-eap backend.

#9 Updated by G S over 10 years ago

To summarise all above comments...

Currently, if:
-our clients are just IKEv1 capable and
-we use IKE phase 1.5 xauth and
-we want to use TTLS/PEAP and
-we want to use FreeRADIUS as a backend then we have a problem! This kind of intergation will not work with Strongswan. Is that correct?

Maybe there is any other way to do it without xauth-eap?

#10 Updated by Martin Willi over 10 years ago

Maybe there is any other way to do it without xauth-eap?

Since 5.1.0 the eap-radius plugin can directly verify XAuth credentials over RADIUS by using User-Name and User-Password attributes, making xauth-eap mostly obsolete.

Of course that won't provide the same level of security on your strongSwan<->FreeRADIUS path as with EAP-TTLS. But you might use other mechanisms to further protect that traffic if required, for example using IPsec.

#11 Updated by G S over 10 years ago

Martin Willi wrote:

Maybe there is any other way to do it without xauth-eap?

Since 5.1.0 the eap-radius plugin can directly verify XAuth credentials over RADIUS by using User-Name and User-Password attributes, making xauth-eap mostly obsolete.

I thought that eap-radius can be used only with IKEv2. Can I use it to verify XAuth credentials with IKEv1?

Of course that won't provide the same level of security on your strongSwan<->FreeRADIUS path as with EAP-TTLS. But you might use other mechanisms to further protect that traffic if required, for example using IPsec.

This is clear.

#12 Updated by G S about 10 years ago

Ticket to be closed.

#13 Updated by Tobias Brunner about 10 years ago

Category set to configuration
Status changed from Feedback to Closed
Assignee set to Martin Willi
Resolution set to No change required

Project

General

Profile

strongSwan

Issues