X.509 pem ipsec ikev2 error

[somme8023]

Use openssl to generate a certificate，when ikev1 is used, it can be used normally. When using ikev2, there is a problem that can not be used normally.

pluto[12107]: packet from 172.16.5.245:500: ikev2 cert encoding of IKEv2 Certificate Request Payload has an unknown value: 12
pluto[12107]: packet from 172.16.5.245:500: malformed payload in packet
pluto[12107]: packet from 172.16.5.245:500: no-state: INVALID_EXCHANGE_TYPE
pluto[12107]: packet from 172.16.5.245:500: ignored received packet with unknown cookies
pluto[12107]: packet from 172.16.5.245:500: ignored received packet with unknown cookies
pluto[12107]: packet from 172.16.5.245:500: ignored received packet with unknown cookies

cisco routers and openswan are configured as follows

cisco routers config:

cisco7200#show run
cisco7200#show running-config 
Building configuration...

Current configuration : 5913 bytes
!
! Last configuration change at 02:40:29 CN Tue Apr 25 2017
!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname cisco7200
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
clock timezone CN 8 0
no ip icmp rate-limit unreachable
ip cef
!
!
!
!         
!         
!         
no ip domain lookup
ip domain name robustel.cisco.com
no ipv6 cef
!         
!         
multilink bundle-name authenticated
!         
crypto pki trustpoint CA
 enrollment terminal
 subject-name cn=robustel.cisco.com,c=CN,l=GuangZhou,ou=Robustel
 revocation-check none
 rsakeypair cisco7200-key
