draft-ietf-msec-mikey-00.txt   draft-ietf-msec-mikey-01.txt 
Internet Engineering Task Force J. Arkko Internet Engineering Task Force J. Arkko
MSEC Working Group E. Carrara MSEC Working Group E. Carrara
INTERNET-DRAFT F. Lindholm INTERNET-DRAFT F. Lindholm
Expires: May 2002 M. Naslund Expires: August 2002 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
November, 2001 February, 2002
MIKEY: Multimedia Internet KEYing MIKEY: Multimedia Internet KEYing
<draft-ietf-msec-mikey-00.txt> <draft-ietf-msec-mikey-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Work for securing real-time applications have started to appear. This Work for securing real-time applications have started to appear. This
has brought forward the need for a key management solution to support has brought forward the need for a key management solution to support
the security protocol. The key management has to fulfil requirements, the security protocol. The key management has to fulfil requirements,
which makes it suitable in the context of conversational multimedia which makes it suitable in the context of conversational multimedia
in a heterogeneous environment. in a heterogeneous environment.
This document describes a key management scheme that can be used for This document describes a key management scheme that can be used for
real-time applications (both for peer-to-peer communication and group real-time applications (both for peer-to-peer communication and group
communication), and shows how it may work together with protocols communication), and shows how it may work together with protocols
such as SIP and RTSP. such as SIP and RTSP. In particular, its use to support the Secure
Real-time Transport Protocol, [SRTP], is described in detail.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction..............................................3 1. Introduction..............................................3
1.1. Notational Conventions..................................3 1.1. Notational Conventions.................................. 4
1.2. Definitions.............................................3 1.2. Definitions............................................. 4
1.3. Abbreviations...........................................4 1.3. Abbreviations........................................... 5
1.4. Outline.................................................5 1.4. Outline.................................................5
2. Basic Overview............................................5 2. Basic Overview............................................ 6
2.1. Scenarios...............................................5 2.1. Scenarios............................................... 6
2.2. Design Goals............................................6 2.2. Design Goals............................................ 7
2.3. System Overview.........................................7 2.3. System Overview.........................................7
2.4. Existing solutions......................................8 2.4. Relation to GKMARCH..................................... 9
3. Basic Key Transport and Exchange Schemes..................8 2.5. Existing solutions...................................... 9
3.1. Pre-shared key..........................................8 3. Basic Key Transport and Exchange Schemes.................. 9
3.2. Public-key encryption...................................9 3.1. Pre-shared key..........................................10
3.3. Diffie-Hellman key exchange.............................10 3.2. Public-key encryption...................................10
4. Key Management............................................11 3.3. Diffie-Hellman key exchange.............................12
4.1. TEK and Verification key Calculation....................11 4. Key Management............................................14
4.1.1. Assumptions...........................................12 4.1. Key Calculation.........................................14
4.1.2. Notation..............................................12 4.1.1. Assumptions...........................................14
4.1.3. Description...........................................12 4.1.2. Notation..............................................14
4.2. Re-keying...............................................13 4.1.3. PRF Description.......................................15
5. Behavior and message handling.............................14 4.1.4. Generating TEK from PMK...............................15
5.1. General.................................................14 4.1.5. Generating keys from an envelope/pre-shared key.......16
5.1.1. Capability discovery..................................14 4.1.6. Generating KEK from a DH-key..........................16
5.1.2. Error handling........................................14 4.2 Pre-defined Transforms and Timestamp Formats.............16
5.2. Creating a message......................................14 4.2.1 Hash functions.........................................16
5.3. Parsing a message.......................................15 4.2.2 Pseudo random number generator and PRF.................16
5.4. Replay handling.........................................16 4.2.3 Key data transport encryption..........................17
5.5. Reliability.............................................17 4.2.4 MAC and Verification Message function..................17
6. SDP integration...........................................17 4.2.5 Envelope Key encryption................................17
7. Key management with SIP...................................18 4.2.6 Digital Signatures.....................................17
7.1. Integration.............................................18 4.2.7 Diffie-Hellman Groups..................................17
7.2. Re-keying...............................................18 4.2.8. Timestamps............................................17
8. Key management with RTSP..................................19 4.3. Policies................................................17
8.1. Integration.............................................19 4.4. Indexing the Data SA....................................18
8.2. Re-keying...............................................19 4.5. Re-keying and MCS updating..............................18
9. Groups....................................................19 5. Behavior and message handling.............................19
10. Security Considerations..................................21 5.1. General.................................................19
10.1. General................................................21 5.1.1. Capability discovery..................................19
10.2. Key lifetime...........................................22 5.1.2. Error handling........................................19
10.3. Timestamps.............................................22 5.2. Creating a message......................................19
10.4. Identity protection....................................23 5.3. Parsing a message.......................................21
10.5. Denial of Service......................................23 5.4. Replay handling.........................................21
11. Conclusions..............................................24 5.5. Reliability.............................................22
12. Acknowledgments..........................................24 6. Integration with session establishment protocols..........23
13. Author's Addresses.......................................24 6.1. SDP integration.........................................23
14. References...............................................25 6.2. MIKEY with SIP..........................................23
6.3. MIKEY with RTSP.........................................24
Appendix A - Payload Encoding................................27 6.4. MIKEY Interface.........................................25
A.1. Common header payload..................................27 7. Groups....................................................26
A.2. PS data payload........................................29 7.1. Simple one-to-"a few"...................................26
A.3. PK data payload........................................30 7.2. Small-size interactive group............................27
A.4. DH data payload........................................30 8. Security Considerations...................................27
A.5. Signature payload......................................31 8.1. General.................................................27
A.6. Timestamp payload......................................31 8.2. Key lifetime............................................28
A.7. ID payload / Certificate payload........................32 8.3. Timestamps..............................................29
A.8. Cert hash payload.......................................33 8.4. Identity protection.....................................30
A.9. Ver msg payload.........................................33 8.5. Denial of Service.......................................30
A.10. n_start/n_end/SPI payload..............................34 8.6. Session establishment...................................30
A.11. SP payload.............................................34 9. Conclusions...............................................30
A.12. Error payload..........................................36 10. Acknowledgments..........................................31
11. Author's Addresses.......................................31
12. References...............................................31
Appendix B. - Payload usage summary..........................36 Appendix A - Payload Encoding................................34
A.1. Common header payload...................................34
A.1.1. SRTP ID...............................................36
A.2. Key data transport payload..............................37
A.3. Envelope data payload...................................38
A.4. DH data payload.........................................38
A.5. Signature payload.......................................39
A.6. Timestamp payload.......................................40
A.7. ID payload / Certificate payload........................40
A.8. Cert hash payload.......................................41
A.9. Ver msg payload.........................................41
A.10. Security Policy payload................................42
A.10.1. SRTPbasic policy.....................................42
A.10.2. SRTPext policy.......................................44
A.10.3. Re-key policy........................................45
A.11. Rand payload...........................................46
A.12. Error payload..........................................46
A.13. Key data payload.......................................47
A.14. Key validity data .....................................48
Appendix B. - Payload usage summary..........................49
Revision History.............................................50
1. Introduction 1. Introduction
There has recently been work to define a security protocol for the There has recently been work to define a security protocol for the
protection of real-time applications running over RTP, [SRTP]. protection of real-time applications running over RTP, [SRTP].
However, a security protocol needs a key management solution to However, a security protocol needs a key management solution to
exchange keys, security parameters, etc. There are some fundamental exchange keys, security parameters, etc. There are some fundamental
properties that such a key management scheme has to fulfil with properties that such a key management scheme has to fulfil with
respect to the kind of real-time applications (streaming, unicast, respect to the kind of real-time applications (streaming, unicast,
groups, multicast, etc.) and to the heterogeneous nature of the groups, multicast, etc.) and to the heterogeneous nature of the
scenarios dealt with. [REQS] lists in detail requirements for key scenarios dealt with.
management to work for conversational multimedia in heterogeneous
environments.
Following the requirements derived in [REQS], we discuss here some This document describes a key management solution, that address
scenarios, and propose a key management solution. That is, the focus multimedia scenarios (e.g. SIP calls and RTSP sessions). The focus is
is on how to set up key management for secure multimedia sessions on how to set up key management for secure multimedia sessions such
such that requirements in a heterogeneous environment are fulfilled. that requirements in a heterogeneous environment are fulfilled.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119. this document are to be interpreted as described in RFC-2119.
1.2. Definitions 1.2. Definitions
Crypto Session: uni- or bi-directional data stream(s), protected by a 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 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 Crypto Session may contain two streams, an RTP stream and the
are both protected by a single instance of SRTP. corresponding RTCP as they are both protected by a single instance of
SRTP (i.e. they share key and some other parameters).
Crypto Session ID: unique identifier for the Crypto Session. Crypto Session ID: within an MCS unique identifier for the Crypto
Session.
Multimedia Crypto Session (MCS): collection of one or more Crypto Multimedia Crypto Session (MCS): collection of one or more Crypto
Sessions, which has a common Security Association and Pre-Master Key. Sessions, which has common Pre-Master Key and security parameters.
Multimedia Crypto Session ID: unique identifier for the MCS. Multimedia Crypto Session ID: unique identifier for the MCS.
Security Association (SA): collection of information needed to secure Security Association (SA): collection of information needed to secure
a Multimedia Crypto Session. a Multimedia Crypto Session.
Pre-Master Key (PMK): a bit-string agreed upon by two or more Pre-Master Key (PMK): a bit-string agreed upon by two or more
parties, associated with a SA (and consequently MCS). From the pre- parties, associated with a SA (and consequently MCS). From the pre-
master key, Traffic-encrypting Keys can then be generated without master key, Traffic-encrypting Keys can then be generated without
need of further communication. need of further communication.
Traffic-encrypting Key (TEK): the key used by the security protocol Traffic-encrypting Key (TEK): the key used by the security protocol
to protect the crypto session (this key may be used directly by the 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 or may be used to derive further keys depending on
security protocol). The TEKs are derived from the MCS's PMK. the security protocol). The TEKs are derived from the MCS's PMK.
Key-encryption key (KEK): a key to be used to protect other keys that
are to be sent between the sender and the receiver.
PMK re-keying: the process of re-negotiating the PMK (and PMK re-keying: the process of re-negotiating the PMK (and
consequently future TEK(s)). consequently future TEK(s)).
Initiator: the initiator of the key management protocol, not Initiator: the initiator of the key management protocol, not
necessarily the initiator of the communication. necessarily the initiator of the communication.
Responder: the responder in the key management protocol. Responder: the responder in the key management protocol.
H(x): a cryptographic hash function with argument x H(x): a cryptographic hash function with argument x
Random(): a secure (pseudo-)random number generator
PRF(k,x): a keyed pseudo-random function
E(k,m): encryption of m with the key k E(k,m): encryption of m with the key k
D(k,m): decryption 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 Sign(k,m): the signature of message m with key k
PK_x: the public key of x PK_x: the public key of x
SK_x: the secret key of x SK_x: the secret key of x
Cert_x: Certificate of x Cert_x: Certificate of x
k_p: the PMK k_p: the PMK
[] an optional piece of information [] an optional piece of information
|| concatenation || concatenation
| logical OR | OR (selection operator)
^ binary exclusive OR ^ exponentiation
** exponentiation XOR binary exclusive or
Bit and byte ordering: throughout the document bits and bytes are as Bit and byte ordering: throughout the document bits and bytes are as
usual indexed from left to right, with the leftmost bits being the usual indexed from left to right, with the leftmost bits being the
most significant. most significant.
1.3. Abbreviations 1.3. Abbreviations
AES Advanced Encryption Standard AES Advanced Encryption Standard
CM Counter Mode CM Counter Mode
DH Diffie-Hellman DH Diffie-Hellman
DoS Denial of Service DoS Denial of Service
KEK Key-encrypting Key
MAC Message Authentication Code MAC Message Authentication Code
MIKEY Multimedia Internet KEYing MIKEY Multimedia Internet KEYing
OFB Output Feedback Mode
PK Public-Key PK Public-Key
PS Pre-Shared PMK Pre-Master key
PS Pre-Shared key
RTP Real-time Transport Protocol RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol RTSP Real Time Streaming Protocol
SDP Session Description Protocol SDP Session Description Protocol
SIP Session Initiation Protocol SIP Session Initiation Protocol
SRTP Secure RTP SRTP Secure RTP
TEK Traffic-encrypting key
1.4. Outline 1.4. Outline
Section 2 describes the basic scenario and the design goals that Section 2 describes the basic scenario and the design goals that
MIKEY are based on. It also gives a brief overview of the entire MIKEY are based on. It also gives a brief overview of the entire
solution. solution and its relation to the group key management architecture
[GKMARCH].
The basic key transport/exchange mechanisms are explained in detail The basic key transport/exchange mechanisms are explained in detail
in Section 3. The key derivation and re-keying procedures are in Section 3. The key derivation, re-keying, and other general key
described in Section 4. management procedures are described in Section 4.
Section 5 describes the expected behavior of the involved parties. Section 5 describes the expected behavior of the involved parties.
This also includes message creation and parsing. This also includes message creation and parsing.
As MIKEY may be carried in SDP over SIP and RTSP, Section 6-8 As MIKEY may be carried in SDP over SIP and RTSP, Section 6 describes
describes how to integrate and use MIKEY in these scenarios. how to integrate and use MIKEY in these scenarios.
Section 9 focuses on how MIKEY may be used in group scenarios. Section 7 focuses on how MIKEY is used in group scenarios.
The Security Considerations section (Section 10), gives a deeper The Security Considerations section (Section 8), gives a deeper
explanation on different security related topics. explanation on different security related topics.
All definitions of the payloads in MIKEY are described in Appendix A 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. and Appendix B includes a list of when the payloads MUST/MAY be used.
2. Basic Overview 2. Basic Overview
2.1. Scenarios 2.1. Scenarios
MIKEY is intended to be used for peer-to-peer, simple one-to-many, 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 and small-size (interactive) groups. One of the main multimedia
conversational multimedia scenario, where users may interact and scenarios is the conversational multimedia scenario, where users may
communicate in real-time. In these scenarios it can be expected that interact and communicate in real-time. In these scenarios it can be
peers set up multimedia sessions between each other, where a expected that peers set up multimedia sessions between each other,
multimedia session may consist of one or more multimedia streams where a multimedia session may consist of one or more multimedia
(e.g. SRTP streams). streams (e.g. SRTP streams).
We identify in the following some typical scenarios which involve the We identify in the following some typical scenarios which involve the
multimedia applications we are dealing with (see also Figure 1.1.). 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 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 parties where it may be desirable that the security is either set
each party sets up the security for its own outgoing streams. up by mutual agreement or that each party sets up the security for
its own outgoing streams.
b) many-to-many, without a centralized control unit, e.g. for small 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 groups where each party may set up the security for its own
outgoing media. outgoing media.
c) many-to-many, with a centralized control unit, e.g. for larger c) many-to-many, with a centralized control unit, e.g. for larger
groups with some kind of Group Controller that sets up the groups with some kind of Group Controller that sets up the
security. security.
d) simple one-to-many (multicast), e.g. real-time presentations, d) simple one-to-many (multicast), e.g. real-time presentations,
where the sender is in charge of setting up the security. where the sender is in charge of setting up the security.
The key management solutions may be different in the above scenarios.
MIKEY addresses the peer-to-peer case, one-to-many (one-to-"a few")
and small-size interactive groups.
peer-to-peer/ many-to-many many-to-many peer-to-peer/ many-to-many many-to-many
one-to-many (distributed) (centralized) one-to-many (distributed) (centralized)
++++ ++++ ++++ ++++ ++++ ++++ ++++ ++++ ++++ ++++
|. | |A | |B | |A |---- ----|B | |. | |A | |B | |A |---- ----|B |
--| ++++ | |----------| | | | \ / | | --| ++++ | |----------| | | | \ / | |
++++ / ++|. | ++++ ++++ ++++ (S) ++++ ++++ / ++|. | ++++ ++++ ++++ (S) ++++
|A |---------| ++++ \ / | |A |---------| ++++ \ / |
| | \ ++|B | \ / | | | \ ++|B | \ / |
++++ \-----| | \ ++++ / ++++ ++++ \-----| | \ ++++ / ++++
++++ \|C |/ |C | ++++ \|C |/ |C |
| | | | | | | |
++++ ++++ ++++ ++++
Figure 1.1: Examples of the four scenarios: peer-to-peer, one-to- 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 many, many-to-many without centralized server, and many-to-many with
a centralized server. 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 2.2. Design Goals
The goal has been to create a protocol that satisfies most of the The key management protocol is designed to have the following
requirements stated in [REQS]. The key management protocol is characteristics:
designed to have the following characteristics:
* End-to-end security. Only the participants have access to the * End-to-end security. Only the participants have access to the
generated key(s). generated key(s).
* Simplicity. * Simplicity.
* Efficiency. Designed to have: * Efficiency. Designed to have:
- low bandwidth consumption, - low bandwidth consumption,
- low computational workload, - low computational workload,
- small code size, and - small code size, and
- minimal number of round-trips. - minimal number of round-trips.
* Piggy backing. Possibility to piggy back MIKEY in session * Tunneling. Possibility to "tunnel" MIKEY in session establishment
establishment protocols (e.g. SIP and RTSP). protocols (e.g. SIP and RTSP).
* Independent of the security of the underlying transport. * Independent of specific security functionality of the underlying
transport.
2.3. System Overview 2.3. System Overview
One objective of MIKEY is to produce a traffic-encrypting key (TEK), One objective of MIKEY is to produce Data security protocol SA (Data
which then can be used as key input to a Security Protocol. SA), including a traffic-encrypting key (TEK), which then can be used
as key input to a Security Protocol. MIKEY can also be used to
distribute a Group Re-key SA, including a key-encrypting key (KEK). A
re-key SA can be used as input for an external group re-key protocol
(see also [GKMARCH] for more information about group re-keying).
The procedure of setting up a Crypto Session and creating a TEK, is The procedure of setting up a Multimedia Crypto Session (MCS) and
done in accordance to Figure 2.1.: creating a TEK (and Data SA), 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 1. A set of security parameters and Pre-Master Key(s) (PMK) are
alternative key transport/exchange mechanisms, see Section 4). created for the Multimedia Crypto Session (this is done by one of
2. The PMK is used to derive (in a cryptographically secure way) a the three alternative key transport/exchange mechanisms, see
Section 3).
2. The PMK(s) is used to derive (in a cryptographically secure way) a
TEK for each Crypto Session. TEK for each Crypto Session.
3. The TEK is used as the key input to the Security Protocol.
------------------- 3. The TEK, together with the security protocol parameters represent
| MCS | the Data SA, which is used as the input to the Security Protocol.
| Key transport |
| /exchange | +-----------------+
- - - - - - - - - - | MCS | +-----------------+
| SA | | Key transport | | External Group |
------------------- | /exchange |--> Re-key SA -->| Re-key protocol |
+-----------------+ +-----------------+
| : | :
| PMK : | PMK :
v : v :
------------ : +----------+ :
CS ID ->| TEK | : Security Protocol CS ID ->| TEK | : Security Protocol
|derivation| : Parameters |derivation| : Parameters
------------ : +----------+ :
| TEK : TEK | :
v v v v
Crypto Session Data SA
(Security Protocol) |
v
+-------------------+
| Crypto Session |
|(Security Protocol)|
+-------------------+
Figure 2.1. Overview of the key management procedure. Figure 2.1. Overview of the key management procedure.
The security protocol MAY then either use the TEK directly, or, if The security protocol MAY then either use the TEK directly, or, if
supported, derive further session keys from the TEK (e.g. see SRTP 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 [SRTP]). It is however up to the security protocol to define how the
TEK is used. TEK is used.
The re-keying procedure is managed by running the transport/exchange Re-keying may be done by an external group re-key protocol using a
phase once more to derive a new PMK (and consequently the TEKs). Re-key SA (in accordance to the group key management architecture
[GKMARCH]). However, a separate re-key protocol may be most useful
for large scale groups. MIKEY can be used to update the TEKs without
an external re-key protocol. This is then done by executing the
transport/exchange phase once again to derive a new PMK (and
consequently the TEKs).
2.4. Existing solutions 2.4. Relation to GKMARCH
The Group key management architecture (GKMARCH) [GKMARCH] describes a
general architecture for group key management protocols. MIKEY is a
part of this architecture, and can be used as a so called
Registration protocol. The main entities involved in the architecture
are a group controller/key server (GCKS), the receiver(s), and the
sender(s).
In MIKEY the GCKS and the sender can be viewed as the same entity,
which pushes down keys to the receiver. Note that e.g. in a SIP-
initiated call, the sender may also be a receiver. As MIKEY address
small interactive groups, a member may dynamically change between
being a sender and receiver (or being both).
2.5. Existing solutions
There is work done in IETF to develop key management schemes. For There is work done in IETF to develop key management schemes. For
example, IKE [IKE] is a widely accepted unicast scheme for IPsec, and example, IKE [IKE] is a widely accepted unicast scheme for IPsec, and
the MSEC WG is developing other schemes, addressed to group the MSEC WG is developing other schemes, addressed to group
communication [GDOI, GSAKMP]. For reasons discussed in Section 3 and communication [GDOI, GSAKMP]. For reasons discussed, there is however
in [REQS], there is however a need for a scheme more suitable for a need for a scheme more suitable for demanding cases such as real-
demanding cases such as real-time data over heterogeneous networks. time data over heterogeneous networks, and small interactive groups.
3. Basic Key Transport and Exchange Schemes 3. Basic Key Transport and Exchange Schemes
The following sections propose three different ways to transport/ The following sections define three different ways to transport/
exchange a Pre-Master Key: with the use of a pre-shared key, public- 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 key encryption, and Diffie-Hellman (DH) key exchange. The two first
methods we call key transport. In the following we assume unicast methods will be denoted key transport. In the following it is for
communication. simplicity assumed unicast communication. In addition to the PMK, a
random "nonce", denoted Rand, is also transported. In all three
cases, the PMK and Rand values are then used to derive TEKs as
described in Section 4.1.4.
Note that in the general keys for encryption and signing in general Note that in general, keys for encryption and signing should be
MUST be different, though for simplicity we use the same notation for different, though for simplicity we use the same notation for both.
both cases.
Note also that in the following protocol definitions, things like
security protocol parameters, headers etc., have intentionally been
left out. In practice, the messages sent are constructed by a set of
payloads (see Appendix A), wherein the different parameters may be
fitted. The signature/MAC is then computed over the entire message
(not only the specific values that are shown in the protocol
definition).
3.1. Pre-shared key 3.1. Pre-shared key
The pre-shared key case is done according to Figure 3.1. The Pre- The pre-shared key case is done according to Figure 3.1. One or more
Master Key (k_p) is randomly chosen by the initiator and then Pre-Master Keys (PMKs) are randomly and independently chosen by the
encrypted with the pre-shared key and sent to the responder. T is a initiator together with zero or one randomly and independently chosen
timestamp added by the Initiator to prevent replay attacks. The KEK. These are then encrypted with the pre-shared key and sent to the
entire message MUST be integrity protected by a Message responder. A random bit-string, Rand, is added together with a
Authentication Code (MAC). It is assumed that the pre-shared secret, timestamp, T. The entire message is integrity protected by a Message
s, consists of key material for both the encryption (encr_key) and Authentication Code (MAC).
the integrity protection (auth_key). The identity IDa MAY be sent to
correctly select the pre-shared key to be used. The pre-shared secret, s, is used to derive key material for both the
encryption (encr_key) and the integrity protection (auth_key) as
described in Section 4.1.5. The encryption and authentication
transforms are described in Section 4.2.
A B A B
Initialization:
Rand, PMKs, KEK = Random ()
encr_key, auth_key = PRF(s,...||Rand)
K = [IDa],T, E(encr_key,k_p) Protocol execution:
K = [IDa],T, Rand, E(encr_key,PMKs[||KEK])
A = MAC(auth_key,K) A = MAC(auth_key,K)
K, A K, A
--------------------- > ---------------------->
V=MAC(k_v,IDa||IDb||T),[IDb] auth_key = PRF(s,..||Rand)
V=MAC(auth_key,IDa||IDb||T),[IDb]
[V] [V]
<---------------------- <----------------------
Figure 3.1. Pre-shared key based transport mechanism. Figure 3.1. Pre-shared key based transport mechanism.
Authentication of the peers is provided by the MAC(s). The responder Authentication of the peers is provided by the MAC(s). The responder
MAY return (if requested by Initiator) the verification message, V, MAY return (if requested by Initiator) the verification message, V.
showing that it knows the PMK. The verification message is created by The verification message is created by applying the MAC function with
applying the MAC function with a verification key, k_v. The an authentication key on the IDs and timestamp.
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 As will be seen, the pre-shared case is, by far, the most efficient
handle the key transport due to the use of symmetric cryptography way to handle the key transport due to the use of symmetric
only. This approach has also the advantage that only a small amount cryptography only. This approach has also the advantage that only a
of data has to be exchanged. Of course, the problematic issue is small amount of data has to be exchanged. Of course, the problematic
scalability. issue is scalability.
3.2. Public-key encryption 3.2. Public-key encryption
Public-key cryptography can be used to create a scalable system. A Public-key cryptography can be used to create a scalable system. A
disadvantage with this approach is that it is more resource consuming disadvantage with this approach is that it is more resource consuming
than the pre-shared key approach. Another disadvantage is that in than the pre-shared key approach. Another disadvantage is that in
most cases a PKI (Public Key Infrastructure) is needed to handle the most cases a PKI (Public Key Infrastructure) is needed to handle the
distribution of public keys. distribution of public keys. Of course, it is possible to use public
keys as pre-shared keys (e.g. by using self-signed certificates).
A B A B
Initialization:
Rand, PMKs, KEK = Random ()
encr_key, auth_key = PRF(env_key,...||Rand)
Protocol execution:
I=(IDa|Cert_A) I=(IDa|Cert_A)
K=E(PK_b,k_p) O=E(encr_key,IDa||PMKs[||KEK])
|| T P=MAC(auth_key,O)
[|| I]
[|| H(Cert_B)] K=E(PK_b,env_key),
O, P, T, Rand
[, I]
[, H(Cert_B)]
S=Sign(SK_a,H(K)) S=Sign(SK_a,H(K))
K,S K,S
----------------------> ---------------------->
{retrieve env_key using SK_b}
V=MAC(k_v,IDa||IDb||T),[IDb] auth_key = PRF(env_key,...||Rand)
V=MAC(auth_key,IDa||IDb||T),[IDb]
[V] [V]
<---------------------- <----------------------
Figure 3.2. Key transport using public keys. Figure 3.2. Key transport using public keys.
The key transport mechanism is according to Figure 3.2. The initiator 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 encrypts one or more PMKs, the IDa, and optionally a KEK. The
responder's public key (which the initiator already has). The encrypted keys MUST also be integrity protected. The keys for
Initiator creates a message consisting of the encrypted k_p, a encryption (encr_key) of the keys and the MAC (auth_key) are derived
timestamp, and optionally its ID/Certificate and a hash of the from an "envelope" key (see Section 4.1.5). The envelope key is then
certificate used to encrypt k_p. The message is then signed and sent encrypted using the responder's public key (which the initiator
to the responder. already has). While any public key techniques could be used, proposed
encryption and signature transforms are described in Section 4.2. We
also refer to Section 4.2 for key-encryption algorithm and MAC
definitions.
The Initiator creates a message consisting of the encrypted PMKs and
KEK, a timestamp, a Rand, and optionally its ID/Certificate and a
hash of the certificate used to encrypt the envelope key. The entire
message is finally signed and sent to the responder.
As mentioned, the initiator MAY include a hash of the certificate of 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 the public key used to encrypt the envelope key, env_key. The
key corresponding to the specified certificate to decrypt the responder MUST then use the private key corresponding to the
encrypted PMK. specified certificate to decrypt the encrypted envelope key.
The responder MAY send a verification message, V, (as in the pre- The responder MAY send a verification message, V, (as in the pre-
shared case) to the initiator, which proves that the responder has shared case) to the initiator. This message uses a MAC (e.g. HMAC),
received the PMK correctly. This message uses a MAC (e.g. HMAC), with with an authentication key, derived from the PMK according to Section
a verification key k_v, which is derived from the PMK according to 4.1.4.
Section 4.1.
Certificate handling is in general complex; the scheme shown here is It is possible to cache the envelope key, so that it can be used as a
not the only one possible. For example, it is possible for B to fetch pre-shared key. It is not recommended that this key should be cached
A's certificate via other means. Verification of certificate against indefinitely (however it is up to the local policy to decide this).
Revocation Lists is not treated here, but may add extra delay. This function may be very convenient during a Multimedia Crypto
Session, if a new crypto session needs to be added (or an old on
removed). Then, the pre-shared key can be used, instead of the public
keys (see also Section 4.5.).
Certificate handling may involve a number of additional tasks not Certificate handling may involve a number of additional tasks not
shown here, and effect the inclusion of certain parts of the message. shown here, and effect the inclusion of certain parts of the message.
The following observations can, however, be made: The following observations can, however, be made:
- A typically has to find the certificate of B in order to send the - party A typically has to find the certificate of B in order to
first message. If A doesn't have B's certificate already, this send the first message. If A doesn't have B's certificate
may involve one or more roundtrips to a central directory agent. 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 - it will be possible for A to omit its own certificate and rely on
B getting this certificate using other means. However, we B getting this certificate using other means. However, we
recommend doing this, only when it is reasonable to assume that recommend doing this, only when it is reasonable to assume that
B can be expected to have cached the certificate from a previous B can be expected to have cached the certificate from a previous
connection. Otherwise accessing the certificate would mean connection. Otherwise accessing the certificate would mean
additional roundtrips for B as well. additional roundtrips for B as well.
- verification of the certificates using Certificate Revocation - verification of the certificates using Certificate Revocation
Lists (CRLs) or an on-line verification protocol may mean Lists (CRLs) or an on-line verification protocol may mean
additional roundtrips for both parties. If a small number of additional roundtrips for both parties. If a small number of
roundtrips is required for acceptable performance, it may be roundtrips is required for acceptable performance, it may be
necessary to omit some of these checks. necessary to omit some of these checks.
3.3. Diffie-Hellman key exchange 3.3. Diffie-Hellman key exchange
The possibility of using a Diffie-Hellman (DH) key exchange method is The possibility of using a Diffie-Hellman (DH) key exchange method is
also offered. Though, this approach in general has a higher resource also offered. Though, this approach in general has a higher resource
consumption (both computationally and in bandwidth) than the previous consumption (both computationally and in bandwidth) than the previous
ones. ones. With this method only one key is created, i.e. the DH-key. This
may then be used either as a PMK or (indirectly) as a KEK.
For a fixed, agreed upon, group, (G,*), for g in G and a natural 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 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 parameters are given in Section 4.2.7. The other transforms below are
group MUST have a size of at least two to the power of the desired described in Section 4.2.
PMK size.
A B A B
Initialization:
Rand, x = Random () y = Random ()
Protocol execution:
I = (IDa|Cert_A) I = (IDa|Cert_A)
K = g**x || T [|| I] K = g^x, T, Rand [,I]
S = Sign (SK_a,H(K)) S = Sign (SK_a,H(K))
K,S I' = (IDb|Cert_B) K,S I' = (IDb|Cert_B)
----------------------> K' = g**y || T [|| I'] -----------------> K' = g^y,T,IDa,g^x [,I']
S' = Sign (SK_b,H(K')) S' = Sign (SK_b,H(K'))
K',S' K',S'
<---------------------- <-----------------
k_p= g**(xy) k_p=g**(xy) PMK=g^(xy) PMK=g^(xy)
Figure 3.3. Diffie-Hellman key based exchange, where x and y are Figure 3.3. Diffie-Hellman key based exchange, where x and y are
randomly chosen respectively by A and B. randomly chosen respectively by A and B.
The key exchange is done according to Figure 3.3. The initiator 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 chooses a random value x, and sends a signed message including g^x, a
and a timestamp to the responder (optionally also including its Rand, and a timestamp to the responder (optionally also including its
certificate or identity). certificate or identity).
The group parameters (e.g., the group G) are a set of parameters The group parameters (e.g., the group G) are a set of parameters
chosen by the initiator. The responder chooses a random positive chosen by the initiator. The responder chooses a random positive
integer y, and sends a signed message including g**y and the integer y, and sends a signed message including g^y and the timestamp
timestamp to the initiator (optionally also providing its to the initiator (optionally also providing its certificate). The
certificate). signature must also cover the Initiator's id and the g^x value.
Both parties then calculate the PMK, g**(xy).
The authentication is due to the signing of the DH key, and is Both parties then calculate the PMK, g^(xy). The authentication is
due to the signing of the DH values (and identities), and is
necessary to avoid man-in-the-middle attacks. necessary to avoid man-in-the-middle attacks.
Note that this approach does not require that the initiator has to Note that this approach does not require that the initiator has to
posses any of the responder's certificate before the setup. Instead, posses any of the responder's certificate before the setup. Instead,
it is sufficient that the responder includes it's signing certificate it is sufficient that the responder includes it's signing certificate
in the response. in the response.
This approach is the most expensive approach. It requires first of This approach is the most expensive approach. It requires that both
all, that both sides compute one signature, then one verification and sides compute one signature, one verification and two DH-
finally two exponentiations. exponentiations.
4. Key Management 4. Key Management
4.1. TEK and Verification key Calculation 4.1. Key Calculation
We define in the following a method to derive a Verification key and We define in the following a general method (pseudo random function)
TEKs from the PMK. to derive one or more keys from a "master" key. This method should be
used to derive:
* TEKs from a PMK and the Rand,
* a KEK from the DH-key and the Rand,
* encryption, authentication, or salting key from a pre-shared/
envelope key and the Rand.
4.1.1. Assumptions 4.1.1. Assumptions
We assume that the following parameters are in place (to be exchanged We assume that the following parameters are in place (to be exchanged
as security parameters, in connection to the actual key exchange): as security parameters, in connection to the actual key exchange):
k_p: the PMK, which MUST be random and kept secret. PMK: a Pre-Master Key, which MUST be random and kept secret. Note
that there may be more than one PMK transported.
The following parameter MAY be sent in the clear: The following parameter MAY be sent in the clear:
mcs_id: Master Crypto Session ID mcs_id: Master Crypto Session ID (32-bits unsigned integer)
cs_id: the Crypto Session ID (8-bits unsigned integer)
Rand: An (at least) 128-bit random bit-string sent by the
Initiator.
cs_id: the Crypto Session ID The key derivation method has the following input parameters:
pmk_len: the length of the PMK. inkey: the input key to the derivation function.
inkey_len: the length in bits of the input key.
seed: a specific seed, dependent on the type of the key to be
derived, the Rand, and the session IDs.
outkey_len: desired length in bits of the output key.
tek_len: desired TEK length for the security protocol. The key derivation method has the following output:
outkey: the output key.
4.1.2. Notation 4.1.2. Notation
Let HMAC be the SHA1 based message authentication function, see Let HMAC be the SHA1 based message authentication function, see
[HMAC,SHA1]. Similar to [TLS], define: [HMAC,SHA1]. Similar to [TLS], define:
P (s, seed, m) = HMAC (s, A_1 || seed) || P (s, seed, m) = HMAC (s, A_1 || seed) ||
HMAC (s, A_2 || seed) || ... HMAC (s, A_2 || seed) || ...
HMAC (s, A_m || seed) HMAC (s, A_m || seed)
where where
A_0 = seed, A_0 = seed,
A_i = HMAC (s, A_(i-1)). A_i = HMAC (s, A_(i-1)).
4.1.3. Description While this is the default, HMAC using other hash function MAY be
used, see Section 4.2.1.
The following procedure is applied to compute the TEK: 4.1.3. PRF Description
* let n = pmk_len / 512, rounded up to the nearest integer The following procedure describes a pseudo-random function, denoted
* split the pre-master key into n blocks, k_p = s_1 || ... || s_n, PRF(inkey,seed), applied to compute the output key, outkey:
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 * let n = inkey_len / 512, rounded up to the nearest integer
* split the inkey into n blocks, inkey = s_1 || ... || s_n, where all
s_i, except possibly s_n, are 512 bits each
* let m = outkey_len / 160, rounded up to the nearest integer
P (s_1, seed, m) ^ P (s_2, seed, m) ^ ... ^ P (s_n, seed, m). (If another hash function than SHA1 is used, "512" and "160" MUST be
replaced by the appropriate input/output block-sizes of that
function.)
The procedure of generating the Verification key, k_v, is the same, Then, the output key, outkey, is obtained as the outkey_len most
replacing the constant string "MIKEYtek" by the constant string significant bits of
"MIKEYver", and cs_id by 0. (This gives a verification key of length
equal to tek_len). PRF(inkey,seed) = P(s_1,seed,m) XOR P(s_2,seed,m) XOR ...
XOR P(s_n,seed,m).
4.1.4. Generating TEK from PMK
The key derivation method should be executed with the following
parameters:
inkey: PMK
seed: 0x2AD01C64 || cs_id || mcs_id || Rand
outkey_len: length of the output TEK.
Note, the cs_id is the id of the cs_id the TEK is supposed to be
derived for.
If the security protocol does not support key derivation for If the security protocol does not support key derivation for
authentication and encryption itself from the TEK, authentication and authentication and encryption itself from the TEK, separate
encryption keys MAY directly be created for the security protocol by authentication and encryption keys MAY directly be created for the
replacing "MIKEYtek" with "MIKEYaut" and "MIKEYenc" respectively, and security protocol by replacing 0x2AD01C64 with 0x1B5C7973 and
tek_len by the desired key-length(s) in each case. 0x15798CEF respectively, and outkey_len by the desired key-length(s)
in each case.
4.2. Re-keying Note that the 32-bit constant integers (i.e. 0x2AD01C64 and the once
replacing it) is taken from the decimal digits of e (i.e. 2.7182...),
and where each constant consist of nine decimals digits (e.g. the
first nine decimal digits 718281828 = 0x2AD01C64).
A PMK re-keying mechanism is necessary, e.g. when a key is 4.1.5. Generating keys from an envelope/pre-shared key
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 inkey: the envelope key or the pre-shared key
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: seed: 0x150533E1 || 0xFF || mcs_id || Rand (for encryption key)
or
0x2D22AC75 || 0xFF || mcs_id || Rand (for auth. key)
or
0x29B88916 || 0xFF || mcs_id || Rand (for salting key)
Encrypted PMK, or DH-values (depending on method). This is sent to be outkey_len: desired length of the authentication/encryption/salting
able to derive a new PMK and thereby new TEKs. key.
SPI is an identifier of the new k_p. This can only be used when it is 4.1.6. Generating KEK from a DH-key
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 inkey: DH-key
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 seed: 0x39A2C14B || 0xFF || mcs_id || Rand
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'. outkey_len: desired length of the KEK.
This does not mean that the protocol will be able to run forever (all
security protocols will 'exhaust' the TEK sooner or later). 4.2 Pre-defined Transforms and Timestamp Formats
This section identifies standard transforms for MIKEY. The following
transforms SHALL be used in the respective case. New transforms MAY
be added in the future. It is however recommended to be sparse with
extensions as it usually only creates interoperability problems
between old and newer versions.
4.2.1 Hash functions
MIKEY SHALL use one of the following hash function: SHA-1 (see
[SHA1], MD5 (see [MD5]), SHA256, SHA384, or SHA512 (see [SHA256] for
the last three). SHA-1 is default and the only mandatory to implement
and support.
4.2.2 Pseudo random number generator and PRF
A cryptographically secure pseudo random number generator MUST be
used for the generation of the keying material and nonces, e.g.
[BMGL].
For the key derivations, the PRF specified in Section 4.1. MUST be
supported. This PRF MAY be extended by using SHA-256 or SHA-512,
instead of SHA-1.
4.2.3 Key data transport encryption
The default and mandatory-to-support key transport encryption is AES
in counter mode, as defined in [SRTP, Section 4], using a key as
derived in Section 4.1.5, and using initialization vector
IV = [S XOR (0x0000 || MCS ID || T)] || 0x0000,
where S is a 112-bit salting key, also derived as in Section 4.1.5,
and where T is the timestamp.
Note: this restricts the maximum size of the transported key to 2^23
bits, which is still enough for all practical purposes.
4.2.4 MAC and Verification Message function
MIKEY SHALL use 160-bit authentication tags, generated by HMAC with
SHA-1 as the default and mandatory to implement method, see [HMAC].
Authentication keys SHALL be derived according to Section 4.1.5.
4.2.5 Envelope Key encryption
When RSA is used for the envelope encryption, MIKEY SHALL use
RSA/PKCS#1, see [PKCS1].
4.2.6 Digital Signatures
When RSA is used for the signatures, MIKEY SHALL use RSA/PKCS#1, see
[PKCS1]. The default hash function SHALL be SHA-1.
4.2.7 Diffie-Hellman Groups
Diffie-Hellman key exchange SHALL use one of the groups: OAKLEY 5,
OAKLEY 1, or, OAKLEY 2, see [OAKLEY], where OAKLEY 5 is default and
mandatory to support.
4.2.8. Timestamps
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 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 UTC.
4.3. Policies
Included in the message exchange, policies for the Data security
protocol and/or the re-key protocol are transmitted. The policies are
defined in a separate payload and are specific to the security/re-key
protocol (see also Appendix A.10.). Together with the keys, the
validity period of theses SHOULD also be specified. This could either
be done with an SPI (e.g. when a re-key protocol is used) or with an
Interval (e.g. a sequence number interval for SRTP). Whether an SPI
or an Interval should be used, depends on the security protocol (or
re-key protocol).
4.4. Indexing the Data SA
The indexing of a Data SA will depend on the security protocol as
different security protocols will have different characteristics. For
SRTP the SSRC (see [SRTP]) is one of those. However, the SSRC is not
sufficient. For the local lookup in the MIKEY SA data base, it is
RECOMMENDED that the MIKEY implementation support a lookup using
destination network address and port together with SSRC. Note that
MIKEY does not send network addresses or ports. One reason to this is
that they may not be known in advance, as well as if a NAT exists in-
between, problems may arise.
When SIP or RTSP is used, the local view of the destination address
and port can be obtained form either SIP or RTSP. MIKEY can then use
these addresses as the index for the Data SA lookup.
4.5. Re-keying and MCS updating
A 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. In accordance to the GKMARCH, MIKEY supports the
possibility to use an external group re-key protocol, by the re-key
SA. However, an external group re-key protocol may not be necessary
in a small group. Therefore, it is also possible to update the MCS
(e.g. a TEK or a crypto session parameter) by using MIKEY.
The updating of the MCS is performed by executing MIKEY again e.g.
before a TEK expires, or a new crypto session is added to the MCS.
When MIKEY is executed again to update the MCS, 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.
The new message exchange MUST use the same MCS ID as the initial
exchange, but a new timestamp. A new Rand MUST NOT be included in the
message exchange (the Rand will only have affect in the Initial
exchange). New Crypto Sessions may be added if desired in the update
message. Therefore, the new MIKEY message does not need to contain
keys.
As explained in Section 3.2., the envelope key may be "cached" as a
pre-shared key. If so, the "update message" SHOULD be a pre-shared
key message, not a public key message. If the public key message is
used, but the envelope key was not cached, the Initiator MUST provide
a new encrypted envelope key that can be used in the verification
message. However, the Initiator does not need to provide any other
keys.
A Multimedia Crypto Session MAY contain several Crypto Sessions. A A Multimedia Crypto Session MAY contain several Crypto Sessions. A
problem that then MAY occur is to synchronize the re-keying if an SPI 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 is not used. It is therefore recommended that an SPI is used, if more
identified from the MCS and the re-keying is done with respect to than one Crypto Session is used.
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.
5. Behavior and message handling 5. Behavior and message handling
Each message that is sent by the Initiator or the Responder, is built 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 by a set of payloads. This section describes how messages are created
and also when they can be used. and also when they can be used.
5.1. General 5.1. General
5.1.1. Capability Discovery 5.1.1. Capability Discovery
skipping to change at page 14, line 26 skipping to change at page 19, line 35
security algorithms etc. If the guess is wrong, then the responder security algorithms etc. If the guess is wrong, then the responder
may send back its own capabilities (negotiation) to let the initiator may send back its own capabilities (negotiation) to let the initiator
choose a common set of parameters. Multiple attributes may be choose a common set of parameters. Multiple attributes may be
provided in sequence. This is done to reduce the number of roundtrips provided in sequence. This is done to reduce the number of roundtrips
as much as possible. as much as possible.
If the responder is not willing/capable to provide security or the 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 parties simply cannot agree, it is up to the parties' policies how to
behave, i.e. accept an insecure communication or reject it. behave, i.e. accept an insecure communication or reject it.
Note that it is not the intention of this protocol to have a very
broad variety of options, as it is assumed that it should not be too
common that an offer is denied.
5.1.2. Error Handling 5.1.2. Error Handling
All errors due to the key management protocol SHOULD be reported to All errors due to the key management protocol SHOULD be reported to
the peer(s) by an error message. The Initiator SHOULD therefore the peer(s) by an error message. The Initiator SHOULD therefore
always be prepared to receive a response back from the responder. always be prepared to receive such message back from the responder.
If the responder does not support the set of parameters suggested by If the responder does not support the set of parameters suggested by
the initiator, the error message SHOULD include the supported the initiator, the error message SHOULD include the supported
parameters (see also Section 5.1.1.). parameters (see also Section 5.1.).
5.2. Creating a message 5.2. Creating a message
To create a MIKEY message, a Common header payload is first created. To create a MIKEY message, a Common header payload is first created.
This payload is then followed, depending on the message type, by a This payload is then followed, depending on the message type, by a
set of information payloads (e.g. DH-value payload, Signature set of information payloads (e.g. DH-value payload, Signature
payload, Security Protocol payload). The defined payloads and the payload, Security Protocol payload). The defined payloads and the
exact encoding of each payload are described in Appendix A. exact encoding of each payload are described in Appendix A.
1 2 3 1 2 3
skipping to change at page 15, line 11 skipping to change at page 20, line 26
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : : : :
: : : : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload x ... ! ! next payload ! Payload x ... !
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MAC/Signature payload ~ ! MAC/Signature ~
+ +
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.1. MIKEY payload example. Figure 5.1. MIKEY payload example.
The process of generating a message consists of the following steps: The process of generating a message consists of the following steps:
* Create a master payload starting with the Common header payload. * Create a master payload starting with the Common header payload.
* Concatenate necessary payloads to the master payload (Appendix B * Concatenate necessary payloads to the master payload (Appendix B
lists what payloads MUST/MAY be used for the different messages). lists which payloads MUST/MAY be used for the different messages).
* As a last step (for messages that must be authenticated), * As a last step (for messages that must be authenticated, this also
concatenate the payload containing the MAC/signature, where the include the verification message), concatenate the payload
MAC/signature field is initiated with zeros. containing the MAC/signature, where the MAC/signature field is
initiated with zeros.
* Calculate the MAC/signature over the entire master payload and * Calculate the MAC/signature over the entire master payload and
update the MAC/signature field with the MAC/signature. update the MAC/signature field with the MAC/signature. In the case
of the verification message, the IDa || IDb || T MUST follow
directly after the master payload in the MAC calculation.
Note that all messages from the Initiator MUST use a new timestamp!
5.3. Parsing a message 5.3. Parsing a message
In general, parsing is done by extracting payload by payload and In general, parsing is done by extracting payload by payload and
checking that no errors occur (the exact procedure is implementation checking that no errors occur (the exact procedure is implementation
specific). However, for the Responder, it is recommended that the specific). However, for the Responder, it is recommended that the
following procedure is followed: following procedure is followed:
* Extract the Timestamp and check that it is within the allowable * Extract the Timestamp and check that it is within the allowable
clock skew. Also check the replay cache so that the message is not clock skew. Also check the replay cache so that the message is not
replayed (see also Section 5.4). replayed (see also Section 5.4).
* Extract ID and authentication algorithm (if not included, assume * Extract ID and authentication algorithm (if not included, assume
default one). default one).
* Verify the MAC/signature. * Verify the MAC/signature.
* If the authentication is NOT successful, an Auth failure Error * If the authentication is NOT successful, an Auth failure Error
message MUST be sent to the initiator. message MUST be sent to the initiator (if SIP is used, this should
be signaled to SIP as a rejection of the offer). The message MUST
then be discarded from further processing, and the event SHOULD be
logged.
* If the authentication is successful, the message SHOULD be * If the authentication is successful, the message SHOULD be
processed. Though how it is processed is implementation specific. processed. Though how it is processed is implementation specific.
* If any unsupported parameters or errors occur during the * If any unsupported parameters or errors occur during the
processing, these SHOULD be reported to the Initiator by sending an processing, these SHOULD be reported to the Initiator by sending an
error message. The processing SHOULD then be aborted. The error error message. The processing SHOULD then be aborted. The error
message MAY also include payloads to describe the supported message MAY also include payloads to describe the supported
parameters. parameters. If SIP is used, this should be signaled to SIP as a
rejection of the offer (see also Section 6.2.).
* If needed, a response message is created and sent to the Initiator. * If needed, a verification/response message is created and sent to
the Initiator.
5.4. Replay handling 5.4. Replay handling
* Each Responder MUST utilize a replay cache in order to remember the * Each Responder MUST utilize a replay cache in order to remember the
messages presented within the allowable clock skew (see also messages presented within the allowable clock skew (see also
Section 10.3. for timestamp considerations). Section 8.3., timestamp considerations).
* Replayed messages MUST NOT be processed.
* A message SHOULD be deleted from the cache when it is outdated with * A message SHOULD be deleted from the cache when it is outdated with
respect to the clock skew. respect to the clock skew.
* Due to physical limitations, the replay cache SHOULD be set to * Due to physical limitations, the replay cache SHOULD be set to
store up to a maximum number of messages (see below for more store up to a maximum number of messages (see below for more
details). details).
* If the host loses track of the incoming requests (e.g. due to * If the host loses track of the incoming requests (e.g. due to
overload), it must reject all incoming requests until the clock overload), it MUST reject all incoming requests until the clock
skew interval has passed. skew interval has passed.
For a client, the maximum number of messages it will recall may vary 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 depending on the capacity of the client itself and the network, but
also the number of expected messages should be taken into account. also the number of expected messages should be taken into account.
The following is a recommendation of how the maximum size of the The following is a recommendation of how the maximum size of the
replay cache may be calculated: replay cache may be calculated:
maxsize = Min (A, e*x) * block_size maxsize = Min (A, e*x) * block_size
where where
A: maximum memory blocks possible to allocate (for simplicity: 1 A: maximum memory blocks possible to allocate (for simplicity: 1
memory block can contain the information from one message) memory block can contain the information from one message)
e: fault-tolerant value (MUST be >1) e: fault-tolerance value (MUST be >1)
x: #max expected messages per "clock skew" x: #max expected messages per "clock skew"
block_size: size of the message to be cached (note that it will 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 probably not be needed to cache the entire message, instead a hash of
the message and the timestamp might be enough). the message and the timestamp might be enough).
In case of a DoS attack, the client will in most cases be able to 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 handle the replay cache. A bigger problem will probably be to process
the messages (verify signatures/MACs), due to the computational the messages (verify signatures/MACs), due to the computational
skipping to change at page 17, line 21 skipping to change at page 23, line 5
The transmitting entity (initiator or responder) MUST: The transmitting entity (initiator or responder) MUST:
* Set a timer and initialize a retry counter * Set a timer and initialize a retry counter
* If the timer expires, the message is resent and the retry counter * If the timer expires, the message is resent and the retry counter
is decreased. is decreased.
* If the retry counter reaches zero (0), the event MAY be logged in * If the retry counter reaches zero (0), the event MAY be logged in
the appropriate system audit file the appropriate system audit file
6. SDP integration 6. Integration with session establishment protocols
This section describes how MIKEY should be integrated with SDP, SIP
and RTSP. It is based on [KMASDP], which describes extensions to SDP
and SIP to carry key management protocol MUST information.
6.1. SDP integration
SDP descriptions [SDP] can be carried by several protocols, such as 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 SIP and RTSP. Both SIP and RTSP often use SDP to describe the media
to piggy-back it in other protocols (such as SIP and RTSP). Both SIP sessions. Therefore, it is also convenient to be able to integrate
and RTSP often uses SDP to describe the media sessions. Therefore, it the key management in the session description it is supposed to
is also convenient to be able to integrate the key management in the protect. [KMASDP] describes attributes that SHOULD be used by a key
session description it is supposed to protect. [KMASDP] describes management protocol that is integrated in SDP. The following two SDP
attributes that SHOULD be used by a key management protocol that is attributes MUST be used by MIKEY.
integrated in SDP. The following two SDP attributes MUST be used by
MIKEY.
a=keymgmt-prot:<protocol> a=keymgmt-prot:<protocol>
a=keymgmt-data:<data> a=keymgmt-data:<data>
The keymgmt-prot attribute indicates the key management protocol. The keymgmt-prot attribute indicates the key management protocol.
Therefore, it MUST be set to "MIKEY", i.e. Therefore, it MUST be set to "MIKEY", i.e.
a=keymgmt-prot:MIKEY a=keymgmt-prot:MIKEY
The data part is used to transport the actual key management payload 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 message. Due to the text based nature of SDP, this part MUST be
base64 encoded to avoid illegal characters. base64 encoded to avoid illegal characters but in the same time
avoiding a too large message expansion.
a=keymgmt-data:<base64 encoded data> a=keymgmt-data:<base64 encoded data>
Example Example
| a=keymgmt-prot:MIKEY | a=keymgmt-prot:MIKEY
| a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD...
MCS < CS 1 < m=audio 49000 RTP/SAVP 98 MCS < CS 1 < m=audio 49000 RTP/SAVP 98
| a=rtpmap:98 AMR/8000 | a=rtpmap:98 AMR/8000
| CS 2 < m=video 2232 RTP/SAVP 31 | CS 2 < m=video 2232 RTP/SAVP 31
skipping to change at page 18, line 4 skipping to change at page 23, line 43
a=keymgmt-data:<base64 encoded data> a=keymgmt-data:<base64 encoded data>
Example Example
| a=keymgmt-prot:MIKEY | a=keymgmt-prot:MIKEY
| a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD...
MCS < CS 1 < m=audio 49000 RTP/SAVP 98 MCS < CS 1 < m=audio 49000 RTP/SAVP 98
| a=rtpmap:98 AMR/8000 | a=rtpmap:98 AMR/8000
| CS 2 < m=video 2232 RTP/SAVP 31 | CS 2 < m=video 2232 RTP/SAVP 31
In this example the multimedia crypto session consists of two crypto In this example the multimedia crypto session consists of two crypto
sessions (one audio stream and one video stream). sessions (one audio stream and one video stream) to be protected by
SRTP (as indicated by the "RTP/SAVP" profile).
7. Key management with SIP 6.2. MIKEY with SIP
In a basic SIP call between two parties (see Figure 7.1.), SIP In a basic SIP call between two parties (see Figure 6.1.), SIP
(Session Initiation Protocol, [SIP]) is used as a session (Session Initiation Protocol, [SIP]) is used as a session
establishment protocol between a caller A and a callee B. establishment protocol between two or more parties. In general an
offer is made, whereby it is either accepted or rejected by the
answerer. SIP complies to the offer/answer model [OFFANS], to which
MIKEY over SIP MUST be compliant with as well.
--------- ---------
|A's SIP| <.......> |B's SIP| |A's SIP| <.......> |B's SIP|
|Server | SIP |Server | |Server | SIP |Server |
--------- --------- --------- ---------
^ ^ ^ ^
. . . .
++++ SIP . . SIP ++++ ++++ SIP . . SIP ++++
| | <............. ..............> | | | | <............. ..............> | |
| | | | | | | |
++++ <-------------------------------------------> ++++ ++++ <-------------------------------------------> ++++
SRTP SRTP
Fig 7.1.: SIP-based call example. The two parties uses SIP to set up Fig 6.1.: SIP-based call example. The two parties uses SIP to set up
an SRTP stream between A and B. an SRTP stream between A and B.
7.1. Integration The SIP offerer will be the MIKEY Initiator and the SIP answerer will
be the MIKEY responder. This implies that in the offer, the MIKEY
SIP may carry SDP descriptions, since the participants negotiate the Initiator message SHOULD be included, and in the answer to the offer,
media encoding etc. Therefore, the SDP attributes previously the MIKEY Responder message SHOULD be included.
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. If the MIKEY part of the offer is not accepted, a MIKEY error message
However, unless the initiator's identity can be derived from SIP SHOULD be provided in the answer (following Section 5.1.). MIKEY MUST
itself, the initiator (caller) MUST provide the identity to the always signal to SIP whether the MIKEY message was an acceptable
callee. It is recommended to use the same identity for both SIP and offer or not.
MIKEY.
7.2. Re-keying It may be assumed that the offerer knows the identity of the
answerer. 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.
A re-keying mechanism is necessary, e.g. when the key is compromised Updating of the MCS (e.g. TEK update) SHOULD only be seen as a new
or simply because it has a restricted lifetime. When SIP is used as offer. Note that it might not be necessary to send all information,
the session establishment protocol, a re-INVITE can be issued such as the certificate, due to the already established call (see
carrying SDP with the MIKEY data (this is sent by the Initiator of also Section 4.5.).
MIKEY). Note that it might not be necessary to send all information,
such as the certificate, due to the already established call.
8. Key management with RTSP 6.3. MIKEY with RTSP
The Real Time Streaming Protocol (RTSP) [RTSP] is used to control The Real Time Streaming Protocol (RTSP) [RTSP] is used to control
media streaming from a server. The media session is typically media streaming from a server. The media session is typically
obtained via an SDP description, received by a DESCRIBE message, or 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 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 RTSP messages which does not contain an SDP description, the RTSP
header (defined in [KMASDP]) is used. KeyMgmt header (defined in [KMASDP]) is used. This header includes
basically the same fields as the SDP extensions.
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 In an RTSP scenario, the RTSP server and initiator will be the same
message from the client to the server. Note that the SETUP message entity. The Initiator/RTSP server includes the MIKEY message in a SDP
does not include a SDP description, why the RTSP KeyMgmt header description. When responding to this, the client uses the defined
(defined in [KMASDP]) MUST be used to pass the MIKEY message. RTSP header to send back the answer (included in the SETUP message).
Note that it is the server that will be the Initiator of MIKEY in 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 this case. This has some advantages. First, the server will always be
able to chose the key for the content it distributes, secondly, it 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 will then have the possibility to use the same key for the same
content that are streamed/sent to more than one client. content that are streamed/sent to more than one client.
8.2. Re-keying To be able to have a server initiated MCS update procedure, either
the ANNOUNCE message or the SET_PARAMETER message SHOULD be used to
send the updated MIKEY material. A disadvantage of using these, is
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).
To be able to have a server initiated re-keying procedure, either the 6.4. MIKEY Interface
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 The SDP, SIP, and RTSP processing is defined in [KMASDP]. However, it
is necessary that MIKEY can work properly with these protocols.
Therefore, the interface between MIKEY and these protocols MUST
provide certain functionality (however, exactly how the interface
looks like is very implementation dependent).
What has been discussed up to now can be extended from the unicast MIKEY MUST have an interface towards the SIP/SDP or RTSP/SDP
case to small-size groups and simple one-to-many scenarios. However, implementation that allows for:
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.
9.1. Simple one-to-many * MIKEY to receive information about the sessions negotiated. This is
to some extent implementation dependent. But it is recommended
that, in the case of SRTP streams, the number of SRTP streams are
included (and the direction of these). The destination addresses
and ports is also recommended to provide to MIKEY.
* MIKEY to receive incoming MIKEY messages. This MUST also include
the possibility to return the status of the incoming message to
SIP/SDP or to RTSP/SDP, i.e. whether the MIKEY message was accepted
or not.
* SIP/SDP or RTSP/SDP to receive information from MIKEY, this include
the receiving the MCS ID, receiving the SSRCs for SRTP. It is also
RECOMMENDED that extra information about errors can be received.
* SIP/SDP or RTSP/SDP to receive outgoing MIKEY messages.
* tearing down a MIKEY MCS (e.g. if the SIP sessions is shutdown, the
MCS SHOULD also be shutdown)
Note that if a MCS has already been established, it is still valid
for the SIP/SDP or RSP/SDP implementation to request a new message
from MIKEY, e.g. when a new offer is issued. MIKEY SHOULD then send
an update message to the Responder (see also Section 4.5).
7. Groups
What has been discussed up to now is not limited to single peer-to-
peer communication, but can be used in small-size groups and simple
one-to-many scenarios. This section describes how MIKEY is used in a
group scenario.
7.1. Simple one-to-"a few"
++++ ++++
|S | |S |
| | | |
++++ ++++
| |
--------+-------------- - - --------+-------------- - -
| | | | | |
v v v v v v
++++ ++++ ++++ ++++ ++++ ++++
|A | |B | |C | |A | |B | |C |
| | | | | | | | | | | |
++++ ++++ ++++ ++++ ++++ ++++
Figure 9.1. Simple one-to-many scenario. Figure 7.1. Simple one-to-many/"a few" scenario.
In the most simple one-to-many scenario, where a server is streaming In the most simple one-to-many/"a few" scenario, a server is
to a small group of clients. In this scenario RTSP or SIP could be streaming to a small group of clients. In this scenario RTSP or SIP
used for the registration and the key management set up. The server could be used for the registration and the key management set up. The
would then act as the Initiator of MIKEY (see also Section 8.). In streaming server would act as the Initiator of MIKEY. In this
this scenario the pre-shared key or public key transport mechanism scenario the pre-shared key or public key transport mechanism will be
would be appropriate to use to transport the same PMK to all the appropriate to use to transport the same PMK to all the clients
clients (which will result in common TEKs for the group). (which will result in common TEKs for the group).
However, as the group increases in size, scalability and management Note, if the same PMK/TEK(s) should be used by all the group members,
problems may arise. The Group Key Management Architecture [GARCH] the streaming server MUST specify the same MCS_ID and CS_ID(s) for
describes a scalable architecture of handling this scenario. The the session to all the group members. Security considerations arising
architecture can be used as a base for how MIKEY should be used in from using the same key for several streams in the underlying
order to handle scalable groups. Some minor extensions to MIKEY will security protocol MUST be considered.
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 7.2. Small-size interactive group
++++ ++++ ++++ ++++
|A | -------> |B | |A | -------> |B |
| | <------- | | | | <------- | |
++++ ++++ ++++ ++++
^ | | ^ ^ | | ^
| | | | | | | |
| | ++++ | | | | ++++ | |
| --->|C |<--- | | --->|C |<--- |
------| |------ ------| |------
++++ ++++
Figure 9.2. Small-size group without centralized controller. Figure 7.2. Small-size group without centralized controller.
As described in the overview section, for small-size groups one may 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 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 for its outgoing streams. In these scenarios, the pre-shared key and
the public-key transport methods should be used. the public-key transport methods will be used.
One scenario may then be that the client sets up a three-part call, 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 using SIP. Due to the small size of the group, unicast SRTP is used
the clients. Each client may set up the security for its outgoing between the clients. Each client may set up the security for its
streams to the others. A scenario like this would not require any outgoing stream(s) to the others.
modifications neither to MIKEY nor SIP/SDP.
10. Security Considerations As for the one-to-"a few" case, the streaming client MUST specify the
same MCS_ID and CS_ID(s) for its outgoing sessions if the same
PMK/TEK(s) should be used for all the group members. The same
security considerations for key-sharing also apply.
10.1. General 8. Security Considerations
8.1. General
No chain is stronger than its weakest link. The cryptographic No chain is stronger than its weakest link. The cryptographic
functions protecting the keys during transport/exchange SHOULD offer functions protecting the keys during transport/exchange SHOULD offer
a security at least corresponding to the (symmetric) keys they a security at least corresponding to the (symmetric) keys they
protect. For instance, with current state of the art, see [LV], 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 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- 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", 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- leading to unnecessary time delays. Therefore, key size for the key-
exchange mechanism SHOULD be weighed against the size of the exchange mechanism SHOULD be weighed against the size of the
skipping to change at page 22, line 5 skipping to change at page 28, line 23
In a Multimedia Crypto Session, the Crypto Sessions (audio, video In a Multimedia Crypto Session, the Crypto Sessions (audio, video
etc) share the same PMK as discussed earlier. From a security point 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 of view, the criterion to be satisfied is that the encryption of the
individual Crypto Sessions are performed "independently". In MIKEY individual Crypto Sessions are performed "independently". In MIKEY
this is accomplished by having unique Crypto Session identifiers (see this is accomplished by having unique Crypto Session identifiers (see
also Section 4.1.). The TEK derivation method assures this by also Section 4.1.). The TEK derivation method assures this by
providing cryptographically independent TEKs to distinct Crypto providing cryptographically independent TEKs to distinct Crypto
Sessions (within the Multimedia Crypto Session), regardless of the Sessions (within the Multimedia Crypto Session), regardless of the
security protocol used. security protocol used.
Specifically, the TEK key derivation is implemented by a pseudo- Specifically, the key derivations are implemented by a pseudo-random
random function. The one used here is a simplified version of that function. The one used here is a simplified version of that used in
used in TLS [TLS]. Here, we use only one single hash function, TLS [TLS]. Here, we use only one single hash function, whereas TLS
whereas TLS uses two different functions, motivated by the risk of uses two different functions. Note that the use of the Rand nonce in
one of the hashes being broken. We motivate our simplification by the the key derivation is essential to protect against off-line time/
observation that if a single widely used hash, e.g. SHA1, is broken, memory trade-off attacks.
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 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 a single party (initiator). This makes MIKEY more sensitive if the
initiator uses a bad random number generator. It should also be noted initiator uses a bad random number generator. It should also be noted
that neither the pre-shared nor the public-key scheme provides that neither the pre-shared nor the public-key scheme provides
perfect forward secrecy. If mutual contribution or perfect forward perfect forward secrecy. If mutual contribution or perfect forward
secrecy is desired, the Diffie-Hellman scheme MUST be used. secrecy is desired, the Diffie-Hellman scheme MUST be used.
Forward/backward security: if the PMK, k_p, is exposed, all TEKs Forward/backward security: if the PMK is exposed, all TEKs generated
generated from it are compromised. However, under the assumption that from it are compromised. However, under the assumption that the
the derivation function is a pseudo-random function, disclosure of an derivation function is a pseudo-random function, disclosure of an
individual TEK does not compromise other (previous or later) TEKs individual TEK does not compromise other (previous or later) TEKs
derived from the same PMK. derived from the same PMK.
10.2. Key lifetime 8.2. Key lifetime
Even if the lifetime of a PMK is not specified, it MUST be taken into Even if the lifetime of a PMK is not specified, it MUST be taken into
account that the encryption transform in the underlying security account that the encryption transform in the underlying security
protocol can in some way degenerate after a certain amount of protocol can in some way degenerate after a certain amount of
encrypted data. Each security protocol MUST define such maximum encrypted data. Each security protocol MUST define such maximum
amount and trigger a re-keying procedure before the 'exhaustion' of 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 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). SRTP 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 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 block cipher (in CBC mode, counter mode, or a feedback mode with full
b-bit feedback), degenerate behavior in the crypto stream, possibly b-bit feedback), degenerate behavior in the crypto stream, possibly
useful for an attacker, is expected to occur after a total of roughly useful for an attacker, is (with constant probability) expected to
2**(b/2) encrypted b-bit blocks (using random IVs). For some security occur after a total of roughly 2^(b/2) encrypted b-bit blocks (using
margin, re-keying SHOULD be triggered well in advance compared to the random IVs). For security margin, re-keying MUST be triggered well in
above bound. See [BDJR] for more details. advance compared to the above bound. See [BDJR] for more details.
For use of a dedicated stream cipher, we refer to the analysis and For use of a dedicated stream cipher, we refer to the analysis and
documentation of said cipher in each specific case. documentation of said cipher in each specific case.
10.3. Timestamps 8.3. Timestamps
The timestamp prevents against replay attacks under the following Timestamp usage prevents against replay attacks under the following
assumptions: assumptions:
* Each host MUST have a clock which is at least "loosely * Each host MUST have a clock which is at least "loosely
synchronized" to the time of the other hosts. synchronized" to the time of the other hosts.
* If the clocks are to be synchronized over the network, a secure * If the clocks are to be synchronized over the network, a secure
network clock synchronization protocol MUST be used. network clock synchronization protocol MUST be used.
In general, a client may not expect a very high load of incoming 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 messages and may therefore allow the degree of looseness to be on the
skipping to change at page 23, line 39 skipping to change at page 30, line 5
with respect to the usage scenario. with respect to the usage scenario.
The use of timestamps instead of challenge-response requires the The use of timestamps instead of challenge-response requires the
systems to have synchronized clocks. Of course, if two clients are systems to have synchronized clocks. Of course, if two clients are
not synchronized, they will have difficulties with setting up the not synchronized, they will have difficulties with setting up the
security. The current timestamp based solution has been selected to security. The current timestamp based solution has been selected to
allow a maximum of one round-trip (i.e. two messages), but still allow a maximum of one round-trip (i.e. two messages), but still
provide a reasonable replay protection. A (secure) challenge-response provide a reasonable replay protection. A (secure) challenge-response
based version would require at least three messages. based version would require at least three messages.
10.4. Identity protection 8.4. Identity protection
Identity protection was not a main design goal when designing MIKEY. Identity protection was not a main design goal for MIKEY. Such
Such feature would have added more complexity to the protocol and was feature will add more complexity to the protocol and was therefore
therefore chosen not to be included. As MIKEY is anyway proposed to chosen not to be included. As MIKEY is anyway proposed to be
be transported over e.g. SIP, the identity may be exposed by this. transported over e.g. SIP, the identity may be exposed by this.
However, if the transporting protocol is secured and also provides However, if the transporting protocol is secured and also provides
identity protection, MIKEY might inherit the same feature. How this identity protection, MIKEY might inherit the same feature. How this
should be done is for future study. should be done is for future study.
10.5. Denial of Service 8.5. Denial of Service
This protocol is resistant to Denial of Service attacks in the sense This protocol is resistant to Denial of Service attacks in the sense
that a responder does not construct any state (at the key management that a responder does not construct any state (at the key management
protocol level) before it has authenticated the initiator. However, protocol level) before it has authenticated the initiator. However,
this protocol, like many others, is open to attacks that use spoofed 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 IP addresses to create a large number of fake requests. This MAY be
solved by letting the protocol transporting MIKEY do an IP address solved by letting the protocol transporting MIKEY do an IP address
validity test. validity test.
11. Conclusions 8.6. Session establishment
It should be noted that if the session establishment protocol is
insecure there may be attacks on this that will have indirect
security implications on the secure media streams. This however only
applies to groups (and is not really that specific to MIKEY only).
The threat is that one group member may re-direct a stream from one
group member to another group member. This will have the same
implication as when a member tries to impersonate another member,
e.g. by changing its IP address. If this is seen as a problem, it is
RECOMMENDED that a Source Origin Authentication scheme is applied for
the security protocol.
9. Conclusions
Work for securing real-time applications have started to appear. This Work for securing real-time applications have started to appear. This
has brought forward the need for a key management solution to support has brought forward the need for a key management solution to support
the security protocol. The key management has to fulfil requirements, the security protocol. The key management has to fulfil requirements,
which make it suitable in the context of conversational multimedia in which make it suitable in the context of conversational multimedia in
a heterogeneous environment. MIKEY was designed to fulfill such a heterogeneous environment and small interactive groups. MIKEY was
requirements and optimized so that it also may be integrated in other designed to fulfill such requirements and optimized so that it also
protocol such as SIP and RTSP. may be integrated in other protocol such as SIP and RTSP.
MIKEY can be used in different scenarios, for peer-to-peer MIKEY is designed to be used in scenarios for peer-to-peer
communication, simple one-to-many, and for small-size groups without communication, simple one-to-many, and for small-size interactive
a centralized group server. This specification focused on the basic groups without a centralized group server.
peer-to-peer scenario, as this also will be the base for the group
scenarios.
12. Acknowledgments 10. Acknowledgments
The authors would like to thank, Mark Baugher, Ran Canetti, the rest The authors would like to thank Mark Baugher, Ran Canetti, the rest
of the msec WG, Pasi Ahonen, Rolf Blom, Vesa-Matti Mantyla, and of the MSEC WG, Pasi Ahonen (with his group), Rolf Blom, and Magnus
Magnus Westerlund, for their valuable feedback. Westerlund, for their valuable feedback.
13. Author's Addresses 11. Author's Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
02420 Jorvas Phone: +358 40 5079256 02420 Jorvas Phone: +358 40 5079256
Finland Email: jari.arkko@ericsson.com Finland Email: jari.arkko@ericsson.com
Elisabetta Carrara Elisabetta Carrara
Ericsson Research Ericsson Research
SE-16480 Stockholm Phone: +46 8 50877040 SE-16480 Stockholm Phone: +46 8 50877040
Sweden EMail: elisabetta.carrara@era.ericsson.se Sweden EMail: elisabetta.carrara@era.ericsson.se
skipping to change at page 25, line 4 skipping to change at page 31, line 32
Fredrik Lindholm Fredrik Lindholm
Ericsson Research Ericsson Research
SE-16480 Stockholm Phone: +46 8 58531705 SE-16480 Stockholm Phone: +46 8 58531705
Sweden EMail: fredrik.lindholm@era.ericsson.se Sweden EMail: fredrik.lindholm@era.ericsson.se
Mats Naslund Mats Naslund
Ericsson Research Ericsson Research
SE-16480 Stockholm Phone: +46 8 58533739 SE-16480 Stockholm Phone: +46 8 58533739
Sweden EMail: mats.naslund@era.ericsson.se Sweden EMail: mats.naslund@era.ericsson.se
Karl Norrman Karl Norrman
Ericsson Research Ericsson Research
SE-16480 Stockholm Phone: +46 8 4044502 SE-16480 Stockholm Phone: +46 8 4044502
Sweden EMail: karl.norrman@era.ericsson.se Sweden EMail: karl.norrman@era.ericsson.se
14. References 12. References
[AES] Advanced Encryption Standard, www.nist.gov/aes [AES] Advanced Encryption Standard, www.nist.gov/aes
[BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P.: "A [BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P.: "A
Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes
of Operation", in Proceedings of the 38th Symposium on Foundations of of Operation", in Proceedings of the 38th Symposium on Foundations of
Computer Science, IEEE, 1997, pp. 394-403. Computer Science, IEEE, 1997, pp. 394-403.
[GARCH] Baugher, M., Canetti, R., and Dondeti, L., "Group Key [BMGL] Hastad, J. and Naslund, M.: "Practical Construction and
Management Architecture", Internet Draft, June 2001, Work in Analysis of Pseduo-randomness Primitives", Proceedings of Asiacrypt
Progress. '01.
[GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.,
"Group Key Management Architecture", Internet Draft, Work in Progress
(MSEC WG).
[GDOI] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group [GDOI] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group
Domain of Interpretation", Internet Draft, February 2001, Work in Domain of Interpretation", Internet Draft, Work in Progress (MSEC
Progress. WG).
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, [GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer,
R., "Group Secure Association Key Management Protocol", Internet R., "Group Secure Association Key Management Protocol", Internet
Draft, March 2001, Work in Progress. Draft, Work in Progress (MSEC WG).
[HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and [KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
Norrman, K., "Key Management Extensions for SDP", Internet Draft, Norrman, K., "Key Management Extensions for SDP and RTSP", Internet
Work in Progress (MMUSIC WG). Draft, Work in Progress (MMUSIC WG).
[LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for [LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for
Cryptosystems", http://www.cryptosavvy.com/suggestions.htm Cryptosystems", http://www.cryptosavvy.com/suggestions.htm
[MD5] Rivest, R.,"MD5 Digest Algorithm", RFC 1321, April 1992. [MD5] Rivest, R.,"MD5 Digest Algorithm", RFC 1321, April 1992.
[NAI] Aboba, B. and Beadles, M., "The Network Access Identifier", [NAI] Aboba, B. and Beadles, M., "The Network Access Identifier",
IETF, RFC 2486, January 1999. IETF, RFC 2486, January 1999.
[NTP] Mills, D., "Network Time Protocol (Version 3) specification, [NTP] Mills, D., "Network Time Protocol (Version 3) specification,
implementation and analysis", RFC 1305, March 1992. implementation and analysis", RFC 1305, March 1992.
[OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC
2412, November 1998. 2412, November 1998.
[OAM] Rosenberg, J. and Schulzrinne, H., "An Offer/Answer Model with
SDP", Internet Draft, IETF, Work in progress (MMUSIC).
[PKCS1] PKCS #1 - RSA Cryptography Standard, [PKCS1] PKCS #1 - RSA Cryptography Standard,
http://www.rsalabs.com/pkcs/pkcs-1/ 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 [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining [RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining
Digital Signatures and Public-Key Cryptosystems". Communications of Digital Signatures and Public-Key Cryptosystems". Communications of
the ACM. Vol.21. No.2. pp.120-126. 1978. the ACM. Vol.21. No.2. pp.120-126. 1978.
[SDP] Handley, M., and Jacobson, V., "Session Description Protocol [SDP] Handley, M., and Jacobson, V., "Session Description Protocol
(SDP), IETF, RFC2327 (SDP), IETF, RFC2327
[SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
http://csrc.nist.gov/fips/fip180-1.ps http://csrc.nist.gov/fips/fip180-1.ps
[SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512", [SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512",
http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf
[SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J.,
"SIP: Session Initiation Protocol", IETF, RFC2543. "SIP: Session Initiation Protocol", IETF, RFC2543.
[SRTP] Blom, R., Carrara, E., McGrew, D., Naslund, M, Norrman, K., [SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M,
and Oran, D., "The Secure Real Time Transport Protocol", Internet Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol",
Draft, IETF, Work in Progress (AVT WG). Internet Draft, IETF, Work in Progress (AVT WG).
[TLS] Dierks, T. and Allen, C., "The TLS Protocol - Version 1.0", [TLS] Dierks, T. and Allen, C., "The TLS Protocol - Version 1.0",
IETF, RFC 2246. IETF, RFC 2246.
[TMMH] McGrew, D., "The Truncated Multi-Modular Hash Function [TMMH] McGrew, D., "The Truncated Multi-Modular Hash Function
(TMMH)", Internet Draft, IETF, Work in Progress. (TMMH)", Internet Draft, IETF, Work in Progress.
[URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource [URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396 Identifiers (URI): Generic Syntax", RFC 2396
Appendix A - Payload Encoding Appendix A - Payload Encoding
This appendix describes in detail all the payloads. For all encoding, This appendix describes in detail all the payloads. For all encoding,
Network byte order MUST always be used. Network byte order MUST always be used.
Note that everything denoted Mandatory MUST be implemented, and
everything denoted Default MUST be assumed to be selected if nothing
else is stated.
A.1. Common header payload A.1. Common header payload
The Common header payload MUST always be present as the first payload The Common header payload MUST always be present as the first payload
in each message. The common header includes general description of in each message. The common header includes general description of
the exchange message. the exchange message.
1 2 3 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 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 ! ! version ! data type ! next payload !R! PRF func !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MCS/CS ID type! ! ! MCS ID !
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MCS/CS ID ~ ! #CS ! CS ID map type! CS ID map info ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The common header contains the following information: The common header contains the following information:
* version: the version number of MIKEY. * version: the version number of MIKEY.
version = 1 version = 1
* data type: describes the type of message (e.g. public-key transport * data type: describes the type of message (e.g. public-key transport
message, verification message, error message). message, verification message, error message).
Data type | Value | Comment Data type | Value | Comment
-------------------------------------- --------------------------------------
Pre-shared | 0 | Initiator's pre-shared key transport message Pre-shared | 0 | Initiator's pre-shared key message
PS ver msg | 1 | Verification message of a Pre-shared message PS ver msg | 1 | Verification message of a Pre-shared
| | key message
Public key | 2 | Initiator's public-key transport message Public key | 2 | Initiator's public-key transport message
PK ver msg | 3 | Verification message of a public-key message PK ver msg | 3 | Verification message of a public-key
| | message
D-H init | 4 | Initiator's DH exchange message D-H init | 4 | Initiator's DH exchange message
D-H resp | 5 | Responder's DH exchange message D-H resp | 5 | Responder's DH exchange message
Error | 6 | Error message Error | 6 | Error message
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last payload. If no more payload follows, it MUST be set to Last
payload. payload.
Next payload | Value Next payload | Value | Appendix
--------------------- ------------------------------
Last payload | 0 Last payload | 0 | -
PS data | 1 Key data trnsp| 1 | A2
PK data | 2 Env data | 2 | A3
DH data | 3 DH data | 3 | A4
Signature | 4 Signature | 4 | A5
Timestamp | 5 Timestamp | 5 | A6
ID | 6 ID | 6 | A7
Certificate | 7 Certificate | 7 | A7
Cert hash | 8 Cert hash | 8 | A8
Ver msg | 9 Ver msg | 9 | A9
n_start | 10 SP | 10 | A10
n_end | 11 Rand | 11 | A11
SPI | 12 Error | 12 | A12
SP | 13 Key data | 20 | A13
Error | 14
* R: flag to indicate whether a response is expected or not (this has * R: flag to indicate whether a response is expected or not (this has
only meaning when it is set by the Initiator). only meaning when it is set by the Initiator).
R = 0 ==> no response expected R = 0 ==> no response expected
R = 1 ==> response expected R = 1 ==> response expected
* Hash func: Indicates the hash function that has been/will be used. * PRF func: Indicates the PRF function that has been/will be used for
key derivation etc.
Hash func | Value | Comments Hash func | Value | Comments
-------------------------------------------------------- --------------------------------------------------------
SHA-1 | 0 | Mandatory, Default (see [SHA1]) MIKEY-1 | 0 | Mandatory, Default (see Section 4.1.2-3.)
MD5 | 1 | (see [MD5]) MIKEY-256 | 1 | (as MIKEY-1 but using a HMAC with SHA256)
SHA256 | 2 | (see [SHA256]) MIKEY-384 | 2 | (as MIKEY-1 but using a HMAC with SHA384)
SHA384 | 3 | (see [SHA256]) MIKEY-512 | 3 | (as MIKEY-1 but using a HMAC with SHA512)
SHA512 | 4 | (see [SHA256])
* MCS/CS ID type: specifies the id used to uniquely identify the MCS * MCS ID: A 32-bit integer to identify the MCS. It is RECOMMENDED
and the CS(s). that it is chosen at random by the Initiator (the Initiator SHOULD
however check for collisions). The Responder MUST use the same MCS
ID in the response.
MCS/CS ID type | Value | Comments * #CS: Indicates the number of Crypto Sessions that will be handled.
Note that even though it is possible to use 256 CSs, this may not
always be likely.
* CS ID map type: specifies the method to uniquely map Crypto
Sessions to the security protocol sessions.
CS ID map type | Value | Comments
------------------------------------- -------------------------------------
SRTP-ID | 0 | Mandatory SRTP-ID | 0 | Mandatory
* CS ID map info: Identifies the crypto session(s) that the SA should
be created for. The currently defined map type is the SRTP-ID
(defined in A.1.1.).
* MCS/CS ID: Identifies the multimedia crypto session and/or the A.1.1. SRTP ID
crypto session(s) that the SA should be created for. The currently
defined IDs are:
SRTP ID
1 2 3 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 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 ! ! ! Policy nr 1 ! SSRC 1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
! !
+ SRTP MCS ID (80 bits) +
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC 1 ! ~ SSRC 1 cont. ! ROC 1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ROC 1 cont. ! Policy nr 2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC 2 ! ! SSRC 2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ROC 2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SSRC #CS ! ! Policy nr #CS ! SSRC #CS ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~SSRC #CS (cont)! ROC #CS ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ROC #CS (cont)!
+-+-+-+-+-+-+-+-+
* #CS: Indicates the number of Crypto Sessions, i.e. the number of * Policy x: The policy applied for the stream with SSRC x. The same
SRTP streams. policy may apply for all CSs.
* 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. * 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. Note that it is the sender of the streams who chooses the SSRC.
Therefore, it might be possible that the Initiator of MIKEY does Therefore, it might be that the Initiator of MIKEY can not fill in
can not fill in all fields. In this case, SSRCs that are not chosen all fields. In this case, SSRCs that are not chosen by the
by the Initiator are set to zero and the Responder fills in these Initiator are set to zero and the Responder fills in these field in
field in the response message. the response message.
NOTE: A stream using SSRC x will also have Crypto Session ID x. * ROC x: Current roll-over counter used in SRTP. If the SRTP session
has not started, this field is set to 0. This field is used to be
able for a member to join and synchronize to an already started
stream.
A.2. PS data payload NOTE: A stream using SSRC x will also have Crypto Session ID equal to
x (NOT to SSRC).
The PS (pre-shared) data payload contains the encrypted PMK and the A.2. Key data transport payload
MAC of the entire message. The PS data payload MUST be added as the
last payload in the pre-shared transport message. The Key data transport payload contains encrypted Key data payloads.
It may contain one or more Key data payloads each including a PMK or
a KEK. The last Key data payload MUST have its Next payload field set
to Last payload. For an update message (see also Section 4.5.), it is
allowed to skip the Key data payloads (which will result in that the
Encr data len is equal to 0).
If the transport method used is the pre-shared key method, this Key
data transport payload MUST be the last payload in the message (note
that the Next payload field MUST be set to Last payload). The MAC is
then calculated over the entire message (as described in Section
5.2.).
If the transport method used is the public-key method, the
Initiator's identity MUST be added in the encrypted data. This is
done by adding the ID payload as the first payload, which then are
followed by the Key data payloads. Note that for an update message,
the ID MUST still be sent encrypted to the Responder (this is to
avoid certain re-direction attacks) even though no Key data payloads
is added after.
The MAC field is in the public-key case calculated only over the Key
data transport payload, where the MAC field and the Next payload
field have been initiated with zeros.
1 2 3 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 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 ! ! Next payload ! Encr alg ! Encr data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encr data ~ ! Encr data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MAC ~ ! Mac alg ! MAC ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* MAC alg specifies the authentication algorithm used.
MAC alg | Value | Comments
--------------------------------------
HMAC-SHA1-160 | 0 | Mandatory
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: The encryption algorithm used to encrypt the PMK.
Encr alg | Value | Comments Encr alg | Value | Comments
------------------------------------------- -------------------------------------------
AES-CM-128 | 1 | Mandatory AES-CM-128 | 1 | Mandatory (as defined in Section 4.2.3.)
AES-CM-128 is AES in Counter Mode (as defined in [SRTP] where the * Encr len: Length of encrypted part (in bytes).
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. * Encr data: The encrypted PMK.
* MAC alg specifies the authentication algorithm used.
MAC alg | Value | Comments
--------------------------------------
HMAC-SHA1-160 | 0 | Mandatory (see Section 4.2.4.)
* MAC: The message authentication code of the entire message. * MAC: The message authentication code of the entire message.
A.3. PK data payload A.3. Envelope data payload
The PK (public-key) data payload contains the encrypted data from the The Envelope data payload contains the encrypted envelope key that is
PK transport. used in the public-key transport to protect the data in the Key data
transport payload.
1 2 3 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 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 ! ! ! Next Payload ! C ! Data len ! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ Key data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. payload.
* Key data len: The length of the Key data field (in bytes). * C: Envelope key cache indicator (see also Section 3.2., for more
information of the usage).
* Key data: The encrypted PMK (padding and formatting MUST be done Cache type | Value | Comments
according to RSA/PKCS#1 if RSA is used). --------------------------------------
No cache | 0 | The envelope key MUST NOT be cached
Cache | 1 | The envelope key should be cached
Cache for MCS | 2 | The envelope key should be cached, but only
| | to be used for the specific MCS.
* Data len: The length of the data field (in bytes).
* Data: The encrypted envelope key (padding and formatting MUST be
done according to RSA/PKCS#1 if RSA is used).
A.4. DH data payload A.4. DH data payload
The DH data payload carries the DH-value and indicates the DH-group The DH data payload carries the DH-value and indicates the DH-group
used. used.
1 2 3 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 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 ! ! Next Payload ! DH-Group ! DH-key len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DH-value ~ ~ DH-value ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! KV ! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. payload.
* DH-Group: identifies the DH group used. * DH-Group: identifies the DH group used.
DH-Group | Value | Comments DH-Group | Value | Comments
-------------------------------------- --------------------------------------
OAKLEY 5 | 0 | Mandatory OAKLEY 5 | 0 | Mandatory
OAKLEY 1 | 1 | OAKLEY 1 | 1 |
OAKLEY 2 | 2 | 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-key len: The length of the DH-value field (in bytes).
* DH-value: The public DH-value. * DH-value: The public DH-value.
* Type: Indicates the type of the key included in the payload, i.e.
if the resulting DH-key will be used as a PMK or KEK (in the second
case, the DH-key is not used directly as a KEK, but is derived
according to Section 4.1.6). See also Appendix A.13. for pre-
defined values.
* KV: Indicates the type of key validity period specified. This may
be done by using an SPI or by providing an interval in which the
key is valid (e.g. in the latter case, for SRTP this will be the
SEQ nr range where the key is valid). See Appendix A.13. for pre-
defined values.
* KV data: This includes either the SPI or an interval (see Appendix
A.14.). If KV is NULL, this field is not included.
A.5. Signature payload A.5. Signature payload
The Signature payload carries the signature and its related data. The The Signature payload carries the signature and its related data. The
signature payload MUST always be the last payload in the PK transport signature payload MUST always be the last payload in the PK transport
and DH exchange messages. and DH exchange messages.
1 2 3 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 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 len ! Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ Signature ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Signature len: The length of the signature field (in bytes). * Signature len: The length of the signature field (in bytes).
* Signature: The signature (padding and formatting MUST be done * Signature: The signature (padding and formatting MUST be done
according to RSA/PKCS#1 if RSA is used). according to RSA/PKCS#1 if RSA is used).
A.6. Timestamp payload A.6. Timestamp payload
The timestamp payload carries the time information. The current The timestamp payload carries the time information.
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
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 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 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 ! ! ! Next Payload ! TS type ! TS-value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ TS-value ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last payload. If no more payload follows, it MUST be set to Last
payload. See Appendix A.1. for values. payload. See Appendix A.1. for values.
* TS type: specifies the timestamp type used. * TS type: specifies the timestamp type used.
TS type | Value | Comments TS type | Value | Comments
------------------------------------- -------------------------------------
NTP-GMT | 0 | Mandatory (64-bits) NTP-UTC | 0 | Mandatory (64-bits)
NTP | 1 | 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. * TS-value: The timestamp value of the specified TS type.
A.7. ID payload / Certificate payload A.7. ID payload / Certificate payload
The ID payload carries a uniquely-defined identifier. The ID payload carries a uniquely-defined identifier.
The certificate payload contains an indicator of the certificate The certificate payload contains an indicator of the certificate
provided as well as the certificate data. provided as well as the certificate data.
1 2 3 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 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 ! ! Next Payload ! ID/Cert Type ! ID/Cert len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ID/Certificate Data ~ ! ID/Certificate Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last payload. If no more payload follows, it MUST be set to Last
payload. See Appendix A.1. for values. payload. See Appendix A.1. for values.
* ID Type: specifies the identifier type used. * ID Type: specifies the identifier type used.
ID Type | Value | Comments ID Type | Value | Comments
---------------------------------------------- ----------------------------------------------
NAI | 0 | Mandatory (see [NAI]) NAI | 0 | Mandatory (see [NAI])
URI | 1 | Mandatory (see [URI]) URI | 1 | Mandatory (see [URI])
* Cert Type: specifies the certificate type used. * Cert Type: specifies the certificate type used.
Cert Type | Value | Comments Cert Type | Value | Comments
---------------------------------------------- ----------------------------------------------
X.509 | 0 | Mandatory X.509 | 0 | Mandatory
X.509 URL | 1 | X.509 URL | 1 |
X.509 Sign | 2 | Mandatory
X.509 Encr | 3 | Mandatory
* ID/Cert len: The length of the ID or Certificate field (in bytes). * ID/Cert len: The length of the ID or Certificate field (in bytes).
* ID/Certificate: The ID or Certificate data. * ID/Certificate: The ID or Certificate data.
A.8. Cert hash payload A.8. Cert hash payload
The Cert hash payload contains the hash of the certificate used. The The Cert hash payload contains the hash of the certificate used. The
hash function used MUST be the one specified in the Common header hash function used MUST be the one specified in the Common header
payload. payload.
skipping to change at page 33, line 26 skipping to change at page 41, line 21
* ID/Cert len: The length of the ID or Certificate field (in bytes). * ID/Cert len: The length of the ID or Certificate field (in bytes).
* ID/Certificate: The ID or Certificate data. * ID/Certificate: The ID or Certificate data.
A.8. Cert hash payload A.8. Cert hash payload
The Cert hash payload contains the hash of the certificate used. The The Cert hash payload contains the hash of the certificate used. The
hash function used MUST be the one specified in the Common header hash function used MUST be the one specified in the Common header
payload. payload.
1 2 3 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 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 ! ! ! Next Payload ! Hash func ! Hash ~
+-+-+-+-+-+-+-+-+ +
~ Hash ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. payload.
* Hash func: Indicates the hash function that has been/will be used
(see also Section 4.2.1.).
Hash func | Value
----------------------
SHA-1 | 0
SHA256 | 1
SHA384 | 2
SHA512 | 3
MD5 | 4
* Hash: The hash data. Note: the hash length is implicit from the * Hash: The hash data. Note: the hash length is implicit from the
hash function used. hash function used.
A.9. Ver msg payload A.9. Ver msg payload
The Ver msg payload contains the calculated verification message in The Ver msg payload contains the calculated verification message in
the PS/PK transport. the PS/PK transport. Note that the MAC is calculated over the entire
message as well as the IDs and Timestamp.
1 2 3 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 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 ! ! ! Next Payload ! Auth alg ! Ver data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ Ver data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last payload. If no more payload follows, it MUST be set to Last
payload. See Appendix A.1. for values. payload. See Appendix A.1. for values.
* Auth alg specified the authentication algorithm used for the * Auth alg specified the authentication algorithm used for the
verification message. verification message.
Auth alg | Value | Comments Auth alg | Value | Comments
------------------------------------ ------------------------------------
HMAC-SHA1-160 | 0 | Mandatory HMAC-SHA1-160 | 0 | Mandatory
HMAC-SHA1-160 is HMAC using SHA-1 with a 160-bits tag length. HMAC-SHA1-160 is HMAC using SHA-1 with a 160-bits tag length.
* Ver data: The verification message data. Note: the length is * Ver data: The verification message data. Note: the length is
implicit from the authentication algorithm used. implicit from the authentication algorithm used.
A.10. n_start/n_end/SPI payload A.10. Security Policy 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 The Security Policy payload defines a set of policies that applies to
its related parameters. a specific security/re-key protocol.
1 2 3 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 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 ! Policy nr ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last payload. If no more payload follows, it MUST be set to Last
payload. See Appendix A.1. for values. payload. See Appendix A.1. for values.
* SP defines the security protocol used. * Policy nr: Each security policy payload must be given a distinct
number.
SP | Value * Prot type: defines the security protocol or re-key protocol.
---------------------
SRTP | 0
* SP param defines the parameters for the security protocol. SP param Prot type | Value |
is dependent on the defined security protocol. ---------------------------
SRTPbasic | 0 | see A.10.1.
SRTPext | 1 | see A.10.2.
Re-key | 2 | see A.10.3.
For SRTP the SP param is currently defined as: * Policy param defines the policy for the security/re-key protocol.
A.10.1. SRTPbasic policy
This policy specifies the policy for SRTP and SRTCP. All defined
transform applies to both SRTP and (if used) SRTCP.
1 2 3 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 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 ! ! encr alg ! encr key len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len ! Salt key ~ ! auth alg ! auth key len ! auth tag len ! salt key len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SRTP PRF ! Key Der rate !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTE: SRTP was not finalized by the date for this draft's submission. NOTE: SRTP was not finalized by the date for this draft's submission.
Therefore, these parameters might be an issue for update! Therefore, these parameters might be an issue for update!
* encr alg specifies the desired encryption algorithm to be used. * encr alg specifies the desired encryption algorithm to be used in
SRTP (and SRTCP, if used by SRTP).
encr alg | Value | Comments encr alg | Value | Comments
------------------------------------------- ------------------------------------------
NULL | 0 | Mandatory NULL | 0 | Mandatory
AES-CM-128 | 1 | Mandatory AES-CM-128 | 1 | Mandatory
AES-F8-128 | 2 | AES-F8-128 | 2 |
AES-CM-128 is AES in CM with 128-bit block size and key. AES-CM-128 is AES in CM with 128-bit block size.
AES-F8-128 is AES in f8 mode with 128-bit block size and key. AES-F8-128 is AES in f8 mode with 128-bit block size.
* encr key len: desired session encryption key length in bytes.
* auth alg specifies the desired authentication algorithm to be used. * auth alg specifies the desired authentication algorithm to be used.
auth alg | Value | Comments auth alg | Value | Comments
------------------------------------------- -------------------------------------------
NULL | 0 | Mandatory NULL | 0 | Mandatory
TMMH-16-16 | 1 | ? TMMH-16 | 1 | Mandatory
HMAC-SHA1-32 | 2 | ? HMAC-SHA1 | 2 | Mandatory
TMMH-16-16 is TMMH/16 [TMMH] with a 16-bit tag length. * auth key len: desired session authentication key length in bytes.
HMAC-SHA1-32 is HMAC using SHA-1 with a 32-bits tag length. * auth tag len: desired length in bytes of the output tag of the MAC.
* Salt len: Length of the salting key. * salt key len: The desired session salting key length in bytes.
Note: do not mix this with the master salt that are exchanged.
* Salt key: The salting key to SRTP (must be random). * PRF: Specifies the PRF used.
SRTP PRF | Value | Comments
-------------------------------------------
AES-CM | 0 | Mandatory
* Key Der rate: The 2-logarithm of the desired key derivation rate.
Note that this is possible as the key derivation rate must be a
power of 2 in the range [0..2^16].
A.10.2. SRTPext policy
This policy separates the SRTP and SRTCP policies.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SRTP EA ! SRTP EKL !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SRTP AA ! SRTP AKL ! SRTP ATL ! SRTP SKL !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SRTxP PRF ! SRTP KDR ! SRTCP EA ! SRTCP EKL !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SRTCP AA ! SRTCP AKL ! SRTCP ATL ! SRTCP SKL !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SRTCP KDR !
+-+-+-+-+-+-+-+-+
* SRTP EA: encryption algorithm for SRTP (see Appendix A.10.1. for
defined ciphers).
* SRTP EAL: encryption key length in bytes for SRTP.
* SRTP AA: authentication algorithm for SRTP (see Appendix A.10.1.
for defined transforms).
* SRTP AKL: authentication key length in bytes for SRTP.
* SRTP ATL: authentication tag length in bytes for SRTP.
* SRTP SKL: salting key length in bytes for SRTP.
* SRTxP PRF: pseudo-random function for SRTP and SRTCP (see Appendix
A.10.1. for defined PRFs).
* SRTP KDR: the 2-logarithm of the key derivation rate for SRTP (see
also Appendix A.10.1).
* SRTCP EA: encryption algorithm for SRTCP (see Appendix A.10.1. for
defined ciphers).
* SRTCP EAL: encryption key length in bytes for SRTCP.
* SRTCP AA: authentication algorithm for SRTCP (see Appendix A.10.1.
for defined transforms).
* SRTCP AKL: authentication key length in bytes for SRTCP.
* SRTCP ATL: authentication tag length in bytes for SRTCP.
* SRTCP SKL: salting key length in bytes for SRTCP.
* SRTCP KDR: the 2-logarithm of the key derivation rate for SRTCP
(see also Appendix A.10.1).
A.10.3. Re-key policy
The following attributes is supported according to GKMARCH.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KEK alg ! auth alg !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KEK key len ! auth key len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! mm alg !
+-+-+-+-+-+-+-+-+
* KEK alg: The KEK ENCRYPTION ALGORITHM
KEK alg | Value
-----------------------
NULL | 0
3DES | 1
AES | 2
* auth alg: The AUTHENTICATION ALGORITHM
auth alg | Value
-----------------------
NULL | 0
HMAC-SHA1 | 1
HMAC-MD5 | 2
* KEK key len: The key length of the KEK
* auth key len: The key length of the authentication key
* mm alg: The MEMBERSHIP MANAGEMENT ALGORITHM
mm alg | Value
-----------------------
NULL | 0
LKH | 1
A.11. Rand payload
The Rand payload consist of a random bit-string. The Rand MUST be
chosen at random and per MCS (note that the if a MCS has several
members, the Initiator MUST use the same Rand to all the members).
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 ! Rand len ! Rand ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload: identifies the payload that is added after this
payload.
* Rand len: Length of the Rand (in bytes). SHOULD be at least 16.
* Rand: a randomly chosen bit-string.
A.12. Error payload A.12. Error payload
The Error payload is used to specify the error(s) that may have The Error payload is used to specify the error(s) that may have
occurred. occurred.
1 2 3 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 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 ! Error nr ! Reserved !
skipping to change at page 36, line 36 skipping to change at page 46, line 45
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last payload. If no more payload follows, it MUST be set to Last
payload. See Appendix A.1. for values. payload. See Appendix A.1. for values.
* Error nr indicates the type of error that was encountered. * Error nr indicates the type of error that was encountered.
Error nr | Value | Comment Error nr | Value | Comment
------------------------------------------------------- -------------------------------------------------------
Auth failure | 0 | Authentication failure Auth failure | 0 | Authentication failure
Invalid TS | 1 | Invalid timestamp Invalid TS | 1 | Invalid timestamp
Invalid hash | 2 | hash function NOT supported Invalid hash | 2 | PRF function NOT supported
Invalid MA | 3 | MAC algorithm NOT supported Invalid MA | 3 | MAC algorithm NOT supported
Invalid DH | 4 | DH group NOT supported Invalid DH | 4 | DH group NOT supported
Invalid ID | 5 | ID NOT supported Invalid ID | 5 | ID NOT supported
Invalid Cert | 6 | certificate NOT supported Invalid Cert | 6 | certificate NOT supported
Invalid SP | 7 | SP NOT supported Invalid SP | 7 | SP NOT supported
Invalid SPpar | 8 | SP parameters NOT supported Invalid SPpar | 8 | SP parameters NOT supported
A.13. Key data payload
The key data payload contains PMKs and a optionally also a KEK. These
are never included in clear, but as an encrypted part of the Key data
transport 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 ! Type ! KV ! Key data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len (optional) ! Salt data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload: identifies the payload that is added after this
payload.
* Type: Indicates the type of the key included in the payload. Note
that TEKs are not sent directly, but a PMK, which is then used to
derive the TEK (or TEKs if there are several crypto sessions).
Type | Value | Comments
-------------------------------------------
PMK | 0 | A Pre-master key (used to derive TEKs from)
PMK+SALT | 1 | A PMK + a salt key are included
KEK | 2 | A Key-encrypting key
* KV: Indicates the type of key validity period specified. This may
be done by using an SPI or by providing an interval in which the
key is valid (e.g. in the latter case, for SRTP this will be the
SEQ nr range where the key is valid).
KV | Value | Comments
-------------------------------------------
Null | 0 | No specific usage rule (e.g. a TEK
| | that has no specific lifetime)
SPI | 1 | The key is associated with the SPI
Interval | 2 | The key has a start and expiration time
| | (e.g. an SRTP TEK)
Note that when NULL is specified, any SPI or Interval is valid. For
an Interval this means that the key is valid from the first
observed sequence number until the key is replaced (or the security
protocol is shutdown).
* Key data len: The length of the Key data field (in bytes).
* Key data: The PMK data or the KEK data.
* Salt len: The salt key length in bytes. Note that this field is
only included if the salt is specified in the Type-field.
* Salt data: The salt key data. Note that this field is only included
if the salt is specified in the Type-field. (For SRTP, this is the
so-called master salt.)
* KV data: This includes either the SPI or an interval (see Appendix
A.14.). If KV is NULL, this field is not included.
A.14. Key validity data
The Key validity data is not a payload, but part of either the Key
data payload (see Appendix A.13.) or the DH payload (see Appendix
A.4.). The Key validity data gives a guideline of when the key should
be used. This can be done, using an SPI or a lifetime range.
SPI
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI Length ! SPI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* SPI Length: The length of the SPI (or MKI) in bytes.
* SPI: The SPI (or MKI for SRTP).
Interval
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VF Length ! Valid from ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VT Length ! Valid to (expires) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* VF Length: Length of the Valid From field in bytes.
* Valid From: Sequence number, timestamp, or other start value that
the security protocol uses to identify the start position of the
key usage.
* VT Length: Length of the Valid To field in bytes.
* Valid to: Sequence number, timestamp, or other expiration value
that the security protocol can use to identify the expiration of
the key usage.
Note that for SRTP usage, the key validity period for a PMK should be
specified with either an interval, where the VF/VT length is equal to
6 bytes, or with an SPI (in SRTP denoted as a Master Key Identifier,
MKI). It is recommended that if more than one SRTP stream is sharing
the same keys and key update/re-keying is desired, this is handled
using SPI rather than the From-To method.
Appendix B. - Payload usage summary Appendix B. - Payload usage summary
Depending on the type of message, different payloads MUST and MAY be Depending on the type of message, different payloads MUST and MAY be
included. There are five distinct types of messages: included. There are five distinct types of messages:
* Pre-shared key transport message * Pre-shared key transport message
* Public key transport message * Public key transport message
* Verification message (for either pre-shared key or public key) * Verification message (for either pre-shared key or public key)
* DH exchange message (bi-directional) * DH exchange message (bi-directional)
* Error message * Error message
| Message Type | Message Type
Payload type | PS | PK | DH | Ver | Error Payload type | PS | PK | DH | Ver | Error
------------------------------------------------- -------------------------------------------------
PS data | M - - - - Key data trnsp| M M# - - O+
PK data | - M* - - - Env data | - M - - -
DH data | - - M - - DH data | - - M# - -
Ver msg | - - - M - Ver msg | - - - M -
Error | - - - - M Error | - - - - M
Timestamp | M M M - O Timestamp | M M M - O
ID | O O O O O ID | O M M O O
Signature | - O M - - Signature | - M M - O+
Certificate | - O O - - Certificate | - O O - -
Cert hash | - 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 SP | O O O - O
Rand | M@ M@ M@ - -
# These messages are only mandatory for initial messages, i.e. for an
update message of a MCS these are optional to include (see also
Section 4.5.).
+ These messages may be included to authenticate the error message.
However, before the other peer has been correctly authenticated, it
is not recommended that the error messages are sent authenticated
(as this would open up for DoS attacks).
@ MUST only be included by the Initiator in the initial exchange.
When a payload is not included, the default values for the When a payload is not included, the default values for the
information carried by it SHALL be used (when applicable). The information carried by it SHALL be used (when applicable). The
following table summarizes what messages may be included in a following table summarizes what messages may be included in a
specific message. specific message.
This Internet-Draft expires in May 2002. For the encrypted sub payloads in the Key data transport payload, the
following should hold:
| Message Type
Payload type | PS | PK
-----------------------------
Keydata/PMK | O O
Keydata/KEK | O O
ID | - M
Revision history
Changes from -00 draft:
* Support for Re-key SA including KEK transport for all methods.
* PK: Id included in the encrypted part to avoid "impersonation"
attacks.
* PK: Envelope approach for encryption of keys (as the size may
exceed the limit that can be encrypted with one public-key
operation).
* Message processing updated
* SDP, SIP and RTSP considerations updated
* Group section updated
* The use of Rand (instead of require a large and random MCS ID)
* SRTP policies etc updated
* Payload update (to support the above changes)
* general editorial changes
This Internet-Draft expires in August 2002.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/