IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
updates
Extracted elements (25)
Deriving the shared secret key in the IPsec layer (rather than exposing it to the O/TWAMP client) is recommended so that IPsec keying material is not exposed; however, the host-internal interaction between layers is implementation-specific and outside the scope of this document.
Protecting O/TWAMP traffic using O/TWAMP security (with IKEv2-derived PSK) while bypassing the IPsec tunnel allows partial authentication of packets — the sequence number can be encrypted and authenticated before the timestamp is fetched, potentially improving latency measurement accuracy.
Setting IKEv2Derived mode in the Server Greeting poses no backwards-compatibility problems: legacy Control-Client implementations simply disregard the new Modes bit, while a client implementing this method can detect that the contacted server does not support IKEv2 key derivation and fall back to RFC 4656/5357 modes.
The motivation for IKEv2-derived keys is to eliminate the operational burden of provisioning and managing pre-shared keys at scale, especially in deployments such as 3GPP LTE where network elements already support certificate-based IKEv2.
The shared secret key is derived from the IKEv2 SA rather than the child SA because it is possible that an IKEv2 SA is created without generating any child SA (RFC 6023), making the IKEv2 SA a more universally available derivation source.
A Control-Client implementing this method that decides not to employ IKEv2 derivation can behave as a client purely compatible with RFC 4656 and RFC 5357; similarly, if no IKEv2 SA exists, the client may proceed with modes defined in RFC 4656, RFC 5357, and RFC 5618 after logging an error.
An O/TWAMP Server implementation MUST obtain SPIi and SPIr from the first 16 octets of the KeyID field and ignore the remaining octets.
If rekeying or deletion of the IKEv2 SA occurs, the corresponding shared secret key generated from the SA MUST continue to be used until the O/TWAMP session terminates.
If the O/TWAMP Server cannot find the IKEv2 SA corresponding to the SPIi and SPIr received, it MUST log the event for operational management purposes.
IKEv2-derived keys SHOULD be used instead of shared secrets when O/TWAMP is employed in a deployment using IKEv2.
In authenticated, encrypted, and mixed modes, the shared secret key MUST be derived from the IKEv2 SA using the formula: Shared secret key = prf(SK_d, "IPPM"), where "IPPM" is ASCII-encoded and prf is a pseudorandom function.
O/TWAMP packets between two IKEv2 systems SHOULD be configured to use the corresponding IPsec tunnel running over an external network even when using O/TWAMP unauthenticated mode, to ensure authenticity and security.
SK_d must be generated first and computed as per RFC 7296 when deriving the shared secret key from the IKEv2 SA.
SPIi and SPIr MUST be included in the KeyID field of the Set-Up-Response message to indicate the IKEv2 SA from which the O/TWAMP shared secret key was derived; the first 8 octets MUST carry SPIi and the second 8 octets MUST carry SPIr, with remaining bits set to zero.
The TWAMP-Modes registry MUST be updated only by "IETF Review" as specified in RFC 5226; IANA SHOULD allocate monotonically increasing bit positions when requested.
When an O/TWAMP Control-Client implementing this method receives a Server Greeting indicating support for Mode IKEv2Derived, it SHOULD reply with a Set-Up-Response that indicates so.
When the O/TWAMP Server cannot find the corresponding IKEv2 SA, it SHOULD set the Accept field of the Server-Start message to value 6 to indicate it is not willing to conduct further transactions in the O/TWAMP-Control session.
The IKEv2Derived mode capability is signaled by setting bit position 7 in the 32-bit Modes field of the TWAMP Server Greeting and Set-Up-Response messages, indicating support for deriving the O/TWAMP shared secret key from an IKEv2 SA.
The O/TWAMP-Control protocol uses AES-CBC for confidentiality and HMAC-SHA1 truncated to 128 bits for message authentication, supporting unauthenticated, authenticated, encrypted, and (for TWAMP) mixed modes.
The O/TWAMP-Test AES Session-key and HMAC Session-key are derived from O/TWAMP-Control keys using the 16-octet SID as input to the KDF, tying test session security to the corresponding control session.
The TWAMP-Modes registry is reformatted as a single-bit-position flags field (32 bits). Bit 7 (IKEv2Derived Mode Capability) is newly added by this document; bits 0-6 are pre-existing entries from RFC 4656, RFC 5618, RFC 5938, and RFC 6038.
The strength of the derived shared secret key is bounded by the IKEv2 SA key derivation algorithm as per RFC 7296, and depends on the inherent strength of the Diffie-Hellman group, exponent size, and random number generator entropy. DoS vulnerabilities are also as defined in RFC 7296.
In the Set-Up-Response message, the KeyID field (80 octets total) carries SPIi in the first 8 octets and SPIr in the second 8 octets when IKEv2 key derivation is used; the remaining 64 octets MUST be set to zero.
The Server Greeting message contains Modes (4 octets), Challenge (16 octets), Salt (16 octets), Count (4 octets), and MBZ (12 octets) fields, preceded by 12 unused octets.
The Set-Up-Response message contains Mode (4 octets), KeyID (80 octets), Token (16 octets), and Client-IV (12 octets) fields.