!         
!         
crypto pki certificate chain CA
 certificate 00F927E468449534B7
  3082030E 308201F6 A0030201 02020900 F927E468 449534B7 300D0609 2A864886 
  F70D0101 05050030 57310B30 09060355 04061302 434E3112 30100603 5504080C 
  09477561 6E67446F 6E673111 300F0603 55040A0C 08526F62 75737465 6C310B30 
  09060355 040B0C02 52543114 30120603 5504030C 0B495053 65632D54 532D4341 
  301E170D 31373034 32343036 31393435 5A170D31 38303432 34303631 3934355A 
  303D310B 30090603 55040613 02434E31 11300F06 0355040B 1308526F 62757374 
  656C311B 30190603 55040313 12726F62 75737465 6C2E6369 73636F2E 636F6D30 
  819F300D 06092A86 4886F70D 01010105 0003818D 00308189 02818100 D3A0713A 
  7A7B2868 AAA9250E 5F74C6E2 C8DA441F D7AE1E09 9963A3E6 AB744F95 F4D7C8F0 
  36296C56 CC601EA4 3316A716 2A9C538E 9BFBD6CC BF4583D8 84D2E5D2 CDF9FC65 
  311E9281 0CA7D5AF 59CB3271 1E1945AF 29326A6F 00CB2F8C 1FFD5B6F EB811428 
  BDD71309 18F47B9E 37C25C5D D791C852 1143B945 6E726998 FCA41325 02030100 
  01A37B30 79300906 03551D13 04023000 302C0609 60864801 86F84201 0D041F16 
  1D4F7065 6E53534C 2047656E 65726174 65642043 65727469 66696361 7465301D 
  0603551D 0E041604 149505E4 FAA6920F 49C337BC 8CAF8021 F1755C0C 20301F06 
  03551D23 04183016 8014F5ED 7FD8AAB7 923D2B7A 71492472 7939B69A AC07300D 
  06092A86 4886F70D 01010505 00038201 01005A9A F5B56F35 936C7694 22D7B494 
  20AB497A DCEBF427 3CA36073 ED28E7C6 291D4B23 1BB3E9BC F8D69A4C E0167772 
  6F2996AC 891007CF BAD820B2 9B76A08A A56EC126 6A13DE8C CFDA4C1E 2119E154 
  D27847B9 ADFD391A 7EFC1D69 BF7623EE D5A24AA7 E74BE20D ECC679C9 9B424C28 
  766BB8A9 E211CF3B 5D7F46C0 CA26F8FB A004F876 29EBD189 F16D04BF 61D69FE1 
  7BE2ABF5 2BD08EF9 8AEF69D8 A6FFAB89 6B0E036A 6D4BA390 6F3FBFB8 A68C02A1 
  5524004F B70F0E94 B2478FC7 B4FAD02C 1C7B6834 A8C32594 118F1CF9 2470BAA5 
  E62F4A86 68002857 78E93CC9 A3FE7879 8DC56D3E 57287ABB 34ADA6AA 8B2A38C1 
  44886A42 261917A0 6C57D22C 9DFD5E04 1517
        quit
 certificate ca 00F927E468449534B5
  30820381 30820269 A0030201 02020900 F927E468 449534B5 300D0609 2A864886 
  F70D0101 05050030 57310B30 09060355 04061302 434E3112 30100603 5504080C 
  09477561 6E67446F 6E673111 300F0603 55040A0C 08526F62 75737465 6C310B30 
  09060355 040B0C02 52543114 30120603 5504030C 0B495053 65632D54 532D4341 
  301E170D 31373034 32343036 31303137 5A170D32 30303432 33303631 3031375A 
  3057310B 30090603 55040613 02434E31 12301006 03550408 0C094775 616E6744 
  6F6E6731 11300F06 0355040A 0C08526F 62757374 656C310B 30090603 55040B0C 
  02525431 14301206 03550403 0C0B4950 5365632D 54532D43 41308201 22300D06 
  092A8648 86F70D01 01010500 0382010F 00308201 0A028201 0100CB70 E11DF85F 
  6673BC5E B5766010 12323E5D E9E36BA3 84B46EB4 A774C0F2 2D4B1A90 B66BBD6B 
  DB3EE53B EEB8F4AD FDAFEA22 0EC00C28 34CDB59B 27B56082 0959AEAC AD65C67E 
  0E764D64 E0FF8885 F479B291 982E3184 BE15BACD C37E2A07 B723B17E 2CC50028 
  C4BD2E33 C8BBD162 CEA6F9F0 C5A48A27 28D412AC ABEB788B 94AE9E81 D158C863 
  BC1D03AF D4CB5FF0 CAD71F96 4FC8CA16 33DAF508 92AAD175 92E36460 41F300A2 
  C0E6C3EC EB8F589B C6C2D412 7408EC31 585362E4 3EEC821B 2F0075D2 65148EB5 
  201A768F 4960F2A0 9BCE9B61 3B1B2E0F 4AD64388 F18A84B0 25C1AA79 05229CA1 
  48A37C5C 20F3931C B449BA55 2B206AFF 1C21A158 4EF10CFD 9F4F0203 010001A3 
  50304E30 1D060355 1D0E0416 0414F5ED 7FD8AAB7 923D2B7A 71492472 7939B69A 
  AC07301F 0603551D 23041830 168014F5 ED7FD8AA B7923D2B 7A714924 727939B6 
  9AAC0730 0C060355 1D130405 30030101 FF300D06 092A8648 86F70D01 01050500 
  03820101 007E4DA1 0FC7620E 33DC6648 6908E9EB F6FA34F5 FBBE901D 01A31A51 
  2BFBDECB 51230732 10D7E9A9 3E1C4CF6 980DB79B 166F9F8E 82CEEF6B 51A7FEBD 
  0F998A00 F9D760A3 352FFC95 2FBD9878 3A93D8AE 5A907D43 1A4809AA BA8E05CF 
  778C2A93 71F77782 6941BAC5 7561A7C1 15ACD3A9 B1F98DFA DD94E1CB 2E6D6F50 
  690EB410 C4F4CD69 AB689AD0 A5A909F2 88FC1AA3 533BF831 74A8A71E 53B29BBC 
  37378A75 43781883 EDB8EFE2 D2227956 A3A39E32 BDB8AC9A 3FD77B48 356DF686 
  9B6EBA5A 60D3E226 3CE46443 57F43E27 8CEE216E FF4D98C5 429614DE 395D4808 
  7C9779CF 11BB81B9 74940B18 49BEEB81 0F34E0CD 489F4668 10B34B3A D1D6DEF9 
  E79DC1FD 6F
        quit
!               
ip tcp synwait-time 5
!         
!         
crypto ikev2 proposal policy 
 encryption 3des
 integrity md5
 group 2  
!         
crypto ikev2 policy policy 
 proposal policy
!         
crypto ikev2 keyring key
 peer openswan
  address 172.16.99.120
  pre-shared-key cisco
 !        
!                 
crypto ikev2 profile profile
 match identity remote address 172.16.99.120 255.255.0.0 
 identity local dn 
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint CA sign
 virtual-template 1
!              
crypto ipsec transform-set tran esp-3des esp-md5-hmac 
 mode tunnel
!                
crypto map ikev2map 10 ipsec-isakmp 
 ! Incomplete
 set peer 172.16.99.120
 set transform-set tran 
 set ikev2-profile profile
 match address vpn
