MIKEY: Multimedia Internet KEYing
updated by
Extracted elements (30)
MIKEY uses timestamps rather than challenge-response for replay protection to minimize the number of round trips. This requires loosely synchronized clocks and a per-Responder replay cache; the allowable clock skew is a direct trade-off with replay cache size.
MIKEY was designed for peer-to-peer, simple one-to-many, and small interactive group scenarios (e.g., SIP calls, multicast presentations). Key design goals are end-to-end security, low bandwidth consumption, minimal round trips, small code size, and the ability to tunnel within session establishment protocols such as SDP and RTSP.
The DH method cannot create group keys because each pair of parties derives a unique TGK from g^(xi*xr); different group members would end up with different TGKs. DH is therefore limited to peer-to-peer use within MIKEY.
Three key transport methods are provided: pre-shared key (symmetric-only, most efficient, limited scalability), public-key encryption (scalable via PKI, envelope key may be cached as a pre-shared key for subsequent sessions), and Diffie-Hellman (perfect forward secrecy, highest resource cost). Only PSK and PK methods are mandatory to implement; DH is optional.
MIKEY is designed to be tunneled within SDP, SIP, and RTSP session establishment. MIKEY itself does not carry destination network addresses or ports; implementations SHOULD support Data SA lookup using destination address and port (obtained from SIP or RTSP) together with SSRC.
A cryptographically secure random or pseudo-random number generator MUST be used for keying material and nonces. The PRF of Section 4.1 is MANDATORY to implement; additional PRFs MAY be added via standards-track RFCs.
AES counter mode with a 128-bit key (AES-CM-128) is the mandatory key data transport encryption. NULL encryption MUST NOT be used unless underlying protocols guarantee security; its only sanctioned use is specific SIP scenarios where SDP is protected end-to-end.
HMAC-SHA-1 producing a 160-bit authentication tag is the mandatory MAC algorithm. The authentication key SHOULD be 160 bits (equal to the hash output size). NULL MAC MUST NOT be used unless underlying protocols guarantee security.
In the DH method, both the Initiator's secret xi and the Responder's secret xr MUST be randomly/pseudo-randomly and secretly chosen.
In the public-key method, an encrypted copy of the Initiator's identity (IDi) is placed inside the KEMAC payload as a man-in-the-middle countermeasure. The encrypted IDi MUST always be verified to equal the expected IDi.
New MIKEY transforms and parameters SHALL be added by IANA registration per RFC 2434. All initiator messages MUST use a unique timestamp. CSB update messages MUST use the same CSB ID as the initial exchange, MUST use a new timestamp, and MUST NOT include a new RAND.
RSA PKCS#1 v1.5 is MANDATORY to support for both envelope key encryption and digital signatures. RSA-OAEP (for encryption) and RSA-PSS (for signatures) are RECOMMENDED.
SHA-1 is MANDATORY to implement as the default hash function in MIKEY.
The Common Header Payload (HDR) MUST always be the first payload in every MIKEY message. The CSB ID MUST be unique per Initiator-Responder pair (not globally), and the Initiator MUST check for collisions when choosing it.
The pre-shared key method and the public-key encryption method are MANDATORY to implement. The Diffie-Hellman key exchange method is OPTIONAL to implement.
Timestamps use the NTP 64-bit format (seconds since 0h, 1 January 1900). Implementations MUST be aware of and account for the ~136-year counter overflow. UTC is RECOMMENDED.
When DH is supported, OAKLEY group 5 (1536-bit) is MANDATORY to implement. OAKLEY groups 1 (768-bit) and 2 (1024-bit) are OPTIONAL. New DH groups MUST be specified in a companion standards-track RFC before IANA assignment.
For PSK and PK methods, encryption and authentication keys for MIKEY messages are derived from the envelope/pre-shared key using PRF(inkey, constant || 0xFF || csb_id || RAND). Constants: encryption key=0x150533E1, authentication key=0x2D22AC75, salt key=0x29B88916.
Keys are derived from a TGK using PRF(TGK, constant || cs_id || csb_id || RAND). The 32-bit constants are taken from consecutive decimal digits of e: TEK=0x2AD01C64, authentication key=0x1B5C7973, encryption key=0x15798CEF, salting key=0x39A2C14B.
MIKEY's default PRF is HMAC-SHA-1 based. The input key is split into 256-bit blocks; each block feeds an iterative HMAC chain (P-function) over a label, and the per-block outputs are XOR-combined to produce an output key of the desired length.
RFC 3830 creates IANA registries for MIKEY data type values, next payload type values, PRF function identifiers, CS ID map type values, encryption algorithm values (KEMAC Encr alg), MAC algorithm values, DH group identifiers, and signature type values. New entries are added via IANA registration per RFC 2434.
Replay protection uses a cache of hashes of successfully authenticated messages. Messages outside the allowable clock skew or found in the cache are silently discarded. Under DoS, MIKEY MAY dynamically reduce the allowed clock skew to keep the replay cache manageable; such attacks are limited to authenticated peers and are therefore traceable.
The primary DoS threat against MIKEY is CPU exhaustion: an attacker sends many messages forcing MAC/signature verification before the replay cache is consulted. Signed error messages in response to authentication failures SHOULD NOT be sent, as they can enable DoS against the Responder; unauthenticated error messages should be treated only as advisory.
The Common Header Payload (HDR) encodes: version (8 bits, 0x01), data type (8 bits: PSK=0, PSK-ver=1, PK=2, PK-ver=3, DH-init=4, DH-resp=5, Error=6), next payload (8 bits), V flag (1 bit, response expected), PRF func (7 bits, MIKEY-1=0), CSB ID (32 bits), #CS (8 bits), CS ID map type (8 bits), CS ID map info (variable).
The DH Data Payload (DH) encodes: Next payload (8 bits), DH-Group (8 bits: OAKLEY 5=0/1536-bit, OAKLEY 1=1/768-bit, OAKLEY 2=2/1024-bit), DH-value (variable, implicit length from group), KV (4 bits, key validity type), optional KV data.
The Envelope Data Payload (PKE) encodes: Next payload (8 bits), C cache indicator (2 bits: No cache=0, Cache=1, Cache for CSB=2), Data len (14 bits), Data (variable, RSA-encrypted envelope key). The C field controls whether the Responder caches the envelope key for reuse as a pre-shared key.
The Key Data Transport Payload (KEMAC) encodes: Next payload (8 bits), Encr alg (8 bits: NULL=0, AES-CM-128=1, AES-KW-128=2), Encr data len (16 bits), Encr data (variable, encrypted Key data sub-payloads), MAC alg (8 bits: NULL=0, HMAC-SHA-1-160=1), MAC (variable, 160 bits for HMAC-SHA-1-160). In PSK mode the MAC covers the entire message; in PK mode the MAC covers only the KEMAC payload.
The Signature Payload (SIGN) encodes: S type (4 bits: RSA/PKCS#1/1.5=0, RSA/PSS=1), Signature len (12 bits), Signature (variable). This payload is always the last payload in PK transport and DH exchange messages; it covers the entire MIKEY message.
The SRTP-ID map info (CS ID map type 0) encodes per-CS: Policy_no_i (8 bits), SSRC_i (32 bits, zero if not yet chosen by Initiator), ROC_i (32 bits rollover counter, 0 if session not started). The Crypto Session ID equals the CS sequence number, not the SSRC value.
The Timestamp Payload (T) encodes: Next payload (8 bits), TS type (8 bits), TS value (variable). The default and mandatory timestamp type is 64-bit NTP format (seconds since 0h 1 January 1900).