Request for Comments: 3830 E. Carrara
Category: Standards Track F. Lindholm
M. Naslund
K. Norrman
Ericsson Research
August 2004
MIKEY: Multimedia Internet KEYing
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes a key management scheme that can be used for
real-time applications (both for peer-to-peer communication and group
communication). In particular, its use to support the Secure Real-
time Transport Protocol is described in detail.
Security protocols for real-time multimedia applications have started
to appear. This has brought forward the need for a key management
solution to support these protocols.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Existing Solutions . . . . . . . . . . . . . . . . . . . 4
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.3. Definitions. . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Abbreviations. . . . . . . . . . . . . . . . . . . . . . 6
1.5. Outline. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 8
2.3. System Overview. . . . . . . . . . . . . . . . . . . . . 8
2.4. Relation to GKMARCH. . . . . . . . . . . . . . . . . . . 10
3. Basic Key Transport and Exchange Methods . . . . . . . . . . . 10
3.1. Pre-shared Key . . . . . . . . . . . . . . . . . . . . . 12
3.2. Public-Key Encryption. . . . . . . . . . . . . . . . . . 13
3.3. Diffie-Hellman Key Exchange. . . . . . . . . . . . . . . 14
4. Selected Key Management Functions. . . . . . . . . . . . . . . 15
4.1. Key Calculation. . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Assumptions. . . . . . . . . . . . . . . . . . . 16
4.1.2. Default PRF Description. . . . . . . . . . . . . 17
4.1.3. Generating keys from TGK . . . . . . . . . . . . 18
4.1.4. Generating keys for MIKEY Messages from
an Envelope/Pre-Shared Key . . . . . . . . . . . 19
4.2 Pre-defined Transforms and Timestamp Formats . . . . . . . 19
4.2.1. Hash Functions . . . . . . . . . . . . . . . . . 19
4.2.2. Pseudo-Random Number Generator and PRF . . . . . 20
4.2.3. Key Data Transport Encryption. . . . . . . . . . 20
4.2.4. MAC and Verification Message Function. . . . . . 21
4.2.5. Envelope Key Encryption. . . . . . . . . . . . . 21
4.2.6. Digital Signatures . . . . . . . . . . . . . . . 21
4.2.7. Diffie-Hellman Groups. . . . . . . . . . . . . . 21
4.2.8. Timestamps . . . . . . . . . . . . . . . . . . . 21
4.2.9. Adding New Parameters to MIKEY . . . . . . . . . 22
4.3. Certificates, Policies and Authorization . . . . . . . . 22
4.3.1. Certificate Handling . . . . . . . . . . . . . . 22
4.3.2. Authorization. . . . . . . . . . . . . . . . . . 23
4.3.3. Data Policies. . . . . . . . . . . . . . . . . . 24
4.4. Retrieving the Data SA . . . . . . . . . . . . . . . . . 24
4.5. TGK Re-Keying and CSB Updating . . . . . . . . . . . . . 25
5. Behavior and Message Handling. . . . . . . . . . . . . . . . . 26
5.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.1. Capability Discovery . . . . . . . . . . . . . . 26
5.1.2. Error Handling . . . . . . . . . . . . . . . . . 27
5.2. Creating a Message . . . . . . . . . . . . . . . . . . . 28
5.3. Parsing a Message. . . . . . . . . . . . . . . . . . . . 29
5.4. Replay Handling and Timestamp Usage. . . . . . . . . . . 30
6. Payload Encoding . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Common Header Payload (HDR). . . . . . . . . . . . . . . 32
6.1.1. SRTP ID. . . . . . . . . . . . . . . . . . . . . 35
6.2. Key Data Transport Payload (KEMAC) . . . . . . . . . . . 36
6.3. Envelope Data Payload (PKE). . . . . . . . . . . . . . . 37
6.4. DH Data Payload (DH) . . . . . . . . . . . . . . . . . . 38
6.5. Signature Payload (SIGN) . . . . . . . . . . . . . . . . 39
6.6. Timestamp Payload (T). . . . . . . . . . . . . . . . . . 39
6.7. ID Payload (ID) / Certificate Payload (CERT) . . . . . . 40
6.8. Cert Hash Payload (CHASH). . . . . . . . . . . . . . . . 41
6.9. Ver msg payload (V). . . . . . . . . . . . . . . . . . . 42
6.10. Security Policy Payload (SP) . . . . . . . . . . . . . . 42
6.10.1. SRTP Policy. . . . . . . . . . . . . . . . . . . 44
6.11. RAND Payload (RAND). . . . . . . . . . . . . . . . . . . 45
6.12. Error Payload (ERR). . . . . . . . . . . . . . . . . . . 46
6.13. Key Data Sub-Payload . . . . . . . . . . . . . . . . . . 46
6.14. Key Validity Data. . . . . . . . . . . . . . . . . . . . 48
6.15. General Extension Payload. . . . . . . . . . . . . . . . 50
7. Transport Protocols. . . . . . . . . . . . . . . . . . . . . . 50
8. Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.1. Simple One-to-Many . . . . . . . . . . . . . . . . . . . 51
8.2. Small-Size Interactive Group . . . . . . . . . . . . . . 51
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 52
9.1. General. . . . . . . . . . . . . . . . . . . . . . . . . 52
9.2. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . 54
9.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 55
9.4. Identity Protection. . . . . . . . . . . . . . . . . . . 55
9.5. Denial of Service. . . . . . . . . . . . . . . . . . . . 56
9.6. Session Establishment. . . . . . . . . . . . . . . . . . 56
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 57
10.1. MIME Registration. . . . . . . . . . . . . . . . . . . . 59
11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. - MIKEY - SRTP Relation. . . . . . . . . . . . . . . . 63
Author’s Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction
There has recently been work to define a security protocol for the
protection of real-time applications running over RTP, [SRTP].
However, a security protocol needs a key management solution to
exchange keys and related security parameters. There are some
fundamental properties that such a key management scheme has to
fulfill to serve streaming and real-time applications (such as
unicast and multicast), particularly in heterogeneous (mix of wired
and wireless) networks.
This document describes a key management solution that addresses
multimedia scenarios (e.g., SIP [SIP] calls and RTSP [RTSP]
sessions). The focus is on how to set up key management for secure
multimedia sessions such that requirements in a heterogeneous
environment are fulfilled.
1.1. Existing Solutions
There is work done in the IETF to develop key management schemes.
For example, IKE [IKE] is a widely accepted unicast scheme for IPsec,
and the MSEC WG is developing other schemes to address group
communication [GDOI, GSAKMP]. However, for reasons discussed below,
there is a need for a scheme with lower latency, suitable for
demanding cases such as real-time data over heterogeneous networks
and small interactive groups.
An option in some cases might be to use [SDP], as SDP defines one
field to transport keys, the "k=" field. However, this field cannot
be used for more general key management purposes, as it cannot be
extended from the current definition.
1.2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
1.3. Definitions
(Data) Security Protocol: the security protocol used to protect the
actual data traffic. Examples of security protocols are IPsec and
SRTP.
Data Security Association (Data SA): information for the security
protocol, including a TEK and a set of parameters/policies.
Crypto Session (CS): uni- or bi-directional data stream(s), protected
by a single instance of a security protocol. For example, when SRTP
is used, the Crypto Session will often contain two streams, an RTP
stream and the corresponding RTCP, which are both protected by a
single SRTP Cryptographic Context, i.e., they share key data and the
bulk of security parameters in the SRTP Cryptographic Context
(default behavior in [SRTP]). In the case of IPsec, a Crypto Session
would represent an instantiation of an IPsec SA. A Crypto Session
can be viewed as a Data SA (as defined in [GKMARCH]) and could
therefore be mapped to other security protocols if necessary.
Crypto Session Bundle (CSB): collection of one or more Crypto
Sessions, which can have common TGKs (see below) and security
parameters.
Crypto Session ID: unique identifier for the CS within a CSB.
Crypto Session Bundle ID (CSB ID): unique identifier for the CSB.
TEK Generation Key (TGK): a bit-string agreed upon by two or more
parties, associated with CSB. From the TGK, Traffic-encrypting Keys
can then be generated without needing further communication.
Traffic-Encrypting Key (TEK): the key used by the security protocol
to protect the CS (this key may be used directly by the security
protocol or may be used to derive further keys depending on the
security protocol). The TEKs are derived from the CSB’s TGK.
TGK re-keying: the process of re-negotiating/updating the TGK (and
consequently future TEK(s)).
Initiator: the initiator of the key management protocol, not
necessarily the initiator of the communication.
Responder: the responder in the key management protocol.
Salting key: a random or pseudo-random (see [RAND, HAC]) string used
to protect against some off-line pre-computation attacks on the
underlying security protocol.
PRF(k,x): a keyed pseudo-random function (see [HAC]).
E(k,m): encryption of m with the key k.
PKx: the public key of x
[] an optional piece of information
{} denotes zero or more occurrences
|| concatenation
| OR (selection operator)
^ exponentiation
XOR exclusive or
Bit and byte ordering: throughout the document bits and bytes are
indexed, as usual, from left to right, with the leftmost bits/bytes
being the most significant.
1.4. Abbreviations
AES Advanced Encryption Standard
CM Counter Mode (as defined in [SRTP])
CS Crypto Session
CSB Crypto Session Bundle
DH Diffie-Hellman
DoS Denial of Service
MAC Message Authentication Code
MIKEY Multimedia Internet KEYing
PK Public-Key
PSK Pre-Shared key
RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
SRTP Secure RTP
TEK Traffic-encrypting key
TGK TEK Generation Key
1.5. Outline
Section 2 describes the basic scenarios and the design goals for
which MIKEY is intended. It also gives a brief overview of the
entire solution and its relation to the group key management
architecture [GKMARCH].
The basic key transport/exchange mechanisms are explained in detail
in Section 3. The key derivation, and other general key management
procedures are described in Section 4.
Section 5 describes the expected behavior of the involved parties.
This also includes message creation and parsing.
All definitions of the payloads in MIKEY are described in Section 6.
Section 7 deals with transport considerations, while Section 8
focuses on how MIKEY is used in group scenarios.
The Security Considerations section (Section 9), gives a deeper
explanation of important security related topics.
2. Basic Overview
2.1. Scenarios
MIKEY is mainly intended to be used for peer-to-peer, simple one-to-
many, and small-size (interactive) groups. One of the main
multimedia scenarios considered when designing MIKEY has been the
conversational multimedia scenario, where users may interact and
communicate in real-time. In these scenarios it can be expected that
peers set up multimedia sessions between each other, where a
multimedia session may consist of one or more secured multimedia
streams (e.g., SRTP streams).
peer-to-peer/ many-to-many many-to-many
simple one-to-many (distributed) (centralized)
++++ ++++ ++++ ++++ ++++
|. | |A | |B | |A |---- ----|B |
--| ++++ | |----------| | | | \ / | |
++++ / ++|. | ++++ ++++ ++++ (S) ++++
|A |---------| ++++ \ / |
| | \ ++|B | \ / |
++++ \-----| | \ ++++ / ++++
++++ \|C |/ |C |
| | | |
++++ ++++
Figure 2.1: Examples of the four scenarios: peer-to-peer, simple
one-to-many, many-to-many without a centralized server (also denoted
as small interactive group), and many-to-many with a centralized
server.
We identify in the following some typical scenarios which involve the
multimedia applications we are dealing with (see also Figure 2.1).
a) peer-to-peer (unicast), e.g., a SIP-based [SIP] call between two
parties, where it may be desirable that the security is either set
up by mutual agreement or that each party sets up the security for
its own outgoing streams.
b) simple one-to-many (multicast), e.g., real-time presentations,
where the sender is in charge of setting up the security.
c) many-to-many, without a centralized control unit, e.g., for
small-size interactive groups where each party may set up the
security for its own outgoing media. Two basic models may be used
here. In the first model, the Initiator of the group acts as the
group server (and is the only one authorized to include new
members). In the second model, authorization information to
include new members can be delegated to other participants.
d) many-to-many, with a centralized control unit, e.g., for larger
groups with some kind of Group Controller that sets up the
security.
The key management solutions may be different in the above scenarios.
When designing MIKEY, the main focus has been on case a, b, and c.
For scenario c, only the first model is covered by this document.
2.2. Design Goals
The key management protocol is designed to have the following
characteristics:
* End-to-end security. Only the participants involved in the
communication have access to the generated key(s).
* Simplicity.
* Efficiency. Designed to have:
- low bandwidth consumption,
- low computational workload,
- small code size, and
- minimal number of roundtrips.
* Tunneling. Possibility to "tunnel"/integrate MIKEY in session
establishment protocols (e.g., SDP and RTSP).
* Independence from any specific security functionality of the
underlying transport.
2.3. System Overview
One objective of MIKEY is to produce a Data SA for the security
protocol, including a traffic-encrypting key (TEK), which is derived
from a TEK Generation Key (TGK), and used as input for the security
protocol.
MIKEY supports the possibility of establishing keys and parameters
for more than one security protocol (or for several instances of the
same security protocol) at the same time. The concept of Crypto
Session Bundle (CSB) is used to denote a collection of one or more
Crypto Sessions that can have common TGK and security parameters, but
which obtain distinct TEKs from MIKEY.
The procedure of setting up a CSB and creating a TEK (and Data SA),
is done in accordance with Figure 2.2:
1. A set of security parameters and TGK(s) are agreed upon for the
Crypto Session Bundle (this is done by one of the three
alternative key transport/exchange mechanisms, see Section 3).
2. The TGK(s) is used to derive (in a cryptographically secure way) a
TEK for each Crypto Session.
3. The TEK, together with the security protocol parameters, represent
the Data SA, which is used as the input to the security protocol.
+-----------------+
| CSB |
| Key transport | (see Section 3)
| /exchange |
+-----------------+
| :
| TGK :
v :
+----------+ :
CS ID ->| TEK | : Security protocol (see Section 4)
|derivation| : parameters (policies)
+----------+ :
TEK | :
v v
Data SA
|
v
+-------------------+
| Crypto Session |
|(Security Protocol)|
+-------------------+
Figure 2.2: Overview of MIKEY key management procedure.
The security protocol can then either use the TEK directly, or, if
supported, derive further session keys from the TEK (e.g., see SRTP
[SRTP]). It is however up to the security protocol to define how the
TEK is used.
MIKEY can be used to update TEKs and the Crypto Sessions in a current
Crypto Session Bundle (see Section 4.5). This is done by executing
the transport/exchange phase once again to obtain a new TGK (and
consequently derive new TEKs) or to update some other specific CS
parameters.
2.4. Relation to GKMARCH
The Group key management architecture (GKMARCH) [GKMARCH] describes a
general architecture for group key management protocols. MIKEY is a