Bug ID 715379: IKEv2 accepts asn1dn for peers-id only as file path of certificate file

Last Modified: May 07, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP TMOS(all modules)

Known Affected Versions:
13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.4

Opened: Apr 17, 2018
Severity: 3-Major

Symptoms

IKEv2 only has a very inconvenient way to specify ID for an ike-peer when using peers-id-type asn1dn. The string value of peers-id-value was understood only as a file path, and not as a representation of the asn1dn value itself. The file had to be a certificate, whose subject happened to be the ID of the remote peer as a distinguished name (DN), so this could be extracted as binary DER for asn1dn. This was both awkward and error prone, requiring what amounts to a copy of a peer's certificate before it is sent during negotiation.

Impact

Very difficult to use asn1dn as the ID of a peer, impeding inter-operation with other vendors.

Conditions

-- Using certificate based authentication in IPsec IKEv2. -- Configuring an ike-peer with peers-id-type as asn1dn.

Workaround

If you can install a local copy of the peer's certificate, with an asn1dn value inside matching what that peer will actually send in an IKE_AUTH exchange, IKEv2 can extract the asn1dn provided the value of peers-id-value is an absolute file system path to this local certificate copy.

Fix Information

None

Behavior Change