MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)
updates
- rfc-3830 — MIKEY: Multimedia Internet KEYing
Extracted elements (28)
In unicast RSA-R mode, both the Initiator (via RAND in I_MESSAGE) and the Responder (via TGK) contribute entropy to TEK generation, which is slightly better than RSA mode where only the Initiator contributes. For group mode, the Responder alone chooses the TGK and RAND since the TEK protects data sent by the Responder.
MIKEY-RSA-R was designed for scenarios where the Initiator does not know the Responder's public key or even the Responder's ID in advance (e.g., call forwarding). Existing RSA, PSK, and DH modes are insufficient when the Initiator cannot obtain the Responder's certificate before the exchange.
The RSA-R mode enables member-initiated group key download, where group members (as MIKEY Initiators) request keying material from a group key server (the Responder). This contrasts with the group manager pushing keys to members and aligns with the MSEC group key management architecture (RFC 4046).
Error no. 13 ('Unsupported message type') is not defined in RFC 3830. RFC 3830-compliant implementations receiving an unparseable MIKEY RSA-R message MAY return 'an unspecified error occurred' (Error no. 12) as a fallback.
RSA-R mode may not easily support 3-way calling when the Initiator lacks certificates for both other parties. If the bridge entity knows neither party's certificate, an extra message exchange beyond what RSA mode requires may be needed. Bridged 3-way calling avoids this issue.
For certificate handling in RSA-R mode, the X.509v3 URL Cert type MUST be implemented as the default. The HTTP URL for fetching a certificate per RFC 2585 MUST be supported; FTP URL support is not required.
If the Initiator's policy does not allow acceptance of an R_MESSAGE from any entity other than one that can assert a specific identity, the Initiator MUST include that specific identity in an IDr payload in the I_MESSAGE.
In group RSA-R mode, Initiators MUST NOT send the SP payload. The Responder sends the SP payload in the R_MESSAGE to convey the session policy for all group members.
Initiators of MIKEY messages that do not originate RTP streams MUST specify '0' as the number of CSs supported. This typically applies to group communication and listen-only entities.
The CSB_ID in the R_MESSAGE HDR MUST be the same as the one in the I_MESSAGE HDR. For group communication, the Responder MUST include a General Extension Payload containing a new CSB_ID, and both parties MUST use that value for key material computation.
The I_MESSAGE MUST be signed by the Initiator using the procedure specified in RFC 3830, providing integrity and replay protection via the SIGNi payload. If CERTi is included, it MUST correspond to the private key used to sign the I_MESSAGE.
The I_MESSAGE MUST contain the MIKEY HDR and timestamp payload for replay protection. The V bit in the HDR MUST be set to '1' (though the Responder ignores it) because a response is mandatory in RSA-R mode.
The Initiator MUST silently discard an R_MESSAGE that contains a RAND payload if the I_MESSAGE contained a RAND payload. Similarly, if I_MESSAGE did not contain RAND, an R_MESSAGE without RAND MUST be silently discarded.
The RAND payload in I_MESSAGE and R_MESSAGE are mutually exclusive: if I_MESSAGE did not include RAND, it MUST be present in R_MESSAGE; if I_MESSAGE included RAND, it MUST NOT be present in R_MESSAGE. In group communication, the Responder always sends the RAND payload.
The RECOMMENDED method for certificate validation is OCSP (RFC 2560). When OCSP is used and nextUpdate is present in the response, it defines the certificate cache validity period. If OCSP is unsupported or nextUpdate is absent, the cache timeout is a matter of local policy.
Upon receiving a valid I_MESSAGE, the Responder MUST send an R_MESSAGE if SIGNi can be correctly verified and the timestamp is current. If an SP payload is present, the Responder MUST return one of the proposed security policies matching its local policy.
MIKEY-RSA-R group mode exchange: I_MESSAGE = HDR, T, [RAND], [IDi|CERTi], [IDr], SIGNi (no SP payload). R_MESSAGE = HDR, GenExt(CSB_ID), T, RAND, [IDr|CERTr], SP, KEMAC, PKE, SIGNr. In group mode, CSB_ID, RAND, and SP in R_MESSAGE are mandatory.
MIKEY-RSA-R unicast mode requires one full roundtrip. I_MESSAGE = HDR, T, [RAND], [IDi|CERTi], [IDr], {SP}, SIGNi. R_MESSAGE = HDR, [GenExt(CSB_ID)], T, [RAND], [IDr|CERTr], [SP], KEMAC, PKE, SIGNr.
The KEMAC payload in R_MESSAGE carries the encrypted TGK and MAC: KEMAC = E(encr_key, IDr || {TGK}) || MAC. The encr_key and auth_key are derived from the envelope key (env_key) per RFC 3830 Section 4.1.4. The first sub-payload is the Responder's identity (IDr), followed by one or more TGK payloads chosen by the Responder.
The PKE payload in R_MESSAGE carries the envelope key encrypted with the Initiator's public key: PKE = E(PKi, env_key). The envelope key MAY be cached and reused as a PSK for re-keying, as suggested in RFC 3830.
To compute the SIGNr signature, the Responder MUST sign: R_MESSAGE (excluding SIGNr itself) || IDi || IDr || T. The added identities and timestamp are identical to those in the ID and T payloads.
New entry added to 'General Extensions payload name spaces' (Table 6.15 of RFC 3830): CSB_ID = 4, carrying the Responder's modified CSB_ID for group mode key distribution.
New error code added to 'Error payload name spaces' (Table 6.12 of RFC 3830): Error no. 13 = 'Unsupported message type' (unparseable MIKEY message). RFC 3830-compliant implementations that do not support this error code MAY return Error no. 12 (unspecified error).
Two new MIKEY message type values added to 'Common Header payload name spaces' (Table 6.1a of RFC 3830): RSA-R I_MSG = 9 (Initiator's RSA-R public-key message) and RSA-R R_MSG = 10 (Responder's RSA-R public-key message).
MIKEY requires clock synchronization for timestamp-based replay protection. A secure network clock synchronization protocol SHOULD be used, such as ISO/IEC 18014 or secure NTP.
The I_MESSAGE in RSA-R offers DoS protection equivalent to the DH method, not the RSA method, because there are no payloads encrypted by the Responder's public key in the I_MESSAGE. If IDr is not included, the Responder will create state for any signed I_MESSAGE, including malicious ones. Caching recently verified requests can mitigate this.
When both unicast and multicast streams need to be negotiated, it is RECOMMENDED to use multiple instances of MIKEY-RSA-R rather than a single instance in group mode, to avoid potential key reuse with counter mode.
When RSA-R mode is used, the Responder may be a different party than the intended recipient (e.g., due to call forwarding). The Initiator is responsible for verifying that the Responder's identity is acceptable per local policy; blacklists, whitelists, or strong authentication may be appropriate.