[strongSwan] rightid (Ipsec with Certificates)

[Andreas Steffen]

Hello Lakshmi,

rightid and leftid are required to prevent an endpoint having
a valid and trusted certificate to take on the identity of another
endpoint (e.g. a client acting as the SEGW).

The leftid must exactly match either the subjectDistinguishedName or
a subjectAltName in the leftcert. rightid must match the identity
of the remote endpoint but may contain wildcards, the most general
being rightid=%any which returns a full match for any id. rightid
is sent by the initiator in the optional IDr payload in order to
assist the remote endpoint in the selection of the identity to be
used if the remote endpoint has multiple identities (e.g. multiple
certificates). If rightid contains at least one wildcard ('*' character)
then IDr is omitted but the the responder must always return its
full IDr not containing any wildcards.

In your first example where you define

  rightid="C=*, O=*, OU=*, CN=*"

the IDr payload is not sent by the initiator and the responder
returns an IDr of the form

 "O=Alcatel, CN=654321 at alcatel-lucent.com"

which does not match your rightid template because the C= and OU=
RDNs are missing and the following local error is produced:

constraint check failed: identity 'C=*, O=*, OU=*, CN=*' required
selected peer config '30' inacceptable
no alternative config found

In order for your example to work you must either define

  rightid="O=*, CN=*"

or if you don't know exaclty which type of RDNs are used by the
SEGW in its certificate just

  rightid=%any

Please be aware that the use of wildcards makes your endpoints
vulnerable to kind of man-in-the-middle attacks mentioned in the
first paragraph.

In your second example you didn't specify any rightid. In that case
by default the IP address specified by right is used as rightid, i.e.

  rightid=172.21.11.181

Since this IDr is not contained in the SEGW's certificate the
remote error

parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error

is received.

I hope this helps!

Best regards

Andreas

On 14.01.2012 03:59, Umarale, Lakshmi S (Lakshmi) wrote:
> This is our configuration –
> 
>  
> 
> SEG <IPSEC TUNNEL> ENodeB
> 
>  
> 
> The eNodeB is the initiator.
> 
>  
> 
> The eNodeB must know in advance the attributes that it will receive in
> the certificate of the SEG in the name of the SEG.
> 
> I have been able to get the authentication working only by specifying
> rightid="O=*, CN=*" (attributes in the certificate of the SEG) on the eNodeB
> 
>  
> 
> If we set the rightid as "C=*, O=*, OU=*, CN=*"
> 
>  
> 
> initiating IKE_SA 30[3] to 172.21.11.181
> 
> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> 
> sending packet: from 172.21.11.21[500] to 172.21.11.181[500]
> 
> received packet: from 172.21.11.181[500] to 172.21.11.21[500]
> 
> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
> CERTREQ N(MULT_AUTH) ]
> 
> received cert request for "O=Alcatel, CN=CMS"
> 
> sending cert request for "O=Alcatel, CN=CMS"
> 
> authentication of 'O=Alcatel, CN=123456.CMS1' (myself) with RSA
> signature successful
> 
> sending end entity cert "O=Alcatel, CN=123456.CMS1"
> 
> sending issuer cert "O=Alcatel, CN=CMS1"
> 
> establishing CHILD_SA 30
> 
> generating IKE_AUTH request 1 [ IDi CERT CERT N(INIT_CONTACT) CERTREQ
> AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ]
> 
> sending packet: from 172.21.11.21[500] to 172.21.11.181[500]
> 
> received packet: from 172.21.11.181[500] to 172.21.11.21[500]
> 
> parsed IKE_AUTH response 1 [ IDr CERT AUTH SA TSi TSr ]
> 
> received end entity cert "O=Alcatel, CN=654321 at alcatel-lucent.com
> <mailto:CN=654321 at alcatel-lucent.com>"
> 
>   using certificate "O=Alcatel, CN=654321 at alcatel-lucent.com
> <mailto:CN=654321 at alcatel-lucent.com>"
> 
>   using trusted ca certificate "O=Alcatel, CN=CMS"
> 
> checking certificate status of "O=Alcatel, CN=654321 at alcatel-lucent.com
> <mailto:CN=654321 at alcatel-lucent.com>"
> 
> certificate status is not available
> 
>   reached self-signed root ca with a path length of 0
> 
> authentication of 'O=Alcatel, CN=654321 at alcatel-lucent.com
> <mailto:CN=654321 at alcatel-lucent.com>' with RSA signature successful
> 
> constraint check failed: identity 'C=*, O=*, OU=*, CN=*' required
> 
> selected peer config '30' inacceptable
> 
> no alternative config found
> 
>  
> 
>  
> 
> Without specifying the righid, I get authentication failure
> 
>  
> 
> initiating IKE_SA 30[8] to 172.21.11.181
> 
> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> 
> sending packet: from 172.21.11.21[500] to 172.21.11.181[500]
> 
> received packet: from 172.21.11.181[500] to 172.21.11.21[500]
> 
> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
> CERTREQ N(MULT_AUTH) ]
> 
> received cert request for "O=Alcatel, CN=CMS"
> 
> sending cert request for "O=Alcatel, CN=CMS"
> 
> authentication of 'O=Alcatel, CN=123456.CMS1' (myself) with RSA
> signature successful
> 
> sending end entity cert "O=Alcatel, CN=123456.CMS1"
> 
> sending issuer cert "O=Alcatel, CN=CMS1"
> 
> establishing CHILD_SA 30
> 
> generating IKE_AUTH request 1 [ IDi CERT CERT N(INIT_CONTACT) CERTREQ
> IDr AUTH SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ]
> 
> sending packet: from 172.21.11.21[500] to 172.21.11.181[500]
> 
> received packet: from 172.21.11.181[500] to 172.21.11.21[500]
> 
> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
> 
> received AUTHENTICATION_FAILED notify error
> 
>  
> 
> I would like to understand the purpose of leftid and rightid. Why do we
> need to specify them?
> 
>  
> 
> Regards,
> 
> Lakshmi

======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4489 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20120114/6a2640ba/attachment.bin>