Project

General

Profile

Bug #2238

eap-dynamic with ca certificate constraint for initiator broken

Added by Noel Kuntze over 3 years ago. Updated over 3 years ago.

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

Description

Hello,

When eap-dynamic is used with eap-tls authentication and a ca constraint is set, the latter seems to make authentication fail, even when the intiator's certificate is signed by it.
charon.log is attached.

The important section in the log is here:

Tue, 2017-01-31 17:00 12[TLS] <mobile-eap-tls|2> received TLS CertificateVerify handshake (516 bytes)
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2>   using certificate "C=DE, O=ThermiCorp, CN=Thermis Style" 
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2>   certificate "C=DE, O=ThermiCorp, CN=Thermis Style" key: 4096 bit RSA
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2>   using trusted intermediate ca certificate "C=DE, ST=Baden-W??rttemberg, O=ThermiCorp, OU=UserCA, CN=ThermiCorp UserCA Level 2" 
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2> checking certificate status of "C=DE, O=ThermiCorp, CN=Thermis Style" 
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2> ocsp check skipped, no ocsp found
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2> certificate status is not available
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2>   certificate "C=DE, ST=Baden-W??rttemberg, O=ThermiCorp, OU=UserCA, CN=ThermiCorp UserCA Level 2" key: 4096 bit RSA
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2>   using trusted ca certificate "C=DE, ST=Baden-W??rttemberg, L=Haslach, O=ThermiCorp, OU=Root CA, CN=ThermiCorp Root CA, E=noel.kuntze@google
mail.com" 
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2> checking certificate status of "C=DE, ST=Baden-W??rttemberg, O=ThermiCorp, OU=UserCA, CN=ThermiCorp UserCA Level 2" 
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2> ocsp check skipped, no ocsp found
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2> certificate status is not available
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2>   certificate "C=DE, ST=Baden-W??rttemberg, L=Haslach, O=ThermiCorp, OU=Root CA, CN=ThermiCorp Root CA, E=noel.kuntze@googlemail.com" key: 40
96 bit RSA
Tue, 2017-01-31 17:00 12[CFG] <mobile-eap-tls|2>   reached self-signed root ca with a path length of 1
Tue, 2017-01-31 17:00 12[TLS] <mobile-eap-tls|2> verified signature with SHA256/RSA
Tue, 2017-01-31 17:00 12[TLS] <mobile-eap-tls|2> processing TLS ChangeCipherSpec record (1 bytes)
Tue, 2017-01-31 17:00 12[TLS] <mobile-eap-tls|2> buffering 54 bytes, 54 bytes of 85 byte TLS record received
Tue, 2017-01-31 17:00 12[TLS] <mobile-eap-tls|2> sending EAP_TLS acknowledgement packet
Tue, 2017-01-31 17:00 12[ENC] <mobile-eap-tls|2> generating IKE_AUTH response 8 [ EAP/REQ/TLS ]
Tue, 2017-01-31 17:00 12[NET] <mobile-eap-tls|2> sending packet: from 188.68.37.10[4500] to 78.43.42.57[47525] (67 bytes)
Tue, 2017-01-31 17:00 23[NET] <mobile-eap-tls|2> received packet: from 78.43.42.57[47525] to 188.68.37.10[4500] (98 bytes)
Tue, 2017-01-31 17:00 23[ENC] <mobile-eap-tls|2> parsed IKE_AUTH request 9 [ EAP/RES/TLS ]
Tue, 2017-01-31 17:00 23[TLS] <mobile-eap-tls|2> buffering 31 bytes, 85 bytes of 85 byte TLS record received
Tue, 2017-01-31 17:00 23[TLS] <mobile-eap-tls|2> processing buffered TLS Handshake record (80 bytes)
Tue, 2017-01-31 17:00 23[TLS] <mobile-eap-tls|2> received TLS Finished handshake (12 bytes)
Tue, 2017-01-31 17:00 23[TLS] <mobile-eap-tls|2> sending TLS ChangeCipherSpec record (1 bytes)
Tue, 2017-01-31 17:00 23[TLS] <mobile-eap-tls|2> sending TLS Finished handshake (12 bytes)
Tue, 2017-01-31 17:00 23[TLS] <mobile-eap-tls|2> sending TLS Handshake record (80 bytes)
Tue, 2017-01-31 17:00 23[TLS] <mobile-eap-tls|2> sending EAP_TLS packet (101 bytes)
Tue, 2017-01-31 17:00 23[ENC] <mobile-eap-tls|2> generating IKE_AUTH response 9 [ EAP/REQ/TLS ]
Tue, 2017-01-31 17:00 23[NET] <mobile-eap-tls|2> sending packet: from 188.68.37.10[4500] to 78.43.42.57[47525] (162 bytes)
Tue, 2017-01-31 17:00 18[NET] <mobile-eap-tls|2> received packet: from 78.43.42.57[47525] to 188.68.37.10[4500] (67 bytes)
Tue, 2017-01-31 17:00 18[ENC] <mobile-eap-tls|2> parsed IKE_AUTH request 10 [ EAP/RES/TLS ]
Tue, 2017-01-31 17:00 18[TLS] <mobile-eap-tls|2> received EAP_TLS acknowledgement packet
Tue, 2017-01-31 17:00 18[IKE] <mobile-eap-tls|2> EAP method EAP_TLS succeeded, MSK established
Tue, 2017-01-31 17:00 18[ENC] <mobile-eap-tls|2> generating IKE_AUTH response 10 [ EAP/SUCC ]
Tue, 2017-01-31 17:00 18[NET] <mobile-eap-tls|2> sending packet: from 188.68.37.10[4500] to 78.43.42.57[47525] (65 bytes)
Tue, 2017-01-31 17:00 26[NET] <mobile-eap-tls|2> received packet: from 78.43.42.57[47525] to 188.68.37.10[4500] (97 bytes)
Tue, 2017-01-31 17:00 26[ENC] <mobile-eap-tls|2> parsed IKE_AUTH request 11 [ AUTH ]
Tue, 2017-01-31 17:00 26[IKE] <mobile-eap-tls|2> authentication of 'C=DE, O=ThermiCorp, CN=Thermis Style' with EAP successful
Tue, 2017-01-31 17:00 26[CFG] <mobile-eap-tls|2> constraint check failed: peer not authenticated by CA 'C=DE, ST=Baden-W??rttemberg, O=ThermiCorp, OU=UserCA, CN=ThermiCorp UserCA Level 2'
Tue, 2017-01-31 17:00 26[CFG] <mobile-eap-tls|2> selected peer config 'mobile-eap-tls' inacceptable: non-matching authentication done
Tue, 2017-01-31 17:00 26[CFG] <mobile-eap-tls|2> switching to peer config 'mobile-eap-mschapv2'


