[strongSwan] rightid (Ipsec with Certificates)

Fri Jan 27 18:17:18 CET 2012

Hi

Also, i think the following entries in the left-peer-gw should also work if
iam right?

In the ipsec.conf of left and/or right GWs
-------------------------------------------------------------
 ..........
.........
....
leftcert=testcert.pem
rightca=%same
....
....
-------------------------------------------------

- no need to mentione leftid and rightid, right?

br
rajiv

On Sat, Jan 14, 2012 at 10:47 PM, Umarale, Lakshmi S (Lakshmi) <
lakshmi.umarale at alcatel-lucent.com> wrote:

> Hello Andreas,
>
> Thanks for the prompt response and also all the explanation. This really
> helps.
> Since we will never know exactly which type of RDNs are used by the
> SEGW in its certificate, I think we will have to use rightid=%any.
> I will give it a try with this.
>
> Best regards,
> Lakshmi
>
> -----Original Message-----
> From: Andreas Steffen [mailto:andreas.steffen at strongswan.org]
> Sent: Saturday, January 14, 2012 12:11 AM
> To: Umarale, Lakshmi S (Lakshmi)
> Cc: users at lists.strongswan.org
> Subject: Re: [strongSwan] rightid (Ipsec with Certificates)
>
> 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]==
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20120127/f3b4e3f7/attachment.html>