!                
interface FastEthernet0/0
 ip address 172.16.5.245 255.255.0.0
 ip nat outside
 speed auto
 duplex auto
 crypto map ikev2map
!         
interface FastEthernet0/1
 ip address 192.168.80.1 255.255.255.0
 ip nat inside
 speed auto
 duplex auto
!         
ip forward-protocol nd
!         
!         
no ip http server
no ip http secure-server
!         
ip access-list extended vpn
!                
control-plane
!         
!         
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 stopbits 1
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 stopbits 1
line vty 0 4
 login    
!         
!         
end      

openswan config: /etc # cat /etc/ipsec.conf

# /etc/ipsec.conf - Openswan IPsec configuration file

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
   dumpdir=/var/run/pluto/
# NAT-TRAVERSAL support, see README.NAT-Traversal
   nat_traversal=yes
   oe=off
   protostack=netkey
   keep_alive=60
   plutodebug=none

conn IPSec_TUN_1
   type=tunnel

   #SA configuration
   pfs=no
   phase2=esp
   phase2alg=3des-md5
   salifetime=28800s
   dpdaction=restart_by_peer
   dpddelay=60
   dpdtimeout=180

   #IKE configuration
   ikev2=insist
   authby=rsasig
   ike=3des-md5;modp1024
   ikelifetime=86400s

   #Left configuration
   left=172.16.99.120
   leftsubnet=192.168.0.0/24
   leftnexthop=172.16.5.1
   leftid=%fromcert
   leftrsasigkey=%none
   leftcert=/tmp/ipsec/Tunnel_1/local.crt
   leftupdown="ipsec_updown 1"

   #Right configuration
   right=172.16.5.245
   rightsubnet=192.168.80.0/24
   rightid=%fromcert
   rightrsasigkey=%none
   rightcert=/tmp/ipsec/Tunnel_1/remote.crt

   auto=start

cat ipsec.secrets : RSA /tmp/ipsec/Tunnel_1/private.key

What is the problem with my configuration?

[letoams]

On Mon, 24 Apr 2017, somme8023 wrote:

Use openssl to generate a certificate，when ikev1 is used, it can be used normally. When using ikev2, there is a problem that can not be used normally.

pluto[12107]: packet from 172.16.5.245:500: ikev2 cert encoding of IKEv2 Certificate Request Payload has an unknown value: 12 pluto[12107]: packet from 172.16.5.245:500: malformed payload in packet pluto[12107]: packet from 172.16.5.245:500: no-state: INVALID_EXCHANGE_TYPE pluto[12107]: packet from 172.16.5.245:500: ignored received packet with unknown cookies pluto[12107]: packet from 172.16.5.245:500: ignored received packet with unknown cookies pluto[12107]: packet from 172.16.5.245:500: ignored received packet with unknown cookies

Hmm, that seems like 4 bugs right there.

CERT handling in IKEv2 Wrong error code INVALID_EXCHANGE_TYPE No retransmit of retransmitted packets wrongly deleted state resulting in unknown cookies

Do you have the same CERT problem with libreswan?

Paul

[mcr]

Versions of Openswan up to and including 2.6.49 do not create/parse IKEv2 certificate requests properly. It was assumed (wrongly) that the structure was identical to IKEv1, which it is not. We already disabled sending a CR in a previous version, but neglected to ignore parsing them. The partial fix in 2.6.50 will be that we just ignore the payload, and 2.6.51 will fix things.

... actually, I miswrote. The structure is just fine. The error we previously observed involved the certificate payloads, during interoperation with strongswan. The problem in this case is that type=12, is not known to openswan, and the definition of the payload said that this was a critical issue. The simple fix for this is rather easy, which is to ignore the unknown types here. https://github.com/xelerance/Openswan/pull/239

[somme8023]

@letoams Thank you. There is no use of Libswan, there is time to try.

[somme8023]

@mcr Thank you.Waiting for repair version.

[shussain]

@somme8023 I will be creating a developer release tag this week. Would that be acceptable for you or would you prefer an actual 2.6.50 release?

[somme8023]

@shussain I can accept it.

[somme8023]

@shussain What bugs will the developer release tag fix?Have ipsec ikev2 with X.509's bug fixes?

[shussain]

@somme8023 The latest developer tag has been released. It contains various bug fixes including a bug fix for IKEv2 with X509. If you want a full list of bug and fixes, I can get that to you later on today (closer to 6pm EDT).

[somme8023]

@shussain I don't need a full list of bug and fixes.I use this latest developer tag to test it.

[somme8023]