Complete configuration:

charon.log (105 KB) charon.log Noel Kuntze, 31.01.2017 17:02

Associated revisions

Revision 865fd804 (diff)
Added by Tobias Brunner over 3 years ago

eap-dynamic: Publish the get_auth() method of the wrapped EAP method

Fixes #2238.

History

#1 Updated by Tobias Brunner over 3 years ago

  • Tracker changed from Issue to Bug
  • Category set to libcharon
  • Status changed from New to Feedback

The eap-dynamic plugin currently does not implement the get_auth() method. Could you please try if the patch in the 2238-eap-dynamic-auth branch works for you?

But I wonder, what happens if the client selects EAP-MSCHAPv2? Since there is no client certificate then, wouldn't the constraint prevent that too?

#2 Updated by Noel Kuntze over 3 years ago

Yes, the patch works.
Yes, if EAP-MSCHAPv2 is chosen, the constraint prevents continuing with that connection. However, if a second connection with EAP-MSCHAPv2 is defined, charon switches to using it and it works fine.

#3 Updated by Tobias Brunner over 3 years ago

  • Assignee set to Tobias Brunner
  • Target version set to 5.5.2
  • Resolution set to Fixed

OK, I'll line this up for the next release.

#4 Updated by Tobias Brunner over 3 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF