[Swan] authenticated Opportunistic Encryption !

Thu Dec 7 05:26:35 UTC 2017

Thanks Paul for the response .

Able to establish "authenticated OE" between peers using libreswan 3.20 . 
Looks like , flag "p"  for certificates created the mess. There were two flags "p" & "P" where former is to Prohibit ( explicitly distrust ) and later to Trust the peer. 
With the "P" for Certificates ., authenticated OE worked fine. 

1] I was going through other thread about libreswan 3.22 & the check for subjectAltName in certificates. Is there any way (either through configuration/tweak) available to disable this check !?   

2] As 3.20 worked for authenticated OE, do you still suggest >=3.22 to look for ? Would request to please point me to bug list (fixed) / enhancements added (in the context of OE) for 3.22 over 3.20 !?

3] Considering the FIPS mode - any inputs !?

-Regards,
Kesav.

-----Original Message-----
From: Paul Wouters [mailto:paul at nohats.ca] 
Sent: Monday, December 04, 2017 9:34 PM
To: Kesava Vunnava (kesriniv) <kesriniv at cisco.com>
Cc: swan at lists.libreswan.org
Subject: RE: [Swan] authenticated Opportunistic Encryption !

On Mon, 4 Dec 2017, Kesava Vunnava (kesriniv) wrote:

> Subject: RE: [Swan] authenticated Opportunistic Encryption !

> Got rid of error mentioned in below mail. A new error popped up . Though peer's certificate (public key) was there in nss DB , log was saying "no RSA public key known for 10.77.123.171".
> PFA "oe-certificate.conf" file for both hosts (CENTOS-171, CENTOS-172) .  Included the same configuration file in /etc/ipsec.conf.
>
> Dec  4 00:38:10: "private-or-clear#10.77.123.0/24"[1] ...10.77.123.171 
> #1: private-or-clear#10.77.123.0/24 ESP/AH proposals for initiator: 
> 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;ESN=DISABLED 
> 2:ESP:ENCR=AES_GCM_C_128;INTEG=NONE;ESN=DISABLED 
> 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=D
> ISABLED 
> 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256,HMAC_SHA2_256_128;ESN=D
> ISABLED 5:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED 
> (default) Dec  4 00:38:10: "private-or-clear#10.77.123.0/24"[1] 
> ...10.77.123.171 #3: EXPECTATION FAILED: r != NULL (in 
> ikev2_decode_peer_id_and_certs at ikev2.c:1390)

This expectation shows that you are not running 3.22. Can you use 3.22 ?

> Dec  4 00:38:10: "private-or-clear#10.77.123.0/24"[1] ...10.77.123.171 #3: no RSA public key known for '10.77.123.171'

If that is the remote IP then it seems you might be missing rightrsasigkey=%fromcert or the remote is not sending a CERT payload? (maybe try leftsendcert=always on the remote?)

If you are using intermediate certs, perhaps you need sendca=all to send the intermediate CA's over IKE as well.

> O/P of "certutil -L -d sql:/etc/ipsec.d/" - This command was executed on "CENTOS-172" .  Can see that Certificate for "CENTOS-171" was lying in nss DB.
> ##############################################
> Certificate Nickname                                      Trust Attributes
> 	                                                             
> SSL,S/MIME,JAR/XPI
>
> CENTOS-CA 	                                	            CTu,u,u
> CENTOS-172       	                                            pu,pu,pu
> CENTOS-171                       	                            p,p,p

I've never seen the p flag set/used ?

> Also, can you please confirm me the tested/stable build for "authenticated opportunistic encryption" !? Reason: The same certs/keys were working fine for host-host tunnel . It's unable to find the RSA public key after loading  configuration for "private-or-clear" .

That's odd. We recommend using 3.22 or 3.23rc1.

> Also, from below O/P it looks for 171->172 an unique SPI identifier got generated but from 172->171 the same was NOT happening. It was 0X0 .
>
> [root at CENTOS-171 ipsec.d]# ip xfrm state src 10.77.123.171 dst 
> 10.77.123.172
>        proto esp spi 0x66e5c871 reqid 16397 mode tunnel
>        replay-window 0
>        sel src 10.77.123.171/32 dst 10.77.123.172/32 src 10.77.123.172 
> dst 10.77.123.171
>        proto esp spi 0x00000000 reqid 0 mode transport
>        replay-window 0
>        sel src 10.77.123.172/32 dst 10.77.123.171/32 proto udp sport 
> 7946 dport 7946 dev ens32

That should never happen. Can you run with plutodebug=all and see what's going on?

Paul