@shussain I tested the IKEV1(with x509) and IKEV2(with x509) using Cisco routers and Openswan(developer release tag).

There was a problem when configuring to Ikev1 with x509,from pluto's print information, you can see that the ISAKMP SA is established, but the IPSec SA cannot be established. I used version (2.6.49.1) that is not problematic.

pluto[1579]: "IPSec_TUN_1" #1: I am sending a certificate request
pluto[1579]: "IPSec_TUN_1" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
pluto[1579]: "IPSec_TUN_1" #1: STATE_MAIN_I3: sent MI3, expecting MR3
pluto[1579]: "IPSec_TUN_1" #1: Main mode peer ID is ID_DER_ASN1_DN: 'C=CN, OU=Robustel, CN=robustel.cisco.com'
pluto[1579]: "IPSec_TUN_1" #1: issuer cacert not found
pluto[1579]: "IPSec_TUN_1" #1: X.509 certificate rejected
pluto[1579]: "IPSec_TUN_1" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
pluto[1579]: "IPSec_TUN_1" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG oursig= theirsig=AwEAAbFio cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1024}
pluto[1579]: "IPSec_TUN_1" #1: Dead Peer Detection (RFC 3706): enabled
pluto[1579]: "IPSec_TUN_1" #2: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+UP+IKEv2ALLOW+SAREFTRACK {using isakmp#1 msgid:1e4d70a0 proposal=3DES(3)_192-MD5(1)_128 pfsgroup=no-pfs}
pluto[1579]: "IPSec_TUN_1" #2: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME msgid=1e4d70a0
pluto[1579]: "IPSec_TUN_1" #2: ERROR: netlink response for Add SA esp.78dfc957@172.16.99.120 included errno 17: File exists
pluto[1579]: | setup_half_ipsec_sa() hit fail failed to add sa
pluto[1579]: "IPSec_TUN_1" #2: state #2: failed to setup incoming SA
pluto[1579]: packet from 172.16.5.245:500: phase 1 message is part of an unknown exchange
~ # pluto[1579]: "IPSec_TUN_1" #2: discarding duplicate packet; already STATE_QUICK_I1
pluto[1579]: packet from 172.16.5.245:500: phase 1 message is part of an unknown exchange
pluto[1579]: "IPSec_TUN_1" #2: discarding duplicate packet; already STATE_QUICK_I1
pluto[1579]: packet from 172.16.5.245:500: phase 1 message is part of an unknown exchange

When configured to IKEv2 with x509,from pluto's print information, you can see that there's a problem,the Child SA cannot be established.

pluto[1580]: loading secrets from "/etc/ipsec.secrets"
pluto[1580]:   loaded private key file '/tmp/ipsec/Tunnel_1/private.key' (1679 bytes)
pluto[1580]: loaded private key for keyid: PPK_RSA:AwEAAcxXq/9E77 2AB3 9278 FEC7 F007 1850 91E7 E36B 7421 E7CF
pluto[1580]: | creating SPD to 172.16.99.120->spi=00000104@0.0.0.0 proto=61
pluto[1580]: | creating SPD to 172.16.99.120->spi=00000104@0.0.0.0 proto=61
pluto[1580]: "IPSec_TUN_1" #1: initiating v2 parent SA
pluto[1580]: "IPSec_TUN_1" #1: STATE_PARENT_I1: initiate
pluto[1580]: "IPSec_TUN_1" #1: transition from state STATE_IKEv2_START to state STATE_PARENT_I1
pluto[1580]: "IPSec_TUN_1" #1: STATE_PARENT_I1: sent v2I1, expected v2R1 (msgid: 00000000/00000000)
pluto[1580]: | I am sending my certificate
pluto[1580]: "IPSec_TUN_1" #2: transition from state STATE_PARENT_I1 to state STATE_PARENT_I2
pluto[1580]: "IPSec_TUN_1" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 oursig=AwEAAcxXq theirsig= cipher=oakley_3des_cbc_192 integ=md5_96 prf=oakley_md5 group=modp1024} (msgid: 00000000/00000000)
pluto[1580]: packet from 172.16.5.245:500: missing payloads (within encryption) for v2_state: initiator-auth-process: ISAKMP_NEXT_v2SA+ISAKMP_NEXT_v2IDr+ISAKMP_NEXT_v2AUTH+ISAKMP_NEXT_v2TSi+ISAKMP_NEXT_v2TSr. Message dropped.
pluto[1580]: "IPSec_TUN_1" #2: STATE_CHILD_C0_KEYING: INVALID_EXCHANGE_TYPE
 pluto[1580]: "IPSec_TUN_1" #2: max number of retransmissions (2) reached STATE_CHILD_C0_KEYING
