Last Modified: May 29, 2024
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 14.1.4.4, 14.1.4.5, 14.1.4.6, 14.1.5, 14.1.5.1, 14.1.5.2, 14.1.5.3, 14.1.5.4, 14.1.5.6
Fixed In:
15.1.0
Opened: Apr 17, 2018 Severity: 3-Major
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.
Very difficult to use asn1dn as the ID of a peer, impeding inter-operation with other vendors.
-- Using certificate based authentication in IPsec IKEv2. -- Configuring an ike-peer with peers-id-type as asn1dn.
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.
The BIG-IP now understands three different ways to express asn1dn inside the peers-id-value string: hexadecimal, distinguished name (DN), and (as a fallback default only) the literal content of the peers-id-value string unchanged. This last is not recommended since it will not be valid asn1dn. Parsing rules are the following: * A string containing equal sign ('=') is assumed a DN. * Otherwise a string is hexadecimal, if it contains only hex digits as well as any number of optional spaces and octothorpes ('#'). Spaces and '#' bytes are ignored, so only hex digits get converted to binary. * Any string parsed as neither DN nor hex is kept as is. Note: An example DN (distinguished name) from rfc1779 is "CN=Steve Kille, O=ISODE Consortium, C=GB". This is the sort of input converted to asn1dn when the value contains at least one equal sign.