Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
Extracted elements (21)
BTNS PAD entries must logically follow all non-BTNS PAD entries to preserve standard IPsec access control semantics. This is implemented by searching the PAD twice: first with the peer-asserted ID, and if that fails, again with the peer's public key as a PUBLICKEY ID. A single-pass implementation that preserves these semantics is also allowed.
Leap-of-faith (LoF) for BTNS mirrors the SSH model: on first contact, the peer's public key is accepted and recorded; subsequent communications verify against that stored key. This provides continuity-based trust without a PKI, but was still being designed at time of publication.
No new on-the-wire protocol elements are added to IKEv2 for BTNS. The unauthenticated mode is achieved entirely through PAD and SPD extensions to the RFC 4301 processing model, making BTNS a policy-layer change rather than a protocol-layer change.
The non-overlap requirement for the wildcard BTNS PAD entry is enforced by searching the PAD a second time when BTNS peers negotiate child SAs, ensuring BTNS peers cannot assert traffic selectors that conflict with non-BTNS PAD entries and thereby impersonate authenticated peers.
At the time of writing, only bare RSA public key CERT payloads are defined for BTNS, meaning BTNS operates only with RSA public keys. Suitable IKEv2 AUTH methods are RSA Digital Signature (method #1) and DSS Digital Signature (method #3).
BTNS is described in terms of IKEv2 and RFC 4301 concepts. IKEv1 (RFC 2408, RFC 2409) can in principle use the same methods, but those specifications do not include PAD concepts, making BTNS implementation on RFC 2401-compliant systems potentially infeasible.
At most one wildcard BTNS PAD entry may appear in the PAD, and if present it MUST be the last entry in the PAD (logically).
BTNS PAD entries MUST logically follow all non-BTNS PAD entries in the PAD. This ensures that a peer with a known identity is always matched against non-BTNS entries first before falling back to BTNS matching.
If no matching non-BTNS PAD entries are found for a peer, the peer's ID MUST be coerced to type 'PUBLICKEY' with the peer's public key as its value, and the PAD is then searched again for matching BTNS PAD entries.
Nodes MAY include any number of certificates that bind the same public key; these certificates do not need to be pre-shared with peers (e.g., they may be ephemeral or self-signed).
Nodes MUST reject IKE_SA proposals from peers that match non-BTNS PAD entries but fail to authenticate properly, preserving standard IPsec access control semantics.
Nodes wishing to be treated as BTNS nodes by their peers MUST include bare public key CERT payloads. Currently only bare RSA public key CERT payloads are defined.
The wildcard BTNS PAD entry MUST have ID constraints that do not logically overlap those of other PAD entries, preventing BTNS peers from impersonating non-BTNS peers via child SA traffic selector assertions.
A new ID type 'PUBLICKEY' is introduced, whose values are public keys. This type is used internally in PAD processing and is not transmitted on the wire.
A new SPD flag 'BTNS_OK' is defined. Traffic to/from peers matching a BTNS PAD entry will only match SPD entries with the BTNS_OK flag set, allowing fine-grained control over which traffic flows accept unauthenticated peers.
BTNS PAD entries are PAD entries that match on PUBLICKEY IDs. A wildcard BTNS PAD entry matches all peer public keys and must be the last entry in the PAD. All other PAD entries are non-BTNS PAD entries.
A rogue BTNS node can successfully establish an SA by asserting a BTNS peer's address (e.g., node C's address in Example #1) unless additional binding of the specific BTNS ID (public key) to traffic flows is performed via connection latching, channel binding, or leap-of-faith mechanisms.
Connection latching binds discrete packet flows to sequences of similar SAs, mitigating MITM attacks subsequent to initial communications. It requires native IPsec implementations and cooperation between upper layer protocols and IPsec.
MITMs can be detected by using application-layer authentication frameworks such as the GSS-API with channel binding (RFC 5056). IPsec 'channels' in this context are latched connections that upper-layer protocols can bind authentication to.
The BTNS PAD entry must be last and its child SA ID constraints must be non-overlapping with any other PAD entry. This ensures that no BTNS peer can impersonate another IPsec non-BTNS peer by asserting that peer's addresses as traffic selectors.
Unauthenticated SA negotiation is subject to man-in-the-middle (MITM) attacks. BTNS should be used with care; in environments lacking security infrastructure it may be better than transmitting in the clear, but MITM protection is not inherent.