pluto[1580]: "IPSec_TUN_1" #2: starting keying attempt 1 of an unlimited number
pluto[1580]: "IPSec_TUN_1" #2: deleting state #2 (STATE_CHILD_C0_KEYING)
pluto[1580]: pending Quick Mode with 172.16.5.245 "IPSec_TUN_1" took too long -- replacing phase 1

[letoams]

On Tue, 2 May 2017, somme8023 wrote:

pluto[1579]: "IPSec_TUN_1" #1: I am sending a certificate request pluto[1579]: "IPSec_TUN_1" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3 pluto[1579]: "IPSec_TUN_1" #1: STATE_MAIN_I3: sent MI3, expecting MR3 pluto[1579]: "IPSec_TUN_1" #1: Main mode peer ID is ID_DER_ASN1_DN: 'C=CN, OU=Robustel, CN=robustel.cisco.com' pluto[1579]: "IPSec_TUN_1" #1: issuer cacert not found pluto[1579]: "IPSec_TUN_1" #1: X.509 certificate rejected pluto[1579]: "IPSec_TUN_1" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4 pluto[1579]: "IPSec_TUN_1" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG oursig= theirsig=AwEAAbFio cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1024}

I find it dangerously weird that a certificate is rejected, yet Main Mode authentication has succeeded... That looks like a pretty bad security issue.

pluto[1579]: "IPSec_TUN_1" #2: ERROR: netlink response for Add SA esp.78dfc957@172.16.99.120 included errno 17: File exists

That means the exact IPsec SA is already installed in the kernel by another conn.

pluto[1580]: "IPSec_TUN_1" #2: transition from state STATE_PARENT_I1 to state STATE_PARENT_I2 pluto[1580]: "IPSec_TUN_1" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 oursig=AwEAAcxXq theirsig= ciph er=oakley_3des_cbc_192 integ=md5_96 prf=oakley_md5 group=modp1024} (msgid: 00000000/00000000) pluto[1580]: packet from 172.16.5.245:500: missing payloads (within encryption) for v2_state: initiator-auth-process : ISAKMP_NEXT_v2SA+ISAKMP_NEXT_v2IDr+ISAKMP_NEXT_v2AUTH+ISAKMP_NEXT_v2TSi+ISAKMP_NEXT_v2TSr. Message dropped. pluto[1580]: "IPSec_TUN_1" #2: STATE_CHILD_C0_KEYING: INVALID_EXCHANGE_TYPE

openswan does not display the Notify payloads when the state machine finds missing expected payloads. So you can only get to see the real error by enabling debugging and manually checking the notify payload received. (libreswan shows you the notify in those cases)

INVALID_EXCHANGE_TYPE looks like another bug where openswan picks the IKE_AUTH or IKE_INIT exchange for sending errors irrespective of the actual exchange received. Probably incomplete create_child_sa related code.

Paul

[mcr]

Paul Wouters (libreswan) notifications@github.com wrote:

I find it dangerously weird that a certificate is rejected, yet Main Mode authentication has succeeded... That looks like a pretty bad security issue.

Why? I can give you all sorts of certificates inband using IKE, and they should be ignored if they don't validate.

One can then continue on to verify the connection using some other credential.

> openswan does not display the Notify payloads when the state machine
> finds missing expected payloads. So you can only get to see the real
> error by enabling debugging and manually checking the notify payload
> received. (libreswan shows you the notify in those cases)

That's a good idea: glad you did that.

-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

[letoams]

On May 3, 2017, at 17:34, Michael Richardson notifications@github.com wrote:

Paul Wouters (libreswan) notifications@github.com wrote:

I find it dangerously weird that a certificate is rejected, yet Main Mode authentication has succeeded... That looks like a pretty bad security issue.

Why? I can give you all sorts of certificates inband using IKE, and they should be ignored if they don't validate.

Sure, but there is no indication that you went on to a next CERT payload at all since you didn't print a validation success message, so I doubt that's what is happening here.

One can then continue on to verify the connection using some other credential.

Except openswan doesn't support multiple AUTH methods. There are some remnants of code supporting authby="rsasig|secret" but it breaks finding the host connection and I think is only partially supported with whack/libipsecconf by accident.

If certs are used the id->kind is set to cert, so it is very clear when it should even bother to read the CERT payload for validation and when to just ignore any CERT payload.