Project

General

Profile

Issue #719

strongSwan ID matching behavior questions

Added by Manoj Kolakur over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
Resolution:
No change required

Description

Hi,

I'm looking for some behavioral configurations in Strongswan.

How Strongswan Client uses rightid present in ipsec.conf.
My understanding as below, please correct me if I'm wrong.

if rightid= example.com
then Client matches with SubAlt Name field of certificate with rightid which is in this case example.com.

if rightid= %example.com
then Client matches with IDr field of IKE message with rightid which is in this case example.com.

if rightid= %any
then Client matches with IDr field of IKE message with SubAlt Name field of certificate.

I do observe StrongSwan Server is sending IDr format as ID_DER_ASN1_DN. When there is a mismatch in leftid and SubAlt Name field of certificate. Is this my observation true?

Is there a way we can configure/force StrongSwan server to send IDr format as IP, which is when leftid=IP. Even if SubAlt Name field of certificate is different?

waiting for your valuable inputs.

Best Regards,
Manoj.

History

#1 Updated by Tobias Brunner over 7 years ago

  • Tracker changed from Feature to Issue
  • Category set to configuration
  • Status changed from New to Feedback
  • Assignee set to Tobias Brunner

if rightid= example.com
then Client matches with SubAlt Name field of certificate with rightid which is in this case example.com.

The client sends example.com as IDr in the IKE_AUTH request and expects that the IDr returned by the server is the same (it will fail if it is not). The identity must be confirmed by the certificate, so it either has to match the subject DN or one of the subjectAltNames.

if rightid= %example.com
then Client matches with IDr field of IKE message with rightid which is in this case example.com.

The client will not send an IDr in the IKE_AUTH request. The IDr returned by the server does not have to be the same but both identities have to be confirmed by the certificate (see above). This, for instance, allows the server to use the subject DN as identity while the clients can use the FQDN to verify the server's identity as long as the FQDN is contained as subjectAltName in the certificate.

if rightid= %any
then Client matches with IDr field of IKE message with SubAlt Name field of certificate.

The client will not send an IDr in the IKE_AUTH request and will accept any identity returned by the server (it must be confirmed by the certificate though).

I do observe StrongSwan Server is sending IDr format as ID_DER_ASN1_DN.
When there is a mismatch in leftid and SubAlt Name field of certificate. Is this my observation true?

Yes, if the configured leftid is not confirmed by the certificate it will fall back to the subject DN (you should see an appropriate message in the log).

Is there a way we can configure/force StrongSwan server to send IDr format as IP, which is when leftid=IP. Even if SubAlt Name field of certificate is different?

No, the IP must be contained as subjectAltName in the certificate if you want to use it as leftid.

#2 Updated by Manoj Kolakur over 7 years ago

Thanks Tobias for your responses.

I'm bit confused,I did not understand the the real difference between configuring rightid= %example.com and rightid= %any at client side.

could you please explain.

Is my statements below True or Flase.
1) If % used in leftid then client will not send IDr in IKE_AUTH request.
2) If % used in leftid then client will not verify/match for IDr of IKE_AUTH response from Server.It can have any value but client does not bother to match with leftid.

Best Regards,
Manoj.

#3 Updated by Tobias Brunner over 7 years ago

1) If % used in leftid then client will not send IDr in IKE_AUTH request.

Using % with leftid has no effect (except for %any). If you use it with rightid then your statement above is correct.

2) If % used in leftid then client will not verify/match for IDr of IKE_AUTH response from Server.It can have any value but client does not bother to match with leftid.

Again, % has only an effect if used with rightid. IDr is always verified against the certificate returned by the responder, so it must match one of the identities contained in it (subject DN or one of the subjectAltNames). If %any is used with rightid it literally means that any identity is accepted, so no matching is performed beyond verifying IDr and the certificate. But if % is followed by an identity that identity has to match one of the identities contained in the certificate, but it does not have to match IDr.

#4 Updated by Manoj Kolakur over 7 years ago

Thanks Tobias for your responses, my typo actually I meant rightid only.My apologies for that.

1) IDr is always verified against the certificate returned by the responder.
Is there any config to not to verify IDr against the certificate by the responder.

2) if rightid=IP and returned certificate contains SubAltName as DNS:example.com.
Does Strongswan resolve domain name example.com and then match with the IP. If not is there any config to do dns query off example.com and then match with rightid=IP.

Best Regards,
Manoj.

#5 Updated by Tobias Brunner over 7 years ago

1) IDr is always verified against the certificate returned by the responder.

Is there any config to not to verify IDr against the certificate by the responder.

No currently not. Martin added such an option in the cert-id-binding-option branch of our repository, see this mail for instance.

2) if rightid=IP and returned certificate contains SubAltName as DNS:example.com.

Does Strongswan resolve domain name example.com and then match with the IP. If not is there any config to do dns query off example.com and then match with rightid=IP.

No, FQDNs are not resolved when used as identities, there is no option to change that.

#6 Updated by Manoj Kolakur over 7 years ago

Thanks Tobias for all your responses.

Will check on the link provided.

Best Regards,
Manoj.

#7 Updated by Tobias Brunner over 7 years ago

  • Subject changed from Strong Swan Fetature behavior question to strongSwan ID matching behavior questions
  • Status changed from Feedback to Closed
  • Resolution set to No change required

#8 Updated by Manoj Kolakur over 7 years ago

Tobias,

I have one more query.

IDr is always verified against the certificate returned by the responder, so it must match one of the identities contained in it (subject DN or one of the subjectAltNames).

Here subject DN means only CN field of Subject should match or full Subject contents it should match.

Example: Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
OU=FreeSoft, CN=www.freesoft.org/emailAddress=

Best Regards,
Manoj.

#9 Updated by Tobias Brunner over 7 years ago

IDr is always verified against the certificate returned by the responder, so it must match one of the identities contained in it (subject DN or one of the subjectAltNames).

Here subject DN means only CN field of Subject should match or full Subject contents it should match.

subject DN means the complete distinguished name in the X.509 subject field. strongSwan does not match IDr against individual RDNs such as CN.

Also available in: Atom PDF