Internet Engineering Task Force J. Arkko
MSEC Working Group E. Carrara
INTERNET-DRAFT F. Lindholm
Expires: May 2002 M. Naslund
K. Norrman
Ericsson
November, 2001
MIKEY: Multimedia Internet KEYing
<draft-ietf-msec-mikey-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Work for securing real-time applications have started to appear. This
has brought forward the need for a key management solution to support
the security protocol. The key management has to fulfil requirements,
which makes it suitable in the context of conversational multimedia
in a heterogeneous environment.
This document describes a key management scheme that can be used for
real-time applications (both for peer-to-peer communication and group
communication), and shows how it may work together with protocols
such as SIP and RTSP.
Arkko, et al. [Page 1]
INTERNET-DRAFT msec-mikey November 2001
TABLE OF CONTENTS
1. Introduction..............................................3
1.1. Notational Conventions..................................3
1.2. Definitions.............................................3
1.3. Abbreviations...........................................4
1.4. Outline.................................................5
2. Basic Overview............................................5
2.1. Scenarios...............................................5
2.2. Design Goals............................................6
2.3. System Overview.........................................7
2.4. Existing solutions......................................8
3. Basic Key Transport and Exchange Schemes..................8
3.1. Pre-shared key..........................................8
3.2. Public-key encryption...................................9
3.3. Diffie-Hellman key exchange.............................10
4. Key Management............................................11
4.1. TEK and Verification key Calculation....................11
4.1.1. Assumptions...........................................12
4.1.2. Notation..............................................12
4.1.3. Description...........................................12
4.2. Re-keying...............................................13
5. Behavior and message handling.............................14
5.1. General.................................................14
5.1.1. Capability discovery..................................14
5.1.2. Error handling........................................14
5.2. Creating a message......................................14
5.3. Parsing a message.......................................15
5.4. Replay handling.........................................16
5.5. Reliability.............................................17
6. SDP integration...........................................17
7. Key management with SIP...................................18
7.1. Integration.............................................18
7.2. Re-keying...............................................18
8. Key management with RTSP..................................19
8.1. Integration.............................................19
8.2. Re-keying...............................................19
9. Groups....................................................19
10. Security Considerations..................................21
10.1. General................................................21
10.2. Key lifetime...........................................22
10.3. Timestamps.............................................22
10.4. Identity protection....................................23
10.5. Denial of Service......................................23
11. Conclusions..............................................24
12. Acknowledgments..........................................24
13. Author's Addresses.......................................24
14. References...............................................25
Appendix A - Payload Encoding................................27
A.1. Common header payload..................................27
Arkko, et al. [Page 2]
INTERNET-DRAFT msec-mikey November 2001
A.2. PS data payload........................................29
A.3. PK data payload........................................30
A.4. DH data payload........................................30
A.5. Signature payload......................................31
A.6. Timestamp payload......................................31
A.7. ID payload / Certificate payload........................32
A.8. Cert hash payload.......................................33
A.9. Ver msg payload.........................................33
A.10. n_start/n_end/SPI payload..............................34
A.11. SP payload.............................................34
A.12. Error payload..........................................36
Appendix B. - Payload usage summary..........................36
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, security parameters, etc. There are some fundamental
properties that such a key management scheme has to fulfil with
respect to the kind of real-time applications (streaming, unicast,
groups, multicast, etc.) and to the heterogeneous nature of the
scenarios dealt with. [REQS] lists in detail requirements for key
management to work for conversational multimedia in heterogeneous
environments.
Following the requirements derived in [REQS], we discuss here some
scenarios, and propose a key management solution. That is, 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. 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 RFC-2119.
1.2. Definitions
Crypto Session: uni- or bi-directional data stream(s), protected by a
single instance of a security protocol. E.g. when SRTP is used, the
Crypto Session may contain two streams, both the RTP and RTCP as they
are both protected by a single instance of SRTP.
Crypto Session ID: unique identifier for the Crypto Session.
Multimedia Crypto Session (MCS): collection of one or more Crypto
Sessions, which has a common Security Association and Pre-Master Key.
Arkko, et al. [Page 3]
INTERNET-DRAFT msec-mikey November 2001
Multimedia Crypto Session ID: unique identifier for the MCS.
Security Association (SA): collection of information needed to secure
a Multimedia Crypto Session.
Pre-Master Key (PMK): a bit-string agreed upon by two or more
parties, associated with a SA (and consequently MCS). From the pre-
master key, Traffic-encrypting Keys can then be generated without
need of further communication.
Traffic-encrypting Key (TEK): the key used by the security protocol
to protect the crypto session (this key may be used directly by the
security protocol or may be used to derive further keys depending on
security protocol). The TEKs are derived from the MCS's PMK.
PMK re-keying: the process of re-negotiating the PMK (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.
H(x): a cryptographic hash function with argument x
E(k,m): encryption of m with the key k
D(k,m): decryption of m with the key k
Sign(k,m): the signature of message m with key k
PK_x: the public key of x
SK_x: the secret key of x
Cert_x: Certificate of x
k_p: the PMK
[] an optional piece of information
|| concatenation
| logical OR
^ binary exclusive OR
** exponentiation
Bit and byte ordering: throughout the document bits and bytes are as
usual indexed from left to right, with the leftmost bits being the
most significant.
1.3. Abbreviations
AES Advanced Encryption Standard
CM Counter Mode
DH Diffie-Hellman
DoS Denial of Service
MAC Message Authentication Code
MIKEY Multimedia Internet KEYing
OFB Output Feedback Mode
PK Public-Key
Arkko, et al. [Page 4]
INTERNET-DRAFT msec-mikey November 2001
PS Pre-Shared
RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol
SDP Session Description Protocol
SIP Session Initiation Protocol
SRTP Secure RTP
1.4. Outline
Section 2 describes the basic scenario and the design goals that
MIKEY are based on. It also gives a brief overview of the entire
solution.
The basic key transport/exchange mechanisms are explained in detail
in Section 3. The key derivation and re-keying procedures are
described in Section 4.
Section 5 describes the expected behavior of the involved parties.
This also includes message creation and parsing.
As MIKEY may be carried in SDP over SIP and RTSP, Section 6-8
describes how to integrate and use MIKEY in these scenarios.
Section 9 focuses on how MIKEY may be used in group scenarios.
The Security Considerations section (Section 10), gives a deeper
explanation on different security related topics.
All definitions of the payloads in MIKEY are described in Appendix A
and Appendix B includes a list of when the payloads MUST/MAY be used.
2. Basic Overview
2.1. Scenarios
MIKEY is intended to be used for peer-to-peer, simple one-to-many,
and small-size groups. One of the main multimedia scenarios is 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 multimedia streams
(e.g. SRTP streams).
We identify in the following some typical scenarios which involve the
multimedia applications we are dealing with (see also Figure 1.1.).
a) peer-to-peer (unicast), e.g. a SIP-based [SIP] call between two
parties where the security is either set up by mutual agreement or
each party sets up the security for its own outgoing streams.
Arkko, et al. [Page 5]
INTERNET-DRAFT msec-mikey November 2001
b) many-to-many, without a centralized control unit, e.g. for small
groups where each party may set up the security for its own
outgoing media.
c) many-to-many, with a centralized control unit, e.g. for larger
groups with some kind of Group Controller that sets up the
security.
d) simple one-to-many (multicast), e.g. real-time presentations,
where the sender is in charge of setting up the security.
peer-to-peer/ many-to-many many-to-many
one-to-many (distributed) (centralized)
++++ ++++ ++++ ++++ ++++
|. | |A | |B | |A |---- ----|B |
--| ++++ | |----------| | | | \ / | |
++++ / ++|. | ++++ ++++ ++++ (S) ++++
|A |---------| ++++ \ / |
| | \ ++|B | \ / |
++++ \-----| | \ ++++ / ++++
++++ \|C |/ |C |
| | | |
++++ ++++
Figure 1.1: Examples of the four scenarios: peer-to-peer, one-to-
many, many-to-many without centralized server, and many-to-many with
a centralized server.
The key management solutions may be different in the above scenarios.
For large scale multicast applications and big groups scalability is
an issue, and we refer to other work in the MSEC WG.
This specification only describes the peer-to-peer case, on which the
simple one-to-many and small-size group then can be based. Section 9
brings up some more MIKEY related group issues.
2.2. Design Goals
The goal has been to create a protocol that satisfies most of the
requirements stated in [REQS]. The key management protocol is
designed to have the following characteristics:
* End-to-end security. Only the participants have access to the
generated key(s).
* Simplicity.
* Efficiency. Designed to have:
- low bandwidth consumption,
- low computational workload,
Arkko, et al. [Page 6]
INTERNET-DRAFT msec-mikey November 2001
- small code size, and
- minimal number of round-trips.
* Piggy backing. Possibility to piggy back MIKEY in session
establishment protocols (e.g. SIP and RTSP).
* Independent of the security of the underlying transport.
2.3. System Overview
One objective of MIKEY is to produce a traffic-encrypting key (TEK),
which then can be used as key input to a Security Protocol.
The procedure of setting up a Crypto Session and creating a TEK, is
done in accordance to Figure 2.1.:
1. A Security Association (SA) and a Pre-Master Key (PMK) are created
for the Multimedia Crypto Session (this is done by one of three
alternative key transport/exchange mechanisms, see Section 4).
2. The PMK is used to derive (in a cryptographically secure way) a
TEK for each Crypto Session.
3. The TEK is used as the key input to the Security Protocol.
-------------------
| MCS |
| Key transport |
| /exchange |
- - - - - - - - - -
| SA |
-------------------
| :
| PMK :
v :
------------ :
CS ID ->| TEK | : Security Protocol
|derivation| : Parameters
------------ :
| TEK :
v v
Crypto Session
(Security Protocol)
Figure 2.1. Overview of the key management procedure.
The security protocol MAY 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.
Arkko, et al. [Page 7]
INTERNET-DRAFT msec-mikey November 2001
The re-keying procedure is managed by running the transport/exchange
phase once more to derive a new PMK (and consequently the TEKs).
2.4. Existing solutions
There is work done in 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, addressed to group
communication [GDOI, GSAKMP]. For reasons discussed in Section 3 and
in [REQS], there is however a need for a scheme more suitable for
demanding cases such as real-time data over heterogeneous networks.
3. Basic Key Transport and Exchange Schemes
The following sections propose three different ways to transport/
exchange a Pre-Master Key: with the use of a pre-shared key, public-
key encryption, and Diffie-Hellman (DH) key exchange. The two first
methods we call key transport. In the following we assume unicast
communication.
Note that in the general keys for encryption and signing in general
MUST be different, though for simplicity we use the same notation for
both cases.
3.1. Pre-shared key
The pre-shared key case is done according to Figure 3.1. The Pre-
Master Key (k_p) is randomly chosen by the initiator and then
encrypted with the pre-shared key and sent to the responder. T is a
timestamp added by the Initiator to prevent replay attacks. The
entire message MUST be integrity protected by a Message
Authentication Code (MAC). It is assumed that the pre-shared secret,
s, consists of key material for both the encryption (encr_key) and
the integrity protection (auth_key). The identity IDa MAY be sent to
correctly select the pre-shared key to be used.
A B
K = [IDa],T, E(encr_key,k_p)
A = MAC(auth_key,K)
K, A
--------------------- >
V=MAC(k_v,IDa||IDb||T),[IDb]
[V]
<----------------------
Figure 3.1. Pre-shared key based transport mechanism.
Arkko, et al. [Page 8]
INTERNET-DRAFT msec-mikey November 2001
Authentication of the peers is provided by the MAC(s). The responder
MAY return (if requested by Initiator) the verification message, V,
showing that it knows the PMK. The verification message is created by
applying the MAC function with a verification key, k_v. The
verification key, k_v, is derived from the PMK according to Section
4.1.
Note that the pre-shared case is, by far, the most efficient way to
handle the key transport due to the use of symmetric cryptography
only. This approach has also the advantage that only a small amount
of data has to be exchanged. Of course, the problematic issue is
scalability.
3.2. Public-key encryption
Public-key cryptography can be used to create a scalable system. A
disadvantage with this approach is that it is more resource consuming
than the pre-shared key approach. Another disadvantage is that in
most cases a PKI (Public Key Infrastructure) is needed to handle the
distribution of public keys.
A B
I=(IDa|Cert_A)
K=E(PK_b,k_p)
|| T
[|| I]
[|| H(Cert_B)]
S=Sign(SK_a,H(K))
K,S
---------------------->
V=MAC(k_v,IDa||IDb||T),[IDb]
[V]
<----------------------
Figure 3.2. Key transport using public keys.
The key transport mechanism is according to Figure 3.2. The initiator
encrypts a randomly chosen value k_p, to be used as the PMK, with the
responder's public key (which the initiator already has). The
Initiator creates a message consisting of the encrypted k_p, a
timestamp, and optionally its ID/Certificate and a hash of the
certificate used to encrypt k_p. The message is then signed and sent
to the responder.
Arkko, et al. [Page 9]
INTERNET-DRAFT msec-mikey November 2001
As mentioned, the initiator MAY include a hash of the certificate of
the public key used to encrypt k_p. The responder uses the private
key corresponding to the specified certificate to decrypt the
encrypted PMK.
The responder MAY send a verification message, V, (as in the pre-
shared case) to the initiator, which proves that the responder has
received the PMK correctly. This message uses a MAC (e.g. HMAC), with
a verification key k_v, which is derived from the PMK according to
Section 4.1.
Certificate handling is in general complex; the scheme shown here is
not the only one possible. For example, it is possible for B to fetch
A's certificate via other means. Verification of certificate against
Revocation Lists is not treated here, but may add extra delay.
Certificate handling may involve a number of additional tasks not
shown here, and effect the inclusion of certain parts of the message.
The following observations can, however, be made:
- A typically has to find the certificate of B in order to send the
first message. If A doesn't have B's certificate already, this
may involve one or more roundtrips to a central directory agent.
- it will be possible for A to omit its own certificate and rely on
B getting this certificate using other means. However, we
recommend doing this, only when it is reasonable to assume that
B can be expected to have cached the certificate from a previous
connection. Otherwise accessing the certificate would mean
additional roundtrips for B as well.
- verification of the certificates using Certificate Revocation
Lists (CRLs) or an on-line verification protocol may mean
additional roundtrips for both parties. If a small number of
roundtrips is required for acceptable performance, it may be
necessary to omit some of these checks.
3.3. Diffie-Hellman key exchange
The possibility of using a Diffie-Hellman (DH) key exchange method is
also offered. Though, this approach in general has a higher resource
consumption (both computationally and in bandwidth) than the previous
ones.
For a fixed, agreed upon, group, (G,*), for g in G and a natural
number x, we let g**x denote g*g*..*g (x times). Choices for the
parameters are given in the DH payload in Appendix A.6. Note that the
group MUST have a size of at least two to the power of the desired
PMK size.
Arkko, et al. [Page 10]
INTERNET-DRAFT msec-mikey November 2001
A B
I = (IDa|Cert_A)
K = g**x || T [|| I]
S = Sign (SK_a,H(K))
K,S I' = (IDb|Cert_B)
----------------------> K' = g**y || T [|| I']
S' = Sign (SK_b,H(K'))
K',S'
<----------------------
k_p= g**(xy) k_p=g**(xy)
Figure 3.3. Diffie-Hellman key based exchange, where x and y are
randomly chosen respectively by A and B.
The key exchange is done according to Figure 3.3. The initiator
chooses a random value x, and sends a signed message including g**x
and a timestamp to the responder (optionally also including its
certificate or identity).
The group parameters (e.g., the group G) are a set of parameters
chosen by the initiator. The responder chooses a random positive
integer y, and sends a signed message including g**y and the
timestamp to the initiator (optionally also providing its
certificate).
Both parties then calculate the PMK, g**(xy).
The authentication is due to the signing of the DH key, and is
necessary to avoid man-in-the-middle attacks.
Note that this approach does not require that the initiator has to
posses any of the responder's certificate before the setup. Instead,
it is sufficient that the responder includes it's signing certificate
in the response.
This approach is the most expensive approach. It requires first of
all, that both sides compute one signature, then one verification and
finally two exponentiations.
4. Key Management
4.1. TEK and Verification key Calculation
We define in the following a method to derive a Verification key and
TEKs from the PMK.
Arkko, et al. [Page 11]
INTERNET-DRAFT msec-mikey November 2001
4.1.1. Assumptions
We assume that the following parameters are in place (to be exchanged
as security parameters, in connection to the actual key exchange):
k_p: the PMK, which MUST be random and kept secret.
The following parameter MAY be sent in the clear:
mcs_id: Master Crypto Session ID
cs_id: the Crypto Session ID
pmk_len: the length of the PMK.
tek_len: desired TEK length for the security protocol.
4.1.2. Notation
Let HMAC be the SHA1 based message authentication function, see
[HMAC,SHA1]. Similar to [TLS], define:
P (s, seed, m) = HMAC (s, A_1 || seed) ||
HMAC (s, A_2 || seed) || ...
HMAC (s, A_m || seed)
where
A_0 = seed,
A_i = HMAC (s, A_(i-1)).
4.1.3. Description
The following procedure is applied to compute the TEK:
* let n = pmk_len / 512, rounded up to the nearest integer
* split the pre-master key into n blocks, k_p = s_1 || ... || s_n,
where all s_i, except possibly s_n, are 512 bits each
* let m = tek_len / 160, rounded up to the nearest integer
* set seed = "MIKEYtek" || cs_id || mcs_id
Then, the TEK is obtained as the tek_len most significant bits of
P (s_1, seed, m) ^ P (s_2, seed, m) ^ ... ^ P (s_n, seed, m).
The procedure of generating the Verification key, k_v, is the same,
replacing the constant string "MIKEYtek" by the constant string
"MIKEYver", and cs_id by 0. (This gives a verification key of length
equal to tek_len).
Arkko, et al. [Page 12]
INTERNET-DRAFT msec-mikey November 2001
If the security protocol does not support key derivation for
authentication and encryption itself from the TEK, authentication and
encryption keys MAY directly be created for the security protocol by
replacing "MIKEYtek" with "MIKEYaut" and "MIKEYenc" respectively, and
tek_len by the desired key-length(s) in each case.
4.2. Re-keying
A PMK re-keying mechanism is necessary, e.g. when a key is
compromised, when access control is desired, or simply when a key
expires. Therefore, re-keying MUST be supported to allow a smooth
(continuos) communication. Re-keying is performed by executing MIKEY
again before the PMK expires.
The necessary parameter(s) to be defined to support the re-keying
procedure is the new PMK and (when applicable) a signature (with the
corresponding parameters as defined in Section 3.2 and 3.3). It may
be necessary to specify the key lifetime range e.g. to trigger a new
re-keying procedure during the on-going Multimedia Crypto Session.
The parameters for re-keying are the following:
Encrypted PMK, or DH-values (depending on method). This is sent to be
able to derive a new PMK and thereby new TEKs.
SPI is an identifier of the new k_p. This can only be used when it is
supported by the security protocol. Note that the use of SPI will
exclude the use of n_start and n_end.
n_start and n_end define the lifetime range of the PMK k_p (and MAY
be used instead of a SPI). The lifetime range MAY be expressed in
terms of time, packet index, etc. The deployed security protocol MUST
specify which unit is used.
If n_start and n_end is not specified, the default n_start value
SHOULD be that the key is valid from the first observed packet. For
the n_end value, as default the key is valid 'until further notice'.
This does not mean that the protocol will be able to run forever (all
security protocols will 'exhaust' the TEK sooner or later).
A Multimedia Crypto Session MAY contain several Crypto Sessions. A
problem that then MAY occur is to synchronize the re-keying if an SPI
is not used. It is then recommended that one main Crypto Session is
identified from the MCS and the re-keying is done with respect to
that. Exactly how this should be done is for future study.
Note that it MAY not be necessary to include certificates and other
information that was provided in the first exchange, i.e. all
parameters that are static or optional to include.
Arkko, et al. [Page 13]
INTERNET-DRAFT msec-mikey November 2001
5. Behavior and message handling
Each message that is sent by the Initiator or the Responder, is built
by a set of payloads. This section describes how messages are created
and also when they can be used.
5.1. General
5.1.1. Capability Discovery
The initiator tries to guess the responder's capabilities in terms of
security algorithms etc. If the guess is wrong, then the responder
may send back its own capabilities (negotiation) to let the initiator
choose a common set of parameters. Multiple attributes may be
provided in sequence. This is done to reduce the number of roundtrips
as much as possible.
If the responder is not willing/capable to provide security or the
parties simply cannot agree, it is up to the parties' policies how to
behave, i.e. accept an insecure communication or reject it.
5.1.2. Error Handling
All errors due to the key management protocol SHOULD be reported to
the peer(s) by an error message. The Initiator SHOULD therefore
always be prepared to receive a response back from the responder.
If the responder does not support the set of parameters suggested by
the initiator, the error message SHOULD include the supported
parameters (see also Section 5.1.1.).
5.2. Creating a message
To create a MIKEY message, a Common header payload is first created.
This payload is then followed, depending on the message type, by a
set of information payloads (e.g. DH-value payload, Signature
payload, Security Protocol payload). The defined payloads and the
exact encoding of each payload are described in Appendix A.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +
~ Common Header... ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload 1 ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Arkko, et al. [Page 14]
INTERNET-DRAFT msec-mikey November 2001
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload x ... !
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MAC/Signature payload ~
+ +
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.1. MIKEY payload example.
The process of generating a message consists of the following steps:
* Create a master payload starting with the Common header payload.
* Concatenate necessary payloads to the master payload (Appendix B
lists what payloads MUST/MAY be used for the different messages).
* As a last step (for messages that must be authenticated),
concatenate the payload containing the MAC/signature, where the
MAC/signature field is initiated with zeros.
* Calculate the MAC/signature over the entire master payload and
update the MAC/signature field with the MAC/signature.
5.3. Parsing a message
In general, parsing is done by extracting payload by payload and
checking that no errors occur (the exact procedure is implementation
specific). However, for the Responder, it is recommended that the
following procedure is followed:
* Extract the Timestamp and check that it is within the allowable
clock skew. Also check the replay cache so that the message is not
replayed (see also Section 5.4).
* Extract ID and authentication algorithm (if not included, assume
default one).
* Verify the MAC/signature.
* If the authentication is NOT successful, an Auth failure Error
message MUST be sent to the initiator.
* If the authentication is successful, the message SHOULD be
processed. Though how it is processed is implementation specific.
Arkko, et al. [Page 15]
INTERNET-DRAFT msec-mikey November 2001
* If any unsupported parameters or errors occur during the
processing, these SHOULD be reported to the Initiator by sending an
error message. The processing SHOULD then be aborted. The error
message MAY also include payloads to describe the supported
parameters.
* If needed, a response message is created and sent to the Initiator.
5.4. Replay handling
* Each Responder MUST utilize a replay cache in order to remember the
messages presented within the allowable clock skew (see also
Section 10.3. for timestamp considerations).
* A message SHOULD be deleted from the cache when it is outdated with
respect to the clock skew.
* Due to physical limitations, the replay cache SHOULD be set to
store up to a maximum number of messages (see below for more
details).
* If the host loses track of the incoming requests (e.g. due to
overload), it must reject all incoming requests until the clock
skew interval has passed.
For a client, the maximum number of messages it will recall may vary
depending on the capacity of the client itself and the network, but
also the number of expected messages should be taken into account.
The following is a recommendation of how the maximum size of the
replay cache may be calculated:
maxsize = Min (A, e*x) * block_size
where
A: maximum memory blocks possible to allocate (for simplicity: 1
memory block can contain the information from one message)
e: fault-tolerant value (MUST be >1)
x: #max expected messages per "clock skew"
block_size: size of the message to be cached (note that it will
probably not be needed to cache the entire message, instead a hash of
the message and the timestamp might be enough).
In case of a DoS attack, the client will in most cases be able to
handle the replay cache. A bigger problem will probably be to process
the messages (verify signatures/MACs), due to the computational
workload this implies.
Arkko, et al. [Page 16]
INTERNET-DRAFT msec-mikey November 2001
5.5. Reliability
When MIKEY is integrated with a transporting protocol, the
reliability scheme of the latter may be applied. Otherwise, the basic
processing applied to ensure protocol reliability is the following.
The transmitting entity (initiator or responder) MUST:
* Set a timer and initialize a retry counter
* If the timer expires, the message is resent and the retry counter
is decreased.
* If the retry counter reaches zero (0), the event MAY be logged in
the appropriate system audit file
6. SDP integration
SDP descriptions [SDP] can be carried by several protocols, such as
SIP and RTSP. One of the goals in the design of MIKEY was to be able
to piggy-back it in other protocols (such as SIP and RTSP). Both SIP
and RTSP often uses SDP to describe the media sessions. Therefore, it
is also convenient to be able to integrate the key management in the
session description it is supposed to protect. [KMASDP] describes
attributes that SHOULD be used by a key management protocol that is
integrated in SDP. The following two SDP attributes MUST be used by
MIKEY.
a=keymgmt-prot:<protocol>
a=keymgmt-data:<data>
The keymgmt-prot attribute indicates the key management protocol.
Therefore, it MUST be set to "MIKEY", i.e.
a=keymgmt-prot:MIKEY
The data part is used to transport the actual key management payload
message. Due to the text based nature of SDP, this part MUST be
base64 encoded to avoid illegal characters.
a=keymgmt-data:<base64 encoded data>
Example
| a=keymgmt-prot:MIKEY
| a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD...
MCS < CS 1 < m=audio 49000 RTP/SAVP 98
| a=rtpmap:98 AMR/8000
| CS 2 < m=video 2232 RTP/SAVP 31
Arkko, et al. [Page 17]
INTERNET-DRAFT msec-mikey November 2001
In this example the multimedia crypto session consists of two crypto
sessions (one audio stream and one video stream).
7. Key management with SIP
In a basic SIP call between two parties (see Figure 7.1.), SIP
(Session Initiation Protocol, [SIP]) is used as a session
establishment protocol between a caller A and a callee B.
|A's SIP| <.......> |B's SIP|
|Server | SIP |Server |
--------- ---------
^ ^
. .
++++ SIP . . SIP ++++
| | <............. ..............> | |
| | | |
++++ <-------------------------------------------> ++++
SRTP
Fig 7.1.: SIP-based call example. The two parties uses SIP to set up
an SRTP stream between A and B.
7.1. Integration
SIP may carry SDP descriptions, since the participants negotiate the
media encoding etc. Therefore, the SDP attributes previously
described may be integrated inside the INVITE and the answer to that.
Eventually, subsequent SIP messages may also be used, e.g., when
parameter negotiation is needed.
It may be assumed that the caller knows the identity of the callee.
However, unless the initiator's identity can be derived from SIP
itself, the initiator (caller) MUST provide the identity to the
callee. It is recommended to use the same identity for both SIP and
MIKEY.
7.2. Re-keying
A re-keying mechanism is necessary, e.g. when the key is compromised
or simply because it has a restricted lifetime. When SIP is used as
the session establishment protocol, a re-INVITE can be issued
carrying SDP with the MIKEY data (this is sent by the Initiator of
MIKEY). Note that it might not be necessary to send all information,
such as the certificate, due to the already established call.
Arkko, et al. [Page 18]
INTERNET-DRAFT msec-mikey November 2001
8. Key management with RTSP
The Real Time Streaming Protocol (RTSP) [RTSP] is used to control
media streaming from a server. The media session is typically
obtained via an SDP description, received by a DESCRIBE message, or
by other means (e.g., HTTP). To be able to pass the MIKEY messages in
RTSP messages not containing a SDP description, the RTSP KeyMgmt
header (defined in [KMASDP]) is used.
8.1. Integration
The server MUST include the necessary security parameters, key
included, in the SDP part of the response to the initial DESCRIBE
message.
If a response is required, this should be included in the first SETUP
message from the client to the server. Note that the SETUP message
does not include a SDP description, why the RTSP KeyMgmt header
(defined in [KMASDP]) MUST be used to pass the MIKEY message.
Note that it is the server that will be the Initiator of MIKEY in
this case. This has some advantages, first the server will always be
able to chose the key for the content it distributes, secondly, it
will then have the possibility to use the same key for the same
content that are streamed/sent to more than one client.
8.2. Re-keying
To be able to have a server initiated re-keying procedure, either the
ANNOUNCE message or the SET_PARAMETER message SHOULD be used to send
the re-keying material. A disadvantage of using these, are that they
are not mandatory to implement. Note that the ANNOUNCE method has the
possibility to send SDP descriptions to update previous ones (i.e. it
is not needed to use the RTSP KeyMgmt header).
9. Groups
What has been discussed up to now can be extended from the unicast
case to small-size groups and simple one-to-many scenarios. However,
key management is more complex in the case of groups. This section
does not give a solution for how MIKEY should be used for groups
(that will be a second step in the process of MIKEY). This section
only describes some properties of the transport and exchange
mechanisms that might be of importance for future work and extensions
in the area.
Arkko, et al. [Page 19]
INTERNET-DRAFT msec-mikey November 2001
9.1. Simple one-to-many
++++
|S |
| |
++++
|
--------+-------------- - -
| | |
v v v
++++ ++++ ++++
|A | |B | |C |
| | | | | |
++++ ++++ ++++
Figure 9.1. Simple one-to-many scenario.
In the most simple one-to-many scenario, where a server is streaming
to a small group of clients. In this scenario RTSP or SIP could be
used for the registration and the key management set up. The server
would then act as the Initiator of MIKEY (see also Section 8.). In
this scenario the pre-shared key or public key transport mechanism
would be appropriate to use to transport the same PMK to all the
clients (which will result in common TEKs for the group).
However, as the group increases in size, scalability and management
problems may arise. The Group Key Management Architecture [GARCH]
describes a scalable architecture of handling this scenario. The
architecture can be used as a base for how MIKEY should be used in
order to handle scalable groups. Some minor extensions to MIKEY will
be needed, such as the transport of a key-encrypting key (KEK).
However, this document does not consider how MIKEY should be used
with the architecture.
9.2. Small-size group
++++ ++++
|A | -------> |B |
| | <------- | |
++++ ++++
^ | | ^
| | | |
| | ++++ | |
| --->|C |<--- |
------| |------
++++
Figure 9.2. Small-size group without centralized controller.
Arkko, et al. [Page 20]
INTERNET-DRAFT msec-mikey November 2001
As described in the overview section, for small-size groups one may
expect that each client will be in charge for setting up the security
for its outgoing streams. In these scenarios, the pre-shared key and
the public-key transport methods should be used.
One scenario may then be that the client sets up a three-part call,
using SIP. Due to the small size group, unicast SRTP is used between
the clients. Each client may set up the security for its outgoing
streams to the others. A scenario like this would not require any
modifications neither to MIKEY nor SIP/SDP.
10. Security Considerations
10.1. General
No chain is stronger than its weakest link. The cryptographic
functions protecting the keys during transport/exchange SHOULD offer
a security at least corresponding to the (symmetric) keys they
protect. For instance, with current state of the art, see [LV],
protecting a 128-bit AES key by a 512-bit RSA [RSA] key offers an
overall security below 64-bits. On the other hand, protecting a 64-
bit symmetric key by a 2048-bit RSA key appears to be an "overkill",
leading to unnecessary time delays. Therefore, key size for the key-
exchange mechanism SHOULD be weighed against the size of the
exchanged key.
Moreover, if the PMKs are not random, a brute force search may be
facilitated, again lowering the effective key size. Therefore, care
MUST be taken when designing the (pseudo) random generators for PMK
generation.
For the selection of the hash function, SHA-1 with 160-bit output is
the default one. In general, hash sizes should be twice the "security
level", indicating that SHA1-256, [SHA256], should be used for the
default 128-bit level. However, due to the real-time aspects in the
scenarios we are treating, hash size slightly below 256 are
acceptable as the normal "existential" collision probabilities would
be of secondary importance.
In a Multimedia Crypto Session, the Crypto Sessions (audio, video
etc) share the same PMK as discussed earlier. From a security point
of view, the criterion to be satisfied is that the encryption of the
individual Crypto Sessions are performed "independently". In MIKEY
this is accomplished by having unique Crypto Session identifiers (see
also Section 4.1.). The TEK derivation method assures this by
providing cryptographically independent TEKs to distinct Crypto
Sessions (within the Multimedia Crypto Session), regardless of the
security protocol used.
Arkko, et al. [Page 21]
INTERNET-DRAFT msec-mikey November 2001
Specifically, the TEK key derivation is implemented by a pseudo-
random function. The one used here is a simplified version of that
used in TLS [TLS]. Here, we use only one single hash function,
whereas TLS uses two different functions, motivated by the risk of
one of the hashes being broken. We motivate our simplification by the
observation that if a single widely used hash, e.g. SHA1, is broken,
the wide-spread use of that function means that we have much more to
be worried about than the security of a single protocol. Also, SHA1
would need to have very serious flaws for our pseudo random function
to be considered insecure.
In the pre-shared key and public-key schemes, the PMK is generated by
a single party (initiator). This makes MIKEY more sensitive if the
initiator uses a bad random number generator. It should also be noted
that neither the pre-shared nor the public-key scheme provides
perfect forward secrecy. If mutual contribution or perfect forward
secrecy is desired, the Diffie-Hellman scheme MUST be used.
Forward/backward security: if the PMK, k_p, is exposed, all TEKs
generated from it are compromised. However, under the assumption that
the derivation function is a pseudo-random function, disclosure of an
individual TEK does not compromise other (previous or later) TEKs
derived from the same PMK.
10.2. Key lifetime
Even if the lifetime of a PMK is not specified, it MUST be taken into
account that the encryption transform in the underlying security
protocol can in some way degenerate after a certain amount of
encrypted data. Each security protocol MUST define such maximum
amount and trigger a re-keying procedure before the 'exhaustion' of
the key. For SRTP the key MUST be changed at least for every 2**48
packet (i.e. every time the ROC + SEQ nr in SRTP wraps).
As a rule of thumb, if the security protocol uses an 'ideal' b-bit
block cipher (in CBC mode, counter mode, or a feedback mode with full
b-bit feedback), degenerate behavior in the crypto stream, possibly
useful for an attacker, is expected to occur after a total of roughly
2**(b/2) encrypted b-bit blocks (using random IVs). For some security
margin, re-keying SHOULD be triggered well in advance compared to the
above bound. See [BDJR] for more details.
For use of a dedicated stream cipher, we refer to the analysis and
documentation of said cipher in each specific case.
10.3. Timestamps
The timestamp prevents against replay attacks under the following
assumptions:
Arkko, et al. [Page 22]
INTERNET-DRAFT msec-mikey November 2001
* Each host MUST have a clock which is at least "loosely
synchronized" to the time of the other hosts.
* If the clocks are to be synchronized over the network, a secure
network clock synchronization protocol MUST be used.
In general, a client may not expect a very high load of incoming
messages and may therefore allow the degree of looseness to be on the
order of minutes (5-10 minutes are believed to be ok). If a DoS
attack is launched and the replay cache grows too large, MIKEY may
dynamically decrease the looseness so that the replay cache becomes
manageable.
Servers may be the entities that will have the highest work load. It
is also recommended that the servers are the Initiators of MIKEY.
This will result in that the servers will not manage any significant
replay cache as they will refuse all incoming messages that are not a
response to an already (by the server) sent message.
Practical experiences of Kerberos and other timestamp based system
indicates that it is not always necessary to synchronize the
terminals over the network. Manual configuration could be a feasible
alternative in many cases (especially in scenarios where the degree
of looseness is high). However, the choice must be carefully based
with respect to the usage scenario.
The use of timestamps instead of challenge-response requires the
systems to have synchronized clocks. Of course, if two clients are
not synchronized, they will have difficulties with setting up the
security. The current timestamp based solution has been selected to
allow a maximum of one round-trip (i.e. two messages), but still
provide a reasonable replay protection. A (secure) challenge-response
based version would require at least three messages.
10.4. Identity protection
Identity protection was not a main design goal when designing MIKEY.
Such feature would have added more complexity to the protocol and was
therefore chosen not to be included. As MIKEY is anyway proposed to
be transported over e.g. SIP, the identity may be exposed by this.
However, if the transporting protocol is secured and also provides
identity protection, MIKEY might inherit the same feature. How this
should be done is for future study.
10.5. Denial of Service
This protocol is resistant to Denial of Service attacks in the sense
that a responder does not construct any state (at the key management
protocol level) before it has authenticated the initiator. However,
this protocol, like many others, is open to attacks that use spoofed
IP addresses to create a large number of fake requests. This MAY be
Arkko, et al. [Page 23]
INTERNET-DRAFT msec-mikey November 2001
solved by letting the protocol transporting MIKEY do an IP address
validity test.
11. Conclusions
Work for securing real-time applications have started to appear. This
has brought forward the need for a key management solution to support
the security protocol. The key management has to fulfil requirements,
which make it suitable in the context of conversational multimedia in
a heterogeneous environment. MIKEY was designed to fulfill such
requirements and optimized so that it also may be integrated in other
protocol such as SIP and RTSP.
MIKEY can be used in different scenarios, for peer-to-peer
communication, simple one-to-many, and for small-size groups without
a centralized group server. This specification focused on the basic
peer-to-peer scenario, as this also will be the base for the group
scenarios.
12. Acknowledgments
The authors would like to thank, Mark Baugher, Ran Canetti, the rest
of the msec WG, Pasi Ahonen, Rolf Blom, Vesa-Matti Mantyla, and
Magnus Westerlund, for their valuable feedback.
13. Author's Addresses
Jari Arkko
Ericsson
02420 Jorvas Phone: +358 40 5079256
Finland Email: jari.arkko@ericsson.com
Elisabetta Carrara
Ericsson Research
SE-16480 Stockholm Phone: +46 8 50877040
Sweden EMail: elisabetta.carrara@era.ericsson.se
Fredrik Lindholm
Ericsson Research
SE-16480 Stockholm Phone: +46 8 58531705
Sweden EMail: fredrik.lindholm@era.ericsson.se
Mats Naslund
Ericsson Research
SE-16480 Stockholm Phone: +46 8 58533739
Sweden EMail: mats.naslund@era.ericsson.se
Arkko, et al. [Page 24]
INTERNET-DRAFT msec-mikey November 2001
Karl Norrman
Ericsson Research
SE-16480 Stockholm Phone: +46 8 4044502
Sweden EMail: karl.norrman@era.ericsson.se
14. References
[AES] Advanced Encryption Standard, www.nist.gov/aes
[BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P.: "A
Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes
of Operation", in Proceedings of the 38th Symposium on Foundations of
Computer Science, IEEE, 1997, pp. 394-403.
[GARCH] Baugher, M., Canetti, R., and Dondeti, L., "Group Key
Management Architecture", Internet Draft, June 2001, Work in
Progress.
[GDOI] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group
Domain of Interpretation", Internet Draft, February 2001, Work in
Progress.
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer,
R., "Group Secure Association Key Management Protocol", Internet
Draft, March 2001, Work in Progress.
[HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
Norrman, K., "Key Management Extensions for SDP", Internet Draft,
Work in Progress (MMUSIC WG).
[LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for
Cryptosystems", http://www.cryptosavvy.com/suggestions.htm
[MD5] Rivest, R.,"MD5 Digest Algorithm", RFC 1321, April 1992.
[NAI] Aboba, B. and Beadles, M., "The Network Access Identifier",
IETF, RFC 2486, January 1999.
[NTP] Mills, D., "Network Time Protocol (Version 3) specification,
implementation and analysis", RFC 1305, March 1992.
[OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC
2412, November 1998.
Arkko, et al. [Page 25]
INTERNET-DRAFT msec-mikey November 2001
[PKCS1] PKCS #1 - RSA Cryptography Standard,
http://www.rsalabs.com/pkcs/pkcs-1/
[REQS] Blom, R., Carrara, E., Lindholm, F., and Arkko, J., "Design
Criteria for Multimedia Session Key Management in Heterogeneous
Networks", Internet Draft, July 2001, Work in Progress.
[RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining
Digital Signatures and Public-Key Cryptosystems". Communications of
the ACM. Vol.21. No.2. pp.120-126. 1978.
[SDP] Handley, M., and Jacobson, V., "Session Description Protocol
(SDP), IETF, RFC2327
[SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
http://csrc.nist.gov/fips/fip180-1.ps
[SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512",
http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf
[SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J.,
"SIP: Session Initiation Protocol", IETF, RFC2543.
[SRTP] Blom, R., Carrara, E., McGrew, D., Naslund, M, Norrman, K.,
and Oran, D., "The Secure Real Time Transport Protocol", Internet
Draft, IETF, Work in Progress (AVT WG).
[TLS] Dierks, T. and Allen, C., "The TLS Protocol - Version 1.0",
IETF, RFC 2246.
[TMMH] McGrew, D., "The Truncated Multi-Modular Hash Function
(TMMH)", Internet Draft, IETF, Work in Progress.
[URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396
Arkko, et al. [Page 26]
INTERNET-DRAFT msec-mikey November 2001
Appendix A - Payload Encoding
This appendix describes in detail all the payloads. For all encoding,
Network byte order MUST always be used.
A.1. Common header payload
The Common header payload MUST always be present as the first payload
in each message. The common header includes general description of
the exchange message.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! version ! data type ! next payload !R! Hash func !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MCS/CS ID type! !
+-+-+-+-+-+-+-+-+ +
~ MCS/CS ID ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The common header contains the following information:
* version: the version number of MIKEY.
version = 1
* data type: describes the type of message (e.g. public-key transport
message, verification message, error message).
Data type | Value | Comment
--------------------------------------
Pre-shared | 0 | Initiator's pre-shared key transport message
PS ver msg | 1 | Verification message of a Pre-shared message
Public key | 2 | Initiator's public-key transport message
PK ver msg | 3 | Verification message of a public-key message
D-H init | 4 | Initiator's DH exchange message
D-H resp | 5 | Responder's DH exchange message
Error | 6 | Error message
* next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last
payload.
Next payload | Value
---------------------
Last payload | 0
PS data | 1
Arkko, et al. [Page 27]
INTERNET-DRAFT msec-mikey November 2001
PK data | 2
DH data | 3
Signature | 4
Timestamp | 5
ID | 6
Certificate | 7
Cert hash | 8
Ver msg | 9
n_start | 10
n_end | 11
SPI | 12
SP | 13
Error | 14
* R: flag to indicate whether a response is expected or not (this has
only meaning when it is set by the Initiator).
R = 0 ==> no response expected
R = 1 ==> response expected
* Hash func: Indicates the hash function that has been/will be used.
Hash func | Value | Comments
--------------------------------------------------------
SHA-1 | 0 | Mandatory, Default (see [SHA1])
MD5 | 1 | (see [MD5])
SHA256 | 2 | (see [SHA256])
SHA384 | 3 | (see [SHA256])
SHA512 | 4 | (see [SHA256])
* MCS/CS ID type: specifies the id used to uniquely identify the MCS
and the CS(s).
MCS/CS ID type | Value | Comments
-------------------------------------
SRTP-ID | 0 | Mandatory
* MCS/CS ID: Identifies the multimedia crypto session and/or the
crypto session(s) that the SA should be created for. The currently
defined IDs are:
SRTP ID
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! #CS ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
! !
Arkko, et al. [Page 28]
INTERNET-DRAFT msec-mikey November 2001
+ SRTP MCS ID (80 bits) +
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC 1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC 2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC #CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* #CS: Indicates the number of Crypto Sessions, i.e. the number of
SRTP streams.
* SRTP MCS ID: MUST be chosen at random by the Initiator (the
Initiator SHOULD however check for collisions). The Responder MUST
use the same MCS ID in the response.
* SSRC x: specifies the SSRC that MUST be used for the SRTP streams.
Note that it is the sender of the streams who chooses the SSRC.
Therefore, it might be possible that the Initiator of MIKEY does
can not fill in all fields. In this case, SSRCs that are not chosen
by the Initiator are set to zero and the Responder fills in these
field in the response message.
NOTE: A stream using SSRC x will also have Crypto Session ID x.
A.2. PS data payload
The PS (pre-shared) data payload contains the encrypted PMK and the
MAC of the entire message. The PS data payload MUST be added as the
last payload in the pre-shared transport message.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MAC alg ! Encr alg ! Encr data len | Reserved !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encr data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MAC ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* MAC alg specifies the authentication algorithm used.
MAC alg | Value | Comments
--------------------------------------
HMAC-SHA1-160 | 0 | Mandatory
Arkko, et al. [Page 29]
INTERNET-DRAFT msec-mikey November 2001
HMAC-SHA1-160 is HMAC using SHA-1 with a 160-bits tag length.
* Encr alg: The encryption algorithm used to encrypt the PMK.
Encr alg | Value | Comments
-------------------------------------------
AES-CM-128 | 1 | Mandatory
AES-CM-128 is AES in Counter Mode (as defined in [SRTP] where the
salting key = 0) with 128-bit block size and key. The IV MUST be
created as IV = MCS ID || T32 || 0...0, where T32 is the 32 least
significant bits of the timestamp and 0...0 is 16 bits of zeros.
* Encr data: The encrypted PMK.
* MAC: The message authentication code of the entire message.
A.3. PK data payload
The PK (public-key) data payload contains the encrypted data from the
PK transport.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Key data len ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ Key data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this
payload.
* Key data len: The length of the Key data field (in bytes).
* Key data: The encrypted PMK (padding and formatting MUST be done
according to RSA/PKCS#1 if RSA is used).
A.4. DH data payload
The DH data payload carries the DH-value and indicates the DH-group
used.
Arkko, et al. [Page 30]
INTERNET-DRAFT msec-mikey November 2001
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! DH-Group ! DH-key len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DH-value ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this
payload.
* DH-Group: identifies the DH group used.
DH-Group | Value | Comments
--------------------------------------
OAKLEY 5 | 0 | Mandatory
OAKLEY 1 | 1 |
OAKLEY 2 | 2 |
See [OAKLEY] for the definitions of the Oakley groups.
* DH-key len: The length of the DH-value field (in bytes).
* DH-value: The public DH-value.
A.5. Signature payload
The Signature payload carries the signature and its related data. The
signature payload MUST always be the last payload in the PK transport
and DH exchange messages.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature len ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ Signature ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Signature len: The length of the signature field (in bytes).
* Signature: The signature (padding and formatting MUST be done
according to RSA/PKCS#1 if RSA is used).
A.6. Timestamp payload
The timestamp payload carries the time information. The current
defined timestamp is as defined in NTP [NTP], i.e. a 64-bit number in
seconds relative to 0h on 1 January 1900. An implementation must be
Arkko, et al. [Page 31]
INTERNET-DRAFT msec-mikey November 2001
aware of (and take into account) the fact that the counter will
overflow approximately every 136th year. It is RECOMMENDED that the
time is always specified in GMT.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! TS type ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ TS-value ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last
payload. See Appendix A.1. for values.
* TS type: specifies the timestamp type used.
TS type | Value | Comments
-------------------------------------
NTP-GMT | 0 | Mandatory (64-bits)
NTP | 1 | Mandatory (64-bits)
Note that NTP-GMT is the NTP time but calculated from GMT. This is to
avoid time-zone problems.
* TS-value: The timestamp value of the specified TS type.
A.7. ID payload / Certificate payload
The ID payload carries a uniquely-defined identifier.
The certificate payload contains an indicator of the certificate
provided as well as the certificate data.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! ID/Cert Type ! ID/Cert len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID/Certificate Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last
payload. See Appendix A.1. for values.
* ID Type: specifies the identifier type used.
Arkko, et al. [Page 32]
INTERNET-DRAFT msec-mikey November 2001
ID Type | Value | Comments
----------------------------------------------
NAI | 0 | Mandatory (see [NAI])
URI | 1 | Mandatory (see [URI])
* Cert Type: specifies the certificate type used.
Cert Type | Value | Comments
----------------------------------------------
X.509 | 0 | Mandatory
X.509 URL | 1 |
* ID/Cert len: The length of the ID or Certificate field (in bytes).
* ID/Certificate: The ID or Certificate data.
A.8. Cert hash payload
The Cert hash payload contains the hash of the certificate used. The
hash function used MUST be the one specified in the Common header
payload.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! !
+-+-+-+-+-+-+-+-+ +
~ Hash ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this
payload.
* Hash: The hash data. Note: the hash length is implicit from the
hash function used.
A.9. Ver msg payload
The Ver msg payload contains the calculated verification message in
the PS/PK transport.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Auth alg ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ Ver data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Arkko, et al. [Page 33]
INTERNET-DRAFT msec-mikey November 2001
* next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last
payload. See Appendix A.1. for values.
* Auth alg specified the authentication algorithm used for the
verification message.
Auth alg | Value | Comments
------------------------------------
HMAC-SHA1-160 | 0 | Mandatory
HMAC-SHA1-160 is HMAC using SHA-1 with a 160-bits tag length.
* Ver data: The verification message data. Note: the length is
implicit from the authentication algorithm used.
A.10. n_start/n_end/SPI payload
The n_start/n_end/SPI payload defines the n_start value, the n_end
value or the SPI as defined in Section 4.2.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Length | !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ Valid from/Expires/SPI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this
payload.
* Length: The length of the n_start/n_end/SPI field (in bytes).
* Valid from: Indicates the Index/Sequence number when the key is
valid from. The field size is dependent on the security protocol.
For SRTP, this field MUST be 48 bits.
* Expires: Indicates the Index/Sequence number when the key expires.
The field size is dependent on the security protocol. For SRTP,
this field MUST be 48 bits.
* SPI: Indicates a SPI that MUST be associated with the new PMK. The
field size may be dependent on the security protocol.
A.11. SP payload
The SP payload defines the security protocol that will be used, and
its related parameters.
Arkko, et al. [Page 34]
INTERNET-DRAFT msec-mikey November 2001
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! SP ! SP param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last
payload. See Appendix A.1. for values.
* SP defines the security protocol used.
SP | Value
---------------------
SRTP | 0
* SP param defines the parameters for the security protocol. SP param
is dependent on the defined security protocol.
For SRTP the SP param is currently defined as:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! encr alg ! auth alg !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len ! Salt key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: SRTP was not finalized by the date for this draft's submission.
Therefore, these parameters might be an issue for update!
* encr alg specifies the desired encryption algorithm to be used.
encr alg | Value | Comments
-------------------------------------------
NULL | 0 | Mandatory
AES-CM-128 | 1 | Mandatory
AES-F8-128 | 2 |
AES-CM-128 is AES in CM with 128-bit block size and key.
AES-F8-128 is AES in f8 mode with 128-bit block size and key.
* auth alg specifies the desired authentication algorithm to be used.
auth alg | Value | Comments
-------------------------------------------
NULL | 0 | Mandatory
Arkko, et al. [Page 35]
INTERNET-DRAFT msec-mikey November 2001
TMMH-16-16 | 1 | ?
HMAC-SHA1-32 | 2 | ?
TMMH-16-16 is TMMH/16 [TMMH] with a 16-bit tag length.
HMAC-SHA1-32 is HMAC using SHA-1 with a 32-bits tag length.
* Salt len: Length of the salting key.
* Salt key: The salting key to SRTP (must be random).
A.12. Error payload
The Error payload is used to specify the error(s) that may have
occurred.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Error nr ! Reserved !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last
payload. See Appendix A.1. for values.
* Error nr indicates the type of error that was encountered.
Error nr | Value | Comment
-------------------------------------------------------
Auth failure | 0 | Authentication failure
Invalid TS | 1 | Invalid timestamp
Invalid hash | 2 | hash function NOT supported
Invalid MA | 3 | MAC algorithm NOT supported
Invalid DH | 4 | DH group NOT supported
Invalid ID | 5 | ID NOT supported
Invalid Cert | 6 | certificate NOT supported
Invalid SP | 7 | SP NOT supported
Invalid SPpar | 8 | SP parameters NOT supported
Appendix B. - Payload usage summary
Depending on the type of message, different payloads MUST and MAY be
included. There are five distinct types of messages:
* Pre-shared key transport message
* Public key transport message
Arkko, et al. [Page 36]
INTERNET-DRAFT msec-mikey November 2001
* Verification message (for either pre-shared key or public key)
* DH exchange message (bi-directional)
* Error message
| Message Type
Payload type | PS | PK | DH | Ver | Error
-------------------------------------------------
PS data | M - - - -
PK data | - M* - - -
DH data | - - M - -
Ver msg | - - - M -
Error | - - - - M
Timestamp | M M M - O
ID | O O O O O
Signature | - O M - -
Certificate | - O O - -
Cert hash | - O O - -
n_start | O O O - -
n_end | O O O - -
SPI | O O O - -
SP | O O O - O
When a payload is not included, the default values for the
information carried by it SHALL be used (when applicable). The
following table summarizes what messages may be included in a
specific message.
This Internet-Draft expires in May 2002.
Arkko, et al. [Page 37]
