draft-ietf-msec-mikey-07.txt   draft-ietf-msec-mikey-08.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: December 2003 M. Naslund Expires: June 2004 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
June, 2003 December, 2003
MIKEY: Multimedia Internet KEYing MIKEY: Multimedia Internet KEYing
<draft-ietf-msec-mikey-07.txt> <draft-ietf-msec-mikey-08.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 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Security protocols for real-time multimedia applications have started Security protocols for real-time multimedia applications have started
to appear. This has brought forward the need for a key management to appear. This has brought forward the need for a key management
solution to support these protocols. solution to support these protocols.
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). In particular, its use to support the Secure Real-
such as SIP and RTSP. In particular, its use to support the Secure time Transport Protocol is described in detail.
Real-time Transport Protocol, [SRTP], is described in detail.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction.....................................................3 1. Introduction.....................................................3
1.1. Existing solutions.............................................4 1.1. Existing solutions.............................................4
1.2. Notational Conventions.........................................4 1.2. Notational Conventions.........................................4
1.3. Definitions....................................................4 1.3. Definitions....................................................4
1.4. Abbreviations..................................................5 1.4. Abbreviations..................................................5
1.5. Outline........................................................6 1.5. Outline........................................................6
2. Basic Overview...................................................6 2. Basic Overview...................................................6
2.1. Scenarios......................................................6 2.1. Scenarios......................................................6
2.2. Design Goals...................................................7 2.2. Design Goals...................................................7
2.3. System Overview................................................8 2.3. System Overview................................................8
2.4. Relation to GKMARCH............................................9 2.4. Relation to GKMARCH............................................9
3. Basic Key Transport and Exchange Methods.........................9 3. Basic Key Transport and Exchange Methods........................10
3.1. Pre-shared key................................................11 3.1. Pre-shared key................................................11
3.2. Public-key encryption.........................................12 3.2. Public-key encryption.........................................12
3.3. Diffie-Hellman key exchange...................................13 3.3. Diffie-Hellman key exchange...................................14
4. Key Management..................................................14 4. Selected Key Management Functions...............................15
4.1. Key Calculation...............................................14 4.1. Key Calculation...............................................15
4.1.1. Assumptions.................................................14 4.1.1. Assumptions.................................................15
4.1.2. Notation....................................................15 4.1.2. Default PRF Description.....................................16
4.1.3. PRF Description.............................................15 4.1.3. Generating keys from TGK....................................17
4.1.4. Generating keys from TGK....................................16 4.1.4. Generating keys for MIKEY messages from
4.1.5. Generating keys from an envelope/pre-shared key.............16 an envelope/pre-shared key..................................18
4.2 Pre-defined Transforms and Timestamp Formats...................17 4.2 Pre-defined Transforms and Timestamp Formats...................18
4.2.1 Hash functions...............................................17 4.2.1 Hash functions...............................................19
4.2.2 Pseudo random number generator and PRF.......................17 4.2.2 Pseudo-random number generator and PRF.......................19
4.2.3 Key data transport encryption................................17 4.2.3 Key data transport encryption................................19
4.2.4 MAC and Verification Message function........................18 4.2.4 MAC and Verification Message function........................20
4.2.5 Envelope Key encryption......................................18 4.2.5 Envelope Key encryption......................................20
4.2.6 Digital Signatures...........................................18 4.2.6 Digital Signatures...........................................20
4.2.7 Diffie-Hellman Groups........................................18 4.2.7 Diffie-Hellman Groups........................................20
4.2.8. Timestamps..................................................18 4.2.8. Timestamps..................................................20
4.2.9. Adding new parameters to MIKEY..............................19 4.2.9. Adding new parameters to MIKEY..............................20
4.3. Certificates, Policies and Authorization......................19 4.3. Certificates, Policies and Authorization......................21
4.3.1. Certificate handling........................................19 4.3.1. Certificate handling........................................21
4.3.2. Authorization...............................................20 4.3.2. Authorization...............................................22
4.3.3. Data Policies...............................................21 4.3.3. Data Policies...............................................23
4.4. Retrieving the Data SA........................................21 4.4. Retrieving the Data SA........................................23
4.5. TGK re-keying and CSB updating................................21 4.5. TGK re-keying and CSB updating................................23
5. Behavior and message handling...................................23 5. Behavior and message handling...................................25
5.1. General.......................................................23 5.1. General.......................................................25
5.1.1. Capability Discovery........................................23 5.1.1. Capability Discovery........................................25
5.1.2. Error Handling..............................................23 5.1.2. Error Handling..............................................26
5.2. Creating a message............................................24 5.2. Creating a message............................................26
5.3. Parsing a message.............................................25 5.3. Parsing a message.............................................28
5.4. Replay handling and timestamp usage...........................26 5.4. Replay handling and timestamp usage...........................28
5.5. Reliability...................................................28 6. Payload Encoding................................................30
6. Payload Encoding................................................28 6.1. Common Header payload (HDR)...................................31
6.1. Common header payload (HDR)...................................28 6.1.1. SRTP ID.....................................................33
6.1.1. SRTP ID.....................................................31 6.2. Key data transport payload (KEMAC)............................34
6.2. Key data transport payload (KEMAC)............................31 6.3. Envelope data payload (PKE)...................................35
6.3. Envelope data payload (PKE)...................................33 6.4. DH data payload (DH)..........................................36
6.4. DH data payload (DH)..........................................33 6.5. Signature payload (SIGN)......................................37
6.5. Signature payload (SIGN)......................................34 6.6. Timestamp payload (T).........................................37
6.6. Timestamp payload (T).........................................35 6.7. ID payload (ID) / Certificate payload (CERT)..................38
6.7. ID payload (ID) / Certificate payload (CERT)..................35 6.8. Cert hash payload (CHASH).....................................39
6.8. Cert hash payload (CHASH).....................................36 6.9. Ver msg payload (V)...........................................40
6.9. Ver msg payload (V)...........................................37 6.10. Security Policy payload (SP).................................40
6.10. Security Policy payload (SP).................................37 6.10.1. SRTP policy................................................41
6.10.1. SRTP policy................................................38 6.11. RAND payload (RAND)..........................................43
6.11. RAND payload (RAND)..........................................39 6.12. Error payload (ERR)..........................................43
6.12. Error payload (ERR)..........................................40 6.13. Key data sub-payload.........................................44
6.13. Key data sub-payload.........................................40 6.14. Key validity data............................................45
6.14. Key validity data............................................42 6.15. General Extension Payload....................................46
6.15. General Extension Payload....................................43 7. Transport protocols.............................................47
7. Integration with session establishment protocols................43 8. Groups..........................................................47
7.1. SDP integration...............................................43 8.1. Simple one-to-many............................................48
7.2. MIKEY within SIP..............................................44 8.2. Small-size interactive group..................................48
7.3. MIKEY with RTSP...............................................45 9. Security Considerations.........................................49
7.4. MIKEY Interface...............................................45 9.1. General.......................................................49
8. Groups..........................................................46 9.2. Key lifetime..................................................51
8.1. Simple one-to-many............................................47 9.3. Timestamps....................................................52
8.2. Small-size interactive group..................................47 9.4. Identity protection...........................................52
9. Security Considerations.........................................48 9.5. Denial of Service.............................................52
9.1. General.......................................................48 9.6. Session establishment.........................................53
9.2. Key lifetime..................................................50 10. IANA considerations............................................53
9.3. Timestamps....................................................50 10.1 MIME Registration.............................................55
9.4. Identity protection...........................................51 11. Acknowledgments................................................56
9.5. Denial of Service.............................................51 12. Author's Addresses.............................................56
9.6. Session establishment.........................................51 13. References.....................................................56
10. IANA considerations............................................52 13.1. Normative References.........................................56
11. Conclusions....................................................54 13.2. Informative References.......................................57
12. Acknowledgments................................................54 Appendix A. - MIKEY - SRTP relation................................59
13. Author's Addresses.............................................54
14. References.....................................................55
14.1. Normative References.........................................55
14.2. Informative References.......................................56
Appendix A. - MIKEY - SRTP relation................................57
Change History since -06 draft.....................................58
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 and related security parameters. There are some exchange keys and related security parameters. There are some
fundamental properties that such a key management scheme has to fundamental properties that such a key management scheme has to
fulfill with respect to the kind of real-time applications (such as fulfill to serve streaming and real-time applications (such as
streaming, unicast, groups, multicast) and also with respect to unicast and multicast), in particular in heterogeneous (mix of wired
heterogeneous (mix of wired and wireless) networks. and wireless) networks.
This document describes a key management solution that addresses This document describes a key management solution that addresses
multimedia scenarios (e.g. SIP calls and RTSP sessions). The focus is multimedia scenarios (e.g. SIP [SIP] calls and RTSP [RTSP] sessions).
on how to set up key management for secure multimedia sessions such The focus is on how to set up key management for secure multimedia
that requirements in a heterogeneous environment are fulfilled. sessions such that requirements in a heterogeneous environment are
fulfilled.
1.1. Existing solutions 1.1. 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 below, there is communication [GDOI, GSAKMP]. For reasons discussed below, there is
however a need for a scheme with low latency, suitable for demanding however a need for a scheme with lower latency, suitable for
cases such as real-time data over heterogeneous networks, and small demanding cases such as real-time data over heterogeneous networks,
interactive groups. and small interactive groups.
An option in some cases might be to use [SDP], as SDP defines one
field to transport keys, the "k=" field. However, this field cannot
be used for more general key management purposes, as it cannot be
extended from the current definition.
1.2. Notational Conventions 1.2. 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
[RFC2119].
1.3. Definitions 1.3. Definitions
(Data) Security Protocol: the security protocol used to protect the
actual data traffic. Examples of security protocols are IPsec and
SRTP.
Data Security Association (Data SA): information for the security
protocol, including a TEK and a set of parameters/policies.
Crypto Session (CS): uni- or bi-directional data stream(s), protected Crypto Session (CS): uni- or bi-directional data stream(s), protected
by a single instance of a security protocol. E.g. when SRTP is used, by a single instance of a security protocol. E.g. when SRTP is used,
the Crypto Session will often contain two streams, an RTP stream and the Crypto Session will often contain two streams, an RTP stream and
the corresponding RTCP which are both protected by a single SRTP the corresponding RTCP which are both protected by a single SRTP
Cryptographic Context, i.e. share key and the bulk of security Cryptographic Context, i.e. they share key data and the bulk of
parameters in the SRTP Cryptographic Context (default behavior in security parameters in the SRTP Cryptographic Context (default
[SRTP]). In the case of IPsec, a Crypto Session would represent an behavior in [SRTP]). In the case of IPsec, a Crypto Session would
instantiation of an IPsec SA. A Crypto Session can be viewed as a represent an instantiation of an IPsec SA. A Crypto Session can be
Data SA (as defined in [GKMARCH]) and could therefore be mapped to viewed as a Data SA (as defined in [GKMARCH]) and could therefore be
other security protocols if needed. mapped to other security protocols if needed.
Crypto Session Bundle (CSB): collection of one or more Crypto Crypto Session Bundle (CSB): collection of one or more Crypto
Sessions, which can have common TEK Generation Keys and security Sessions, which can have common TGKs (see below) and security
parameters. parameters.
Crypto Session ID: unique identifier for the Crypto Session within an Crypto Session ID: unique identifier for the CS within a CSB.
CSB.
Crypto Session Bundle ID: unique identifier for the CSB. Crypto Session Bundle ID (CSB ID): unique identifier for the CSB.
TEK Generation Key (TGK): a bit-string agreed upon by two or more TEK Generation Key (TGK): a bit-string agreed upon by two or more
parties, associated with CSB. From the TEK Generation Key, Traffic- parties, associated with CSB. From the TGK, Traffic-encrypting Keys
encrypting Keys can then be generated without need of further can then be generated without need of further communication.
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 CS (this key may be used directly by the security
security protocol or may be used to derive further keys depending on protocol or may be used to derive further keys depending on the
the security protocol). The TEKs are derived from the CSB's TGK. security protocol). The TEKs are derived from the CSB's TGK.
TGK re-keying: the process of re-negotiating/updating the TGK (and TGK re-keying: the process of re-negotiating/updating the TGK (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.
Data SA: information for the security protocol, including a TEK and a Salting key: a random or pseudo-random (see [RAND, HAC]) string used
set of parameters/policies. to protect against some off-line pre-computation attacks on the
underlying security protocol.
PRF(k,x): a keyed pseudo-random function. PRF(k,x): a keyed pseudo-random function (see [HAC]).
E(k,m): encryption of m with the key k. E(k,m): encryption of m with the key k.
PKx: the public key of x PKx: the public key of x
[] an optional piece of information [] an optional piece of information
{} denotes zero or more occurrences {} denotes zero or more occurrences
|| concatenation || concatenation
| OR (selection operator) | OR (selection operator)
^ exponentiation ^ exponentiation
XOR exclusive or XOR 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
skipping to change at page 6, line 21 skipping to change at page 6, line 25
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 other general key management in Section 3. The key derivation, and other general key management
procedures are described in Section 4. 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.
All definitions of the payloads in MIKEY are described in Section 6. All definitions of the payloads in MIKEY are described in Section 6.
As MIKEY can be carried in SDP over SIP or RTSP, Section 7 describes Section 7 deals with transport considerations, while Section 8
how to integrate and use MIKEY in these scenarios. focuses on how MIKEY is used in group scenarios.
Section 8 focuses on how MIKEY is used in group scenarios.
The Security Considerations section (Section 9), gives a deeper The Security Considerations section (Section 9), gives a deeper
explanation of important security related topics. explanation of important security related topics.
2. Basic Overview 2. Basic Overview
2.1. Scenarios 2.1. Scenarios
MIKEY is mainly intended to be used for peer-to-peer, simple one-to- MIKEY is mainly intended to be used for peer-to-peer, simple one-to-
many, and small-size (interactive) groups. One of the main multimedia many, and small-size (interactive) groups. One of the main multimedia
skipping to change at page 7, line 22 skipping to change at page 7, line 36
parties where it may be desirable that the security is either set up parties where it may be desirable that the security is either set up
by mutual agreement or that each party sets up the security for its by mutual agreement or that each party sets up the security for its
own outgoing streams. own outgoing streams.
b) simple one-to-many (multicast), e.g. real-time presentations, b) 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.
c) many-to-many, without a centralized control unit, e.g. for small- c) many-to-many, without a centralized control unit, e.g. for small-
size interactive groups where each party may set up the security for size interactive groups where each party may set up the security for
its own outgoing media. Two basic models may be used here. In the its own outgoing media. Two basic models may be used here. In the
first model, the initiator of the group acts as the group server (and first model, the Initiator of the group acts as the group server (and
is the only one authorized to include new members). In the second is the only one authorized to include new members). In the second
model, authorization information to include new members can be model, authorization information to include new members can be
delegated to other participants. delegated to other participants.
d) many-to-many, with a centralized control unit, e.g. for larger d) many-to-many, with a centralized control unit, e.g. for larger
groups with some kind of Group Controller that sets up the security. groups with some kind of Group Controller that sets up the security.
The key management solutions may be different in the above scenarios. The key management solutions may be different in the above scenarios.
When designing MIKEY, the main focus has been on case a, b, and c. When designing MIKEY, the main focus has been on case a, b, and c.
For scenario c, only the first model is covered by this document. For scenario c, only the first model is covered by this document.
skipping to change at page 7, line 51 skipping to change at page 8, line 14
* 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 roundtrips. - minimal number of roundtrips.
* Tunneling. Possibility to "tunnel"/integrate MIKEY in session * Tunneling. Possibility to "tunnel"/integrate MIKEY in session
establishment protocols (e.g. SIP and RTSP). establishment protocols (e.g. SDP and RTSP).
* Independent of any specific security functionality of the * Independent of any specific security functionality of the
underlying transport. underlying transport.
2.3. System Overview 2.3. System Overview
One objective of MIKEY is to produce a Data security protocol SA One objective of MIKEY is to produce a Data SA for the security
(Data SA), including a traffic-encrypting key (TEK), which is derived protocol, including a traffic-encrypting key (TEK), which is derived
from a TEK Generation Key (TGK) and used as the input to the security from a TEK Generation Key (TGK), and used as input to the security
protocol. protocol.
MIKEY supports the possibility to establish keys and parameters for MIKEY supports the possibility to establish keys and parameters for
more than one security protocol at the same time. The concept of more than one security protocol (or for several instances of the same
Crypto Session Bundle (CSB) is used to denote a collection of one or security protocol) at the same time. The concept of Crypto Session
more Crypto Sessions that can have common TEK Generation Keys and Bundle (CSB) is used to denote a collection of one or more Crypto
security parameters, but which obtain distinct TEKs from MIKEY. Sessions that can have common TGK and security parameters, but which
obtain distinct TEKs from MIKEY.
The procedure of setting up a CSB and creating a TEK (and Data SA), The procedure of setting up a CSB and creating a TEK (and Data SA),
is done in accordance with Figure 2.2: is done in accordance with Figure 2.2:
1. A set of security parameters and TEK Generation Key(s) (TGK) are 1. A set of security parameters and TGK(s) are agreed upon for the
agreed upon for the Crypto Session Bundle (this is done by one of the Crypto Session Bundle (this is done by one of the three alternative
three alternative key transport/exchange mechanisms, see Section 3). key transport/exchange mechanisms, see Section 3).
2. The TGK(s) is used to derive (in a cryptographically secure way) a 2. The TGK(s) is used to derive (in a cryptographically secure way) a
TEK for each Crypto Session. TEK for each Crypto Session.
3. The TEK, together with the security protocol policy parameters 3. The TEK, together with the security protocol parameters, represent
represent the Data SA, which is used as the input to the Security the Data SA, which is used as the input to the security protocol.
Protocol.
+-----------------+ +-----------------+
| CSB | | CSB |
| Key transport | (see Section 3) | Key transport | (see Section 3)
| /exchange | | /exchange |
+-----------------+ +-----------------+
| : | :
| TGK : | TGK :
v : v :
+----------+ : +----------+ :
skipping to change at page 8, line 54 skipping to change at page 9, line 27
TEK | : TEK | :
v v v v
Data SA Data SA
| |
v v
+-------------------+ +-------------------+
| Crypto Session | | Crypto Session |
|(Security Protocol)| |(Security Protocol)|
+-------------------+ +-------------------+
Figure 2.2: Overview of the key management procedure. Figure 2.2: Overview of MIKEY key management procedure.
The security protocol can then either use the TEK directly, or, if The security protocol can 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.
MIKEY can be used to update TEKs and the Crypto Sessions in a current MIKEY can be used to update TEKs and the Crypto Sessions in a current
Crypto Session Bundle (see Section 4.5). This is done by executing Crypto Session Bundle (see Section 4.5). This is done by executing
the transport/exchange phase once again to obtain a new TGK (and the transport/exchange phase once again to obtain a new TGK (and
consequently derive new TEKs) or to update some other specific Crypto consequently derive new TEKs) or to update some other specific CS
Session parameters. parameters.
2.4. Relation to GKMARCH 2.4. Relation to GKMARCH
The Group key management architecture (GKMARCH) [GKMARCH] describes a The Group key management architecture (GKMARCH) [GKMARCH] describes a
general architecture for group key management protocols. MIKEY is a general architecture for group key management protocols. MIKEY is a
part of this architecture, and can be used as a so called part of this architecture, and can be used as a so-called
Registration protocol. The main entities involved in the architecture Registration protocol. The main entities involved in the architecture
are a group controller/key server (GCKS), the receiver(s), and the are the group controller/key server (GCKS), the receiver(s), and the
sender(s). sender(s).
In MIKEY, the sender could act as GCKS and push down keys to the In MIKEY, the sender could act as GCKS and push down keys to the
receiver(s). receiver(s).
Note that e.g., in a SIP-initiated call, the sender may also be a Note that e.g., in a SIP-initiated call, the sender may also be a
receiver. As MIKEY addresses small interactive groups, a member may receiver. As MIKEY addresses small interactive groups, a member may
dynamically change between being a sender and receiver (or being both dynamically change between being a sender and receiver (or being both
simultaneously). simultaneously).
3. Basic Key Transport and Exchange Methods 3. Basic Key Transport and Exchange Methods
The following sub-sections define three different methods to The following sub-sections define three different methods to
transport/establish a TEK Generation Key (TGK): with the use of a transport/establish a TGK: with the use of a pre-shared key, public-
pre-shared key, public-key encryption, and Diffie-Hellman (DH) key key encryption, and Diffie-Hellman (DH) key exchange. In the
exchange. In the following we for simplicity assume unicast following we for simplicity assume unicast communication. In addition
communication. In addition to the TGK, a random "nonce", denoted to the TGK, a random "nonce", denoted RAND, is also transported. In
RAND, is also transported. In all three cases, the TGK and RAND all three cases, the TGK and RAND values are then used to derive TEKs
values are then used to derive TEKs as described in Section 4.1.4. as described in Section 4.1.3. A timestamp is also sent, to avoid
replay attacks (see Section 5.4).
The pre-shared key method and the public-key method are both based on The pre-shared key method and the public-key method are both based on
key transport mechanisms, where the actual TGK is pushed (securely) key transport mechanisms, where the actual TGK is pushed (securely)
to the recipient(s). In the Diffie-Hellman method, the actual TGK is to the recipient(s). In the Diffie-Hellman method, the actual TGK is
instead derived from the Diffie-Hellman values exchanged between the instead derived from the Diffie-Hellman values exchanged between the
peers. peers.
The pre-shared case is, by far, the most efficient way to handle the The pre-shared case is, by far, the most efficient way to handle the
key transport due to the use of symmetric cryptography only. This key transport due to the use of symmetric cryptography only. This
approach has also the advantage that only a small amount of data has approach has also the advantage that only a small amount of data has
to be exchanged. Of course, the problematic issue is scalability as to be exchanged. Of course, the problematic issue is scalability as
it is not always feasible to share individual keys with a large group it is not always feasible to share individual keys with a large group
of peers. Therefore, this case mainly addresses scenarios such as of peers. Therefore, this case mainly addresses scenarios such as
server-to-client and also those cases where the public-key modes have server-to-client and also those cases where the public-key modes have
already been used thus allowing to "cache" a symmetric key (see already been used thus allowing to "cache" a symmetric key (see below
below and Section 3.2). and Section 3.2).
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. Of course, it is possible to use public distribution of public keys. Of course, it is possible to use public
keys as pre-shared keys (e.g. by using self-signed certificates). It keys as pre-shared keys (e.g. by using self-signed certificates). It
should also be noted that, as mentioned above, this method may be should also be noted that, as mentioned above, this method may be
used to establish a "cached" symmetric key that later can be used to used to establish a "cached" symmetric key that later can be used to
establish subsequent TGKs by using the pre-shared key method (hence, establish subsequent TGKs by using the pre-shared key method (hence,
the subsequent request can be executed more efficiently). the subsequent request can be executed more efficiently).
The Diffie-Hellman (DH) key agreement method has in general a higher The Diffie-Hellman (DH) key agreement method has in general a higher
resource consumption (both computationally and in bandwidth) than the resource consumption (both computationally and in bandwidth) than the
previous ones. However, it has the advantage of providing perfect previous ones, and needs certificates as the public-key case.
forward secrecy (PFS) and flexibility by allowing implementation in However, it has the advantage of providing perfect forward secrecy
several different finite groups. (PFS) and flexibility by allowing implementation in several different
finite groups.
Note that by using the DH method, the two involved parties will Note that by using the DH method, the two involved parties will
generate a unique random key (which neither of the parties are likely generate a unique unpredictable random key. Therefore, it is not
to significantly affect the outcome of). Therefore, it is not
possible to use this DH method to establish a group TEK (as the possible to use this DH method to establish a group TEK (as the
different parties in the group would end up with different TEKs). It different parties in the group would end up with different TEKs). It
is not the intention of the DH method to work in this scenario, but is not the intention of the DH method to work in this scenario, but
be a good alternative in the special peer-to-peer case. to be a good alternative in the special peer-to-peer case.
The following general notation is used: The following general notation is used:
HDR: The general MIKEY header, which includes MIKEY CSB related data HDR: The general MIKEY header, which includes MIKEY CSB related data
(e.g. CSB ID) and information mapping to the specific security (e.g. CSB ID) and information mapping to the specific security
protocol used. See Section 6.1 for payload definition. protocol used. See Section 6.1 for payload definition.
T: The timestamp. See Section 6.6 for payload definition and also T: The timestamp, used mainly to prevent replay attacks. See
Section 5.4 for other timestamp related information. Section 6.6 for payload definition and also Section 5.4 for other
timestamp related information.
IDx: The identity of x. See Section 6.7 for payload definition. IDx: The identity of entity x (i=Initiator, r=Responder). See
Section 6.7 for payload definition.
RAND: Random/pseudorandom byte-string, which is always included in RAND: Random/pseudo-random byte-string, which is always included in
the first message from the Initiator. It is not included in update the first message from the Initiator. RAND is used as freshness value
messages of a CSB. See Section 6.11 for payload definition. for the key generation. It is not included in update messages of a
CSB. See Section 6.11 for payload definition. For randomness
recommendations for security, see [RAND].
SP: The security policies for the data security protocol. See SP: The security policies for the data security protocol. See
Section 6.10 for payload definition. Section 6.10 for payload definition.
3.1. Pre-shared key 3.1. Pre-shared key
In this method, the pre-shared secret key, s, is used to derive key In this method, the pre-shared secret key, s, is used to derive key
material for both the encryption (encr_key) and the integrity material for both the encryption (encr_key) and the integrity
protection (auth_key) as described in Section 4.1.5. The encryption protection (auth_key) of the MIKEY messages, as described in Section
and authentication transforms are described in Section 4.2. 4.1.4. The encryption and authentication transforms are described in
Section 4.2.
Initiator Responder Initiator Responder
I_MESSAGE = I_MESSAGE =
HDR, T, RAND, [IDi], HDR, T, RAND, [IDi],
{SP}, KEMAC ---> {SP}, KEMAC --->
R_MESSAGE = R_MESSAGE =
[<---] HDR, T, [IDr], V [<---] HDR, T, [IDr], V
The main objective of the Initiator's message is to transport one or The main objective of the Initiator's message (I_MESSAGE) is to
more TGKs and a set of data protocol parameters to the Responder in a transport one or more TGKs (carried into KEMAC) and a set of security
secure manner. As the verification message from the Responder is parameters (SPs) to the Responder in a secure manner. As the
optional, the Initiator indicates in the HDR whether it requires a verification message from the Responder is optional, the Initiator
verification message or not from the Responder. indicates in the HDR whether it requires a verification message or
not from the Responder.
KEMAC = E(encr_key, {TGK}) || MAC KEMAC = E(encr_key, {TGK}) || MAC
The KEMAC payload contains a set of encrypted sub-payloads and a MAC. The KEMAC payload contains a set of encrypted sub-payloads and a MAC.
Each sub-payload includes a, by the Initiator, randomly and Each sub-payload includes a, by the Initiator, randomly and
independently chosen TGK (and possible other related parameters, independently chosen TGK (and possible other related parameters,
e.g., the key lifetime). The MAC is a Message Authentication Code e.g., the key lifetime). The MAC is a Message Authentication Code
covering the entire MIKEY message (with the exception of the MAC covering the entire MIKEY message using the authentication key,
field itself) using the authentication key, auth_key. See Section 6.2 auth_key. See Section 6.2 for payload definition and Section 5.2 for
for payload definition and Section 5.2 for exact definition of the exact definition of the MAC calculation.
MAC calculation.
The main objective of the verification message from the Responder is The main objective of the verification message from the Responder is
to obtain mutual authentication. The verification, V, is a MAC to obtain mutual authentication. The verification message, V, is a
computed over the Responder's entire message (with the exception of MAC computed over the Responder's entire message, the timestamp (the
the Verification MAC field), the timestamp (that was included in the same as the one that was included in the Initiator's message), and
Initiator's message), and the two parties identities, using the the two parties identities, using the authentication key. See also
authentication key. See also Section 5.2 for the exact definition of Section 5.2 for the exact definition of the Verification MAC
the Verification MAC calculation and Section 6.9 for payload calculation and Section 6.9 for payload definition.
definition.
The ID fields are optional. However, leaving out an ID can only be The ID fields SHOULD be included, but they MAY be left out when it
done when it can be expected that the peer already knows the other can be expected that the peer already knows the other party's ID
party's ID (otherwise it cannot look up the pre-shared key). This (otherwise it cannot look up the pre-shared key). This could e.g. be
could e.g. be the case if the ID is extracted from SIP. the case if the ID is extracted from SIP.
This method is MANDATORY to implement.
3.2. Public-key encryption 3.2. Public-key encryption
Initiator Responder Initiator Responder
I_MESSAGE = I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], {SP}, HDR, T, RAND, [IDi|CERTi], {SP},
[CHASH], KEMAC, PKE, SIGNi ---> KEMAC, [CHASH], PKE, SIGNi --->
R_MESSAGE = R_MESSAGE =
[<---] HDR, T, [IDr], V [<---] HDR, T, [IDr], V
The main objective of the Initiator's message is to transport one or As in the previous case, the main objective of the Initiator's
more TGKs and a set of data protocol parameters to the Responder in a message is to transport one or more TGKs and a set of security
secure manner. This is done using an envelope approach where the TGKs parameters to the Responder in a secure manner. This is done using an
are encrypted (and integrity protected) with keys derived from a envelope approach where the TGKs are encrypted (and integrity
randomly/pseudorandomly chosen "envelope key". The envelope key is protected) with keys derived from a randomly/pseudo-randomly chosen
sent to the Responder encrypted with the public key of the Responder. "envelope key". The envelope key is sent to the Responder encrypted
with the public key of the Responder.
The PKE contains the encrypted envelope key: PKE = E(PKr, env_key).
It is encrypted using the Responder's public key (PKr). If the
Responder posses several public keys, the Initiator can indicate the
key used in the CHASH payload (see Section 6.8).
The KEMAC contains a set of encrypted sub-payloads and a MAC: The KEMAC contains a set of encrypted sub-payloads and a MAC:
KEMAC = E(encr_key, IDi || {TGK}) || MAC KEMAC = E(encr_key, IDi || {TGK}) || MAC
The first sub-payload is the identity of the Initiator (not a The first payload (IDi) in KEMAC is the identity of the Initiator
certificate, but generally the same ID as the one specified in the (not a certificate, but generally the same ID as the one specified in
certificate). Each of the following sub-payloads includes a, by the the certificate). Each of the following payloads (TGK) includes a, by
Initiator, randomly and independently chosen TGK (and possible other the Initiator, randomly and independently chosen TGK (and possible
related parameters, e.g., the key lifetime). The encrypted part is other related parameters, e.g., the key lifetime). The encrypted part
then followed by a MAC, which is calculated over the KEMAC payload is then followed by a MAC, which is calculated over the KEMAC
with exception of the MAC field. The encr_key and the auth_key are payload. The encr_key and the auth_key are derived from the envelope
derived from the envelope key, env_key, see Section 4.1.5. See also key, env_key, as specified in Section 4.1.4. See also Section 6.2 for
Section 6.2 for payload definition. payload definition.
The PKE contains the encrypted envelope key: PKE = E(PKr, env_key).
It is encrypted using the Responder's public key. If the Responder
posses several public keys, the Initiator can use CHASH to indicate
the key used.
The SIGNi is a signature covering the entire MIKEY message (excluding The SIGNi is a signature covering the entire MIKEY message, using the
SIGN itself), using the Initiator's signature key (see also Section Initiator's signature key (see also Section 5.2 for the exact
5.2 for the exact definition). definition).
The main objective of the verification message from the Responder is The main objective of the verification message from the Responder is
to obtain mutual authentication. As the verification message V from to obtain mutual authentication. As the verification message V from
the Responder is optional, the Initiator indicates in the HDR whether the Responder is optional, the Initiator indicates in the HDR whether
it requires a verification message or not from the Responder. V is it requires a verification message or not from the Responder. V is
calculated in the same way as for the one in the pre-shared key mode calculated in the same way as in the pre-shared key mode (see also
(see also Section 5.2 for the exact definition). See Section 6.9 for Section 5.2 for the exact definition). See Section 6.9 for payload
payload definition. definition.
Note that there will be one encrypted IDi and possibly also one Note that there will be one encrypted IDi and possibly also one
unencrypted IDi. The encrypted one is together with the MAC used as a unencrypted IDi. The encrypted one is together with the MAC used as a
countermeasure for certain man-in-the-middle attacks (while the countermeasure for certain man-in-the-middle attacks, while the
unencrypted is always useful for the Responder to immediately unencrypted is always useful for the Responder to immediately
identify the Initiator). The encrypted IDi MUST always be verified to identify the Initiator. The encrypted IDi MUST always be verified to
be equal with the expected IDi. be equal with the expected IDi.
It is possible to cache the envelope key, so that it can be used as a It is possible to cache the envelope key, so that it can be used as a
pre-shared key. It is not recommended to cache this key indefinitely pre-shared key. It is not recommended to cache this key indefinitely
(however it is up to the local policy to decide this). This function (however it is up to the local policy to decide this). This function
may be very convenient during the life-time of a Crypto Session may be very convenient during the lifetime of a CSB, if a new crypto
Bundle, if a new crypto session needs to be added (or an expired one session needs to be added (or an expired one removed). Then, the pre-
removed). Then, the pre-shared key can be used, instead of the public shared key can be used, instead of the public keys (see also Section
keys (see also Section 4.5). If the Initiator indicates that the 4.5). If the Initiator indicates that the envelope key should be
envelope key should be cached, the key is at least to be cached cached, the key is at least to be cached during the lifetime of the
during the life-time of the entire CSB. entire CSB.
The ID fields and certificate are optional. However, leaving out an The cleartext ID fields and certificate SHOULD be included, but they
ID (or certificate) can only be done when it can be expected that the MAY be left out when it can be expected that the peer already knows
peer already knows the other party's ID (or can obtain the the other party's ID, or can obtain the certificate in some other
certificate in some other manner). This could e.g. be the case if the manner. This could e.g. be the case if the ID is extracted from SIP.
ID is extracted from SIP.
For certificate handling, authorization and policies, see For certificate handling, authorization and policies, see Section
Section 4.3. 4.3.
This method is MANDATORY to implement.
3.3. Diffie-Hellman key exchange 3.3. Diffie-Hellman key exchange
For a fixed, agreed upon, cyclic group, (G,*), we let g denote a For a fixed, agreed upon, cyclic group, (G,*), we let g denote a
generator for this group. Choices for the parameters are given in generator for this group. Choices for the parameters are given in
Section 4.2.7. The other transforms below are described in Section Section 4.2.7. The other transforms below are described in Section
4.2. 4.2.
With this method only one key is created, i.e. the DH-key, which is This method creates a DH-key, which is used as the TGK. This method
used as the TGK. This implies that this method cannot be used to cannot be used to create group keys, only be used to create single
create group keys, but only be used to create single peer-to-peer peer-to-peer keys. This method is OPTIONAL to implement.
keys. This method is OPTIONAL to implement.
Initiator Responder Initiator Responder
I_MESSAGE = I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], HDR, T, RAND, [IDi|CERTi],
{SP}, DHi, SIGNi ---> {SP}, DHi, SIGNi --->
R_MESSAGE = R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi, <--- HDR, T, [IDr|CERTr], IDi,
DHr, DHi, SIGNr DHr, DHi, SIGNr
The main objective of the Initiator's message is to, in a secure way, The main objective of the Initiator's message is to, in a secure way,
provide the Responder with its DH value (i.e., DHi = g^(xi), where xi provide the Responder with its DH value (DHi) g^(xi), where xi MUST
MUST be randomly/pseudorandomly and secretly chosen) and a set of be randomly/pseudo-randomly and secretly chosen, and a set of
data protocol parameters. security protocol parameters.
The SIGNi is a signature covering the Initiator's MIKEY message, The SIGNi is a signature covering the Initiator's MIKEY message,
I_MESSAGE, using the Initiator's signature key. I_MESSAGE, using the Initiator's signature key (see Section 5.2 for
the exact definition).
The main objective of the Responder's message is to, in a secure way, The main objective of the Responder's message is to, in a secure way,
provide the Initiator with its own DH value (i.e., DHr = g^(xr), provide the Initiator with the Responder's value (DHr) g^(xr), where
where xr MUST be randomly/pseudorandomly and secretly chosen). xr MUST be randomly/pseudo-randomly and secretly chosen. The
timestamp that is included in the answer is the same as the one
included in the Initiator's message.
The SIGNr is a signature covering the Responder's MIKEY message, The SIGNr is a signature covering the Responder's MIKEY message,
R_MESSAGE, using the Responder's signature key (see also Section 5.2 R_MESSAGE, using the Responder's signature key (see Section 5.2 for
for the exact definition). the exact definition).
The group parameters (e.g., the group G, the generator g, etc) are a The DH group parameters (e.g., the group G, the generator g, etc) are
set of parameters chosen by the Initiator and signaled to the chosen by the Initiator and signaled to the Responder. Both parties
responder. Both parties calculate the TGK, g^(xi*xr) from the calculate the TGK, g^(xi*xr) from the exchanged DH-values.
exchanged DH-values.
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 certificates before the setup. Instead, posses any of the Responder's certificates before the setup. Instead,
it is sufficient that the responder includes it's signing certificate it is sufficient that the Responder includes its signing certificate
in the response. in the response.
The ID fields and certificate are optional. However, leaving out an The ID fields and certificate SHOULD be included, but they MAY be
ID (or certificate) can only be done when it can be expected that the left out when it can be expected that the peer already knows the
peer already knows the other party's ID (or can obtain the other party's ID (or can obtain the certificate in some other
certificate in some other manner). This could e.g. be the case if the manner). This could e.g. be the case if the ID is extracted from SIP.
ID is extracted from SIP.
For certificate handling, authorization and policies, see For certificate handling, authorization and policies, see
Section 4.3. Section 4.3.
4. Selected Key Management Functions 4. Selected Key Management Functions
MIKEY manages symmetric keys in two main ways. Firstly, following key
transport or key exchange of TGK(s) (and other parameters) as defined
by any of the above three methods, MIKEY maintains a mapping between
Data SA identifiers and Data SAs, where the identifiers used depend
on the security protocol in question, see Section 4.4. Thus, when the
security protocol requests a Data SA, given such a Data SA
identifier, an up-to-date Data SA will be obtained. In particular,
correct keying material, TEK(s), might need to be derived. The
derivation of TEK(s) (and other keying material) is done from a TGK
and is described in Section 4.1.3.
Secondly, for use within MIKEY itself, two key management procedures
are needed:
* in the pre-shared case, deriving encryption and authentication key
material from a single pre-shared key, and
* in the public key case, deriving similar key material from the
transported envelope key.
These two key derivation methods are specified in section 4.1.4.
All the key derivation functionality mentioned above is based on a
pseudo-random function, defined next.
4.1. Key Calculation 4.1. Key Calculation
We define in the following a general method (pseudo random function) We define in the following a general method (pseudo-random function)
to derive one or more keys from a "master" key. This method is used to derive one or more keys from a "master" key. This method is used
to derive: to derive:
* TEKs from a TGK and the RAND value, * TEKs from a TGK and the RAND value,
* encryption, authentication, or salting key from a pre-shared/ * encryption, authentication, or salting key from a pre-shared/
envelope key and the RAND value. envelope key and the RAND value.
4.1.1. Assumptions 4.1.1. Assumptions
We assume that the following parameters are in place: We assume that the following parameters are in place:
csb_id: Crypto Session Bundle ID (32-bits unsigned integer) csb_id: Crypto Session Bundle ID (32-bits unsigned integer)
cs_id: The Crypto Session ID (8-bits unsigned integer) cs_id : the Crypto Session ID (8-bits unsigned integer)
RAND: An (at least) 128-bit (pseudo)random bit-string sent by the RAND : an (at least) 128-bit (pseudo-)random bit-string sent by the
Initiator in the initial exchange. Initiator in the initial exchange.
The key derivation method has the following input parameters: The key derivation method has the following input parameters:
inkey: the input key to the derivation function. inkey : the input key to the derivation function
inkey_len: the length in bits of the input key. inkey_len : the length in bits of the input key
label: a specific label, dependent on the type of the key to be label: a specific label, dependent on the type of the key to be
derived, the RAND, and the session IDs. derived, the RAND, and the session IDs
outkey_len: desired length in bits of the output key. outkey_len: desired length in bits of the output key.
The key derivation method has the following output: The key derivation method has the following output:
outkey: the output key of desired length. outkey: the output key of desired length.
4.1.2. Notation 4.1.2. Default PRF Description
Let HMAC be the SHA1 based message authentication function, see Let HMAC be the SHA-1 based message authentication function, see
[HMAC,SHA1]. Similar to [TLS], define: [HMAC], [SHA-1]. Similar to [TLS], define:
P (s, label, m) = HMAC (s, A_1 || label) || P (s, label, m) = HMAC (s, A_1 || label) ||
HMAC (s, A_2 || label) || ... HMAC (s, A_2 || label) || ...
HMAC (s, A_m || label) HMAC (s, A_m || label)
where where
A_0 = label, A_0 = label,
A_i = HMAC (s, A_(i-1)). A_i = HMAC (s, A_(i-1))
s is the input key
While SHA-1 is the default, HMAC using other hash function MAY be m is a positive integer.
used, see Section 4.2.2.
4.1.3. PRF Description Values of label depend on the case in which the PRF is invoked, and
values are specified in the following for the default PRF. Thus, note
that other PRFs later added to MIKEY MAY specify different input
parameters.
The following procedure describes a pseudo-random function, denoted The following procedure describes a pseudo-random function, denoted
PRF(inkey,label), applied to compute the output key, outkey: PRF(inkey,label), based on the above P-function, applied to compute
the output key, outkey:
* let n = inkey_len / 512, rounded up to the nearest integer * let n = inkey_len / 512, rounded up to the nearest integer if not
already an integer
* split the inkey into n blocks, inkey = s_1 || ... || s_n, where all * split the inkey into n blocks, inkey = s_1 || ... || s_n, where all
s_i, except possibly s_n, are 512 bits each s_i, except possibly s_n, are 512 bits each
* let m = outkey_len / 160, rounded up to the nearest integer * let m = outkey_len / 160, rounded up to the nearest integer if not
already an integer
If another hash function than SHA1 is used, "512" and "160" SHALL be (The values "512" and "160" equals the input block-size and output
replaced by the appropriate input/output block-sizes of that hash size, respectively, of the SHA-1 hash as part of the P-
function. function.)
Then, the output key, outkey, is obtained as the outkey_len most Then, the output key, outkey, is obtained as the outkey_len most
significant bits of significant bits of
PRF(inkey, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ... PRF(inkey, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ...
XOR P(s_n, label, m). XOR P(s_n, label, m).
4.1.4. Generating keys from TGK 4.1.3. Generating keys from TGK
The key derivation method should be executed with the following In the following, we describe how keying material is derived from a
parameters to generate a TEK: TGK, thus assuming that mapping of Data SA identifier to the correct
TGK has already been done according to Section 4.4.
The key derivation method SHALL be executed using the above PRF with
the following input parameters:
inkey: TGK inkey: TGK
inkey_len: bit length of TGK inkey_len: bit length of TGK
label: 0x2AD01C64 || cs_id || csb_id || RAND label : constant || cs_id || csb_id || RAND
outkey_len: bit length of the output TEK. outkey_len : bit length of the output key.
If the security protocol does not support key derivation for The constant part of label depends on the type of key that is to be
authentication and encryption itself from the TEK, separate generated. The constant 0x2AD01C64 is used to generate a TEK from
authentication and encryption keys MAY directly be created for the TGK. If the security protocol itself does not support key derivation
for authentication and encryption from the TEK, separate
authentication and encryption keys MAY be created directly for the
security protocol by replacing 0x2AD01C64 with 0x1B5C7973 and security protocol by replacing 0x2AD01C64 with 0x1B5C7973 and
0x15798CEF respectively, and outkey_len by the desired key-length(s) 0x15798CEF respectively, and outkey_len by the desired key-length(s)
in each case. in each case.
A salt key can be derived from the TGK as well. This is done by using A salt key can be derived from the TGK as well, by using the constant
the constant 0x39A2C14B. 0x39A2C14B. Note that the Key data sub-payload (Section 6.13) can
carry a salt. The security protocol in need of the salt key, SHALL
use the salt key carried in the Key data sub-payload (in the pre-
shared and public-key case), when present. If that is not sent, then
it is possible to derive the salt key via the key derivation
function, as described above.
Note that the 32-bit constant integers (i.e. 0x2AD01C64 or the one The table below summarizes the values of constant, used to generate
replacing it) are taken from the decimal digits of e (i.e. keys from a TGK.
2.7182...), and where each constant consist of nine decimals digits
(e.g. the first nine decimal digits 718281828 = 0x2AD01C64). The
strings of nine decimal digits are not chosen at random, but as
consecutive "chunks" from the decimal digits of e.
4.1.5. Generating keys from an envelope/pre-shared key constant | derived key from the TGK
--------------------------------------
0x2AD01C64 | TEK
0x1B5C7973 | authentication key
0x15798CEF | encryption key
0x39A2C14B | salting key
Table 4.1.3: Values of constant for the derivation of keys from TGK.
Note that these 32-bit constant values (listed in the table above)
are 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). The strings of nine decimal
digits are not chosen at random, but as consecutive "chunks" from the
decimal digits of e.
4.1.4. Generating keys for MIKEY messages from an envelope/pre-shared
key
This derivation is to form the symmetric encryption key (and salting This derivation is to form the symmetric encryption key (and salting
key) for the encryption of the TGK in the pre-shared key and public key) for the encryption of the TGK in the pre-shared key and public
key methods. This is also used to derive the symmetric key used for key methods. This is also used to derive the symmetric key used for
the message authentication code in these messages (and the the message authentication code in these messages, and the
corresponding verification messages). Hence, this derivation is corresponding verification messages. Hence, this derivation is needed
needed in order to get different keys for the encryption and the MAC in order to get different keys for the encryption and the MAC (and in
(and in the case of the pre-shared key, it will result in fresh key the case of the pre-shared key, it will result in fresh key material
material for each new CSB). for each new CSB). The parameters for the default PRF are here:
inkey: the envelope key or the pre-shared key inkey: the envelope key or the pre-shared key
inkey_len: the bit length of inkey inkey_len: the bit length of inkey
label: 0x150533E1 || 0xFF || csb_id || RAND (for encryption key) label : constant || 0xFF || csb_id || RAND
or
0x2D22AC75 || 0xFF || csb_id || RAND (for auth. key)
or
0x29B88916 || 0xFF || csb_id || RAND (for salting key)
outkey_len: desired bit length of the outkey_len : desired bit length of the output key.
authentication/encryption/salting key.
The constant part of label depends on the type of key that is to be
generated from an envelope/pre-shared key, as summarized below.
constant | derived key
--------------------------------------
0x150533E1 | encryption key
0x2D22AC75 | authentication key
0x29B88916 | salt key
Table 4.1.4: Values of constant for the derivation of keys from an
envelope/pre-shared key.
4.2 Pre-defined Transforms and Timestamp Formats 4.2 Pre-defined Transforms and Timestamp Formats
This section identifies standard transforms for MIKEY. The following This section identifies standard transforms for MIKEY. The following
transforms are mandatory to implement and support in the respective transforms are mandatory to implement and support in the respective
case. New transforms can be added in the future (see Section 4.2.9 case. New transforms can be added in the future (see Section 4.2.9
for further guidelines). for further guidelines).
4.2.1 Hash functions 4.2.1 Hash functions
In MIKEY, SHA-1 is the default hash function that is mandatory to In MIKEY, SHA-1 is the default hash function that is MANDATORY to
implement. implement.
4.2.2 Pseudo random number generator and PRF 4.2.2 Pseudo-random number generator and PRF
A cryptographically secure random or pseudo random number generator A cryptographically secure random or pseudo-random number generator
MUST be used for the generation of the keying material and nonces, MUST be used for the generation of the keying material and nonces,
e.g. [BMGL]. However, it is implementation specific which one to use e.g. [BMGL]. However, it is implementation specific which one to use
(as the choice will not affect the interoperability). (as the choice will not affect the interoperability).
For the key derivations, the PRF specified in Section 4.1, using SHA- For the key derivations, the PRF specified in Section 4.1, is
1 is mandatory to implement. This PRF MAY be extended by using SHA- MANDATORY to implement. Other PRFs MAY be added by writing standard-
256, SHA-384, or SHA-512, instead of SHA-1. However, it is not track RFCs specifying the PRF constructions and their exact use
mandatory to support these. within MIKEY.
4.2.3 Key data transport encryption 4.2.3 Key data transport encryption
The default and mandatory-to-implement key transport encryption is The default and mandatory-to-implement key transport encryption is
AES in counter mode, as defined in [SRTP], using a 128-bit key as AES in counter mode, as defined in [SRTP], using a 128-bit key as
derived in Section 4.1.5, and using initialization vector derived in Section 4.1.4, and using initialization vector
IV = [S XOR (0x0000 || CSB ID || T)] || 0x0000, IV = (S XOR (0x0000 || CSB ID || T)) || 0x0000,
where S is a 112-bit salting key, also derived as in Section 4.1.5, where S is a 112-bit salting key, also derived as in Section 4.1.4,
and where T is the timestamp sent by the Initiator. and where T is the 64-bit timestamp sent by the Initiator.
Note: this restricts the maximum size that can be encrypted to 2^23 Note: this restricts the maximum size that can be encrypted to 2^23
bits, which is still enough for all practical purposes. bits, which is still enough for all practical purposes [SRTP].
The NULL encryption algorithm (i.e., no encryption) can be used (but The NULL encryption algorithm (i.e., no encryption) can be used (but
is not mandatory to implement). Note that this MUST NOT be used is OPTIONAL to implement). Note that this MUST NOT be used unless the
unless the underlying protocols can guarantee the security. The main underlying protocols can guarantee the security. The main reason for
reason for including this is for certain specific SIP scenarios, including this is for certain specific SIP scenarios, where SDP is
where SDP is protected end-to-end. For this scenario, MIKEY MAY be protected end-to-end. For this scenario, MIKEY MAY be used with the
used with the pre-shared key method and the NULL encryption and pre-shared key method and the NULL encryption and NULL authentication
authentication algorithm while relying on the security of SIP. Use algorithm (see Section 4.2.4) while relying on the security of SIP.
this option with caution! Use this option with caution!
The AES key wrap function [AESKW] is included as an optional (but not The AES key wrap function [AESKW] is included as an OPTIONAL to
mandatory to implement) method. If the key wrap function is used, the implement method. If the key wrap function is used in the public key
NULL MAC is RECOMMENDED to be used when using the public key method method, the NULL MAC is RECOMMENDED as the key wrap itself will
(NOT the pre-shared key method) as the key wrap itself will provide provide integrity of the encrypted content (note though that the NULL
integrity of the keys. The 128-bit key and a 64-bit salt, S, are MAC SHOULD NOT be used in the pre-shared key case, as the MAC in that
derived in accordance to Section 4.1.5 and the key wrap IV is then case covers the entire message). The 128-bit key and a 64-bit salt,
set to S. S, are derived in accordance to Section 4.1.4 and the key wrap IV is
then set to S.
4.2.4 MAC and Verification Message function 4.2.4 MAC and Verification Message function
MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1 MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1
as the mandatory to implement method, see [HMAC]. Authentication keys as the MANDATORY to implement method, see [HMAC]. Authentication keys
are derived according to Section 4.1.5. Note that the authentication are derived according to Section 4.1.4. Note that the authentication
key size MUST be equal to the size of the hash function's output key size SHOULD be equal to the size of the hash function's output
(e.g. for HMAC-SHA-1, a 160-bit authentication key is used). (e.g. for HMAC-SHA-1, a 160-bit authentication key is used) [HMAC].
The NULL authentication algorithm (i.e., no MAC) can be used together The NULL authentication algorithm (i.e., no MAC) can be used together
with the NULL encryption algorithm (but is not mandatory to with the NULL encryption algorithm (but is OPTIONAL to implement).
implement). Note that this MUST NOT be used unless the underlying Note that this MUST NOT be used unless the underlying protocols can
protocols can guarantee the security. The main reason for including guarantee the security. The main reason for including this is for
this is for certain specific SIP scenarios, where SDP is protected certain specific SIP scenarios, where SDP is protected end-to-end.
end-to-end. For this scenario, MIKEY MAY be used with the pre-shared For this scenario, MIKEY MAY be used with the pre-shared key method
key method and the NULL encryption and authentication algorithm while and the NULL encryption and authentication algorithm while relying on
relying on the security of SIP. Use this option with caution! the security of SIP. Use this option with caution!
4.2.5 Envelope Key encryption 4.2.5 Envelope Key encryption
The public key encryption algorithm applied is defined by, and The public key encryption algorithm applied is defined by, and
dependent on the certificate used. dependent on the certificate used. It is MANDATORY to support RSA
PKCS#1, v1.5, and it is RECOMMENDED to also support RSA OAEP [PSS].
4.2.6 Digital Signatures 4.2.6 Digital Signatures
The signature algorithm applied is defined by, and dependent on the The signature algorithm applied is defined by, and dependent on the
certificate used. certificate used. It is MANDATORY to support RSA PKCS#1, v1.5, and it
is RECOMMENDED to also support RSA PSS [PSS].
4.2.7 Diffie-Hellman Groups 4.2.7 Diffie-Hellman Groups
The Diffie-Hellman key exchange uses OAKLEY 5 [OAKLEY] as mandatory The Diffie-Hellman key exchange uses OAKLEY 5 [OAKLEY] as mandatory
to implement. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are to implement. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are
not mandatory to implement). OPTIONAL to implement).
See Section 4.2.9 for the guidelines to specify a new DH Group to be See Section 4.2.9 for the guidelines to specify a new DH Group to be
used within MIKEY. used within MIKEY.
4.2.8. Timestamps 4.2.8. Timestamps
The timestamp is as defined in NTP [NTP], i.e. a 64-bit number in The 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 seconds relative to 0h on 1 January 1900. An implementation MUST be
aware of (and take into account) the fact that the counter will aware of (and take into account) the fact that the counter will
overflow approximately every 136th year. It is RECOMMENDED that the overflow approximately every 136th year. It is RECOMMENDED that the
time is always specified in UTC. time is always specified in UTC.
4.2.9. Adding new parameters to MIKEY 4.2.9. Adding new parameters to MIKEY
There are two different parameter sets that can be added to MIKEY. There are two different parameter sets that can be added to MIKEY.
The first is a set of MIKEY transforms (needed for the exchange The first is a set of MIKEY transforms (needed for the exchange
itself), and the second is the data security protocol policies/ itself), and the second is the Data SAs.
parameters.
New transforms and parameters SHALL be added by registering (with New transforms and parameters (including new policies) SHALL be added
IANA) a new number for the concerned payload, and also if necessary, by registering with IANA (according to [RFC2434], see also Section
10) a new number for the concerned payload, and also if necessary,
document how the new transform/parameter is used. Sometimes it might document how the new transform/parameter is used. Sometimes it might
be enough to point to an already specified document for the usage, be enough to point to an already specified document for the usage,
e.g., when adding a new already standardized hash function. e.g., when adding a new already standardized hash function.
In the case of adding a new DH group, the group needs to be specified In the case of adding a new DH group, the group MUST be specified in
in a companion RFC (it is RECOMMENDED that the specified group uses a companion standard-track RFC (it is RECOMMENDED that the specified
the same format as used in [OAKLEY]). A number can then be assigned group uses the same format as used in [OAKLEY]). A number can then be
by IANA for such a group to be used in MIKEY. assigned by IANA for such a group to be used in MIKEY.
When adding support for a new data security protocol, the following When adding support for a new data security protocol, the following
MUST be specified: MUST be specified:
* A map sub payload (see Section 6.1). This is used to be able to map * A map sub-payload (see Section 6.1). This is used to be able to map
a crypto session to the right instance of the data security protocol a crypto session to the right instance of the data security protocol
and possibly also to provide individual parameters for each data and possibly also to provide individual parameters for each data
security protocol. security protocol.
* a policy payload, i.e., specification of parameters and supported * A policy payload, i.e., specification of parameters and supported
values. values.
* general guidelines of usage. * General guidelines of usage.
4.3. Certificates, Policies and Authorization 4.3. Certificates, Policies and Authorization
4.3.1. Certificate handling 4.3.1. Certificate handling
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
(c.f. [X.509]). The following observations can, however, be made: (c.f. [X.509]). The following observations can, however, be made:
* The Initiator typically has to find the certificate of the * The Initiator typically has to find the certificate of the
skipping to change at page 21, line 4 skipping to change at page 22, line 48
These authorization policies address the MIKEY scenarios a-c of These authorization policies address the MIKEY scenarios a-c of
Section 2.1, where the Initiator acts as the group owner and who is Section 2.1, where the Initiator acts as the group owner and who is
also the only one that can invite others. This implies that for each also the only one that can invite others. This implies that for each
Responder, the distributed keys MUST NOT be re-distributed to other Responder, the distributed keys MUST NOT be re-distributed to other
parties. parties.
In a many-to-many situation, where the group control functions are In a many-to-many situation, where the group control functions are
distributed (and/or where it is possible to delegate the group distributed (and/or where it is possible to delegate the group
control function to others), there MUST exist means to distribute control function to others), there MUST exist means to distribute
authorization information about who may be added to the group. authorization information about who may be added to the group.
However, it is out of scope for this document to specify how this However, it is out of scope for this document to specify how this
should be done. should be done.
For any broader communication situation, an external authorization For any broader communication situation, an external authorization
infrastructure may be used (following the assumptions of [GKMARCH]). infrastructure may be used (following the assumptions of [GKMARCH]).
4.3.3. Data Policies 4.3.3. Data Policies
Included in the message exchange, policies for the Data security Included in the message exchange, policies (i.e., security
protocol are transmitted. The policies are defined in a separate parameters) for the Data security protocol are transmitted. The
payload and are specific to the security protocol (see also Section policies are defined in a separate payload and are specific to the
6.10). Together with the keys, the validity period of these can also security protocol (see also Section 6.10). Together with the keys,
be specified. This can be done e.g., with an SPI (or SRTP MKI) or the validity period of these can also be specified. This can be done
with an Interval (e.g. a sequence number interval for SRTP), e.g., with an SPI (or SRTP MKI) or with an Interval (e.g. a sequence
depending on the security protocol. number interval for SRTP), depending on the security protocol.
New parameters can be added to a policy by documenting how they New parameters can be added to a policy by documenting how they
should be interpreted by MIKEY and also by registering new values in should be interpreted by MIKEY and also by registering new values in
the appropriate name space. If a completely new policy is needed, see the appropriate name space in IANA. If a completely new policy is
Section 4.2.9 for guidelines. needed, see Section 4.2.9 for guidelines.
4.4. Retrieving the Data SA 4.4. Retrieving the Data SA
The retrieval of a Data SA will depend on the security protocol as The retrieval of a Data SA will depend on the security protocol, as
different security protocols will have different characteristics. different security protocols will have different characteristics.
When adding support for a security protocol to MIKEY, some interface When adding support for a security protocol to MIKEY, some interface
of how the security protocol retrieves the Data SA from MIKEY MUST be of how the security protocol retrieves the Data SA from MIKEY MUST be
specified (together with policies that can be negotiated etc.). specified (together with policies that can be negotiated etc.).
For SRTP the SSRC (see [SRTP]) is one of the parameters used to For SRTP the SSRC (see [SRTP]) is one of the parameters used to
retrieve the Data SA. However, the SSRC is not sufficient. For the retrieve the Data SA (and e.g. the MKI may be used to indicate the
retrieval of the Data SA from MIKEY, it is RECOMMENDED that the MIKEY TGK/TEK used for the Data SA). However, the SSRC is not sufficient.
implementation supports a lookup using destination network address For the retrieval of the Data SA from MIKEY, it is RECOMMENDED that
and port together with SSRC. Note that MIKEY does not send network the MIKEY implementation support a lookup using destination network
addresses or ports. One reason for this is that they may not be known address and port together with SSRC. Note that MIKEY does not send
in advance, as well as if a NAT exists in-between, problems may network addresses or ports. One reason for this is that they may not
arise. When SIP or RTSP is used, the local view of the destination be known in advance, as well as if a NAT exists in-between, problems
address and port can be obtained from either SIP or RTSP. MIKEY can may arise. When SIP or RTSP is used, the local view of the
then use these addresses as the index for the Data SA lookup. destination address and port can be obtained from either SIP or RTSP.
MIKEY can then use these addresses as the index for the Data SA
lookup.
4.5. TGK re-keying and CSB updating 4.5. TGK re-keying and CSB updating
MIKEY provides the means to update the CSB (e.g. transporting a new MIKEY provides the means to update the CSB (e.g. transporting a new
TGK/TEK or adding a new Crypto Session to the CSB). The updating of TGK/TEK or adding a new Crypto Session to the CSB). The updating of
the CSB is done by the Initiator and performed by executing MIKEY the CSB is done by executing MIKEY again e.g. before a TEK expires,
again e.g. before a TEK expires, or when a new Crypto Session is or when a new Crypto Session is added to the CSB. Note that MIKEY
added to the CSB. Note that MIKEY does not provide re-keying in the does not provide re-keying in the GKMARCH sense, only updating of the
GKMARCH sense, only updating of the keys by normal unicast messages. keys by normal unicast messages.
When MIKEY is executed again to update the CSB, it is not necessary When MIKEY is executed again to update the CSB, it is not necessary
to include certificates and other information that was provided in to include certificates and other information that was provided in
the first exchange, i.e. all payloads that are static or optional to the first exchange, i.e. all payloads that are static or optional to
include may be left out (see Figure 4.1). include may be left out (see Figure 4.1).
The new message exchange uses the same CSB ID as the initial The new message exchange MUST use the same CSB ID as the initial
exchange, but a new timestamp. A new RAND is NOT included in the exchange, but MUST use a new timestamp. A new RAND MUST NOT be
message exchange (the RAND will only have affect in the Initial included in the message exchange (the RAND will only have effect in
exchange). New Crypto Sessions are added if desired in the update the Initial exchange). New Crypto Sessions are added if desired in
message. Note that a MIKEY update message does not need to contain the update message. Note that a MIKEY update message does not need to
new keying material (i.e., new TGK). In this case the crypto session contain new keying material (i.e., new TGK). In this case the crypto
continues to use the previously established keying material, while session continues to use the previously established keying material,
updating the new information. while updating the new information.
As explained in Section 3.2, the envelope key can be "cached" as a As explained in Section 3.2, the envelope key can be "cached" as a
pre-shared key (this is indicated by the Initiator in the first pre-shared key (this is indicated by the Initiator in the first
message sent). If so, the update message is a pre-shared key message message sent). If so, the update message is a pre-shared key message
(with the cached envelope key as the pre-shared key), i.e., it MUST (with the cached envelope key as the pre-shared key), i.e., it MUST
NOT be a public key message. If the public key message is used, but NOT be a public key message. If the public key message is used, but
the envelope key is not cached, the Initiator MUST provide a new the envelope key is not cached, the Initiator MUST provide a new
encrypted envelope key that can be used in the verification message. encrypted envelope key that can be used in the verification message.
However, the Initiator does not need to provide any other keys. However, the Initiator does not need to provide any other keys.
Figure 4.1 visualizes the update messages that can be sent, including Figure 4.1 visualizes the update messages that can be sent, including
the optional parts. The big difference from the original message is the optional parts. The big difference from the original message is
mainly that it is optional to include TGKs (or DH values in the DH mainly that it is optional to include TGKs (or DH values in the DH
method). See also Section 3 for more details of the specific methods. method). See also Section 3 for more details of the specific methods.
By definition, a Crypto Session Bundle can contain several Crypto By definition, a CSB can contain several CSs. A problem that then
Sessions. A problem that then might occur is to synchronize the TGK might occur is to synchronize the TGK re-keying if an SPI (or similar
re-keying if an SPI (or similar functionality, e.g., MKI) is not functionality, e.g., MKI in [SRTP]) is not used. It is therefore
used. It is therefore recommended that an SPI or MKI is used, if more RECOMMENDED that an SPI or MKI is used, if more than one CS is used.
than one Crypto Session is used.
Initiator Responder Initiator Responder
Pre-shared key method: Pre-shared key method:
I_MESSAGE = I_MESSAGE =
HDR, T, [IDi], {SP}, KEMAC ---> HDR, T, [IDi], {SP}, KEMAC --->
R_MESSAGE = R_MESSAGE =
[<---] HDR, T, [IDr], V [<---] HDR, T, [IDr], V
Public key method: Public key method:
I_MESSAGE = I_MESSAGE =
HDR, T, [IDi|CERTi], {SP}, [CHASH], HDR, T, [IDi|CERTi], {SP}, [KEMAC],
[KEMAC], PKE, SIGNi ---> [CHASH], PKE, SIGNi --->
R_MESSAGE = R_MESSAGE =
[<---] HDR, T, [IDr], V [<---] HDR, T, [IDr], V
DH method: DH method:
I_MESSAGE = I_MESSAGE =
HDR, T, [IDi|CERTi], {SP}, HDR, T, [IDi|CERTi], {SP},
[DHi], SIGNi ---> [DHi], SIGNi --->
R_MESSAGE = R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi, <--- HDR, T, [IDr|CERTr], IDi,
[DHr, DHi], SIGNr [DHr, DHi], SIGNr
Figure 4.1: Update messages. Figure 4.1: Update messages.
Note that for the DH method, if the Initiator includes the DHi Note that for the DH method, if the Initiator includes the DHi
payload, then the responder MUST include DHr, DHi. If the initiator payload, then the Responder MUST include DHr and DHi. If the
does not include DHi, the responder MUST NOT include DHr, DHi. Initiator does not include DHi, the Responder MUST NOT include DHr,
DHi.
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
The initiator indicates the security policy to use (i.e. in terms of The Initiator indicates the security policy to use (i.e. in terms of
security protocol algorithms etc). If the Responder does not support security protocol algorithms etc). If the Responder does not support
it (for some reason), the Responder can together with an error it (for some reason), the Responder can together with an error
message (indicating that it does not support the parameters), send message (indicating that it does not support the parameters), send
back its own capabilities (negotiation) to let the Initiator choose a back its own capabilities (negotiation) to let the Initiator choose a
common set of parameters. This is done by including one or more common set of parameters. This is done by including one or more
security policy payloads. Multiple attributes can be provided in security policy payloads in the error message sent in answer (see
sequence in the response. This is done to reduce the number of Section 5.1.2.). Multiple attributes can be provided in sequence in
roundtrips as much as possible (i.e. in most cases, where the policy the response. This is done to reduce the number of roundtrips as much
is accepted the first time, one roundtrip is enough). If the as possible (i.e. in most cases, where the policy is accepted the
Responder does not accept the offer, the Initiator must go out with a first time, one roundtrip is enough). If the Responder does not
new MIKEY message. accept the offer, the Initiator must go out with a new MIKEY message.
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 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 broad variety of options, as it is assumed that it should not be too
common that an offer is denied. common that an offer is denied.
In the one-to-many and many-to-many scenarios using multicast
communication, one issue is of course that there MUST be a common
security policy to all the receivers. This limits the possibility for
negotiation.
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 such message back from the Responder. always be prepared to receive such message 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.2). parameters (see also Section 5.1.1).
The error message should be formed as: The error message is formed as:
HDR, T, {ERR}, [V|SIGNr] HDR, T, {ERR}, {SP}, [V|SIGNr]
Note that if the failure is due to the inability to authenticate the Note that if the failure is due to the inability to authenticate the
peer, the error message is OPTIONAL, and does not need to be peer, the error message is OPTIONAL, and does not need to be
authenticated. It is up to the local policy how to treat this kind of authenticated. It is up to the local policy how to treat this kind of
messages. However, if a signed error message in response to a failed messages. However, if a signed error message in response to a failed
authentication is returned this can be used for DoS purposes. authentication is returned this can be used for DoS purposes (against
Similarly, an unauthenticated error message could be sent to the the Responder). Similarly, an unauthenticated error message could be
Initiator in order to fool her to tear down the CSB. It is highly sent to the Initiator in order to fool her to tear down the CSB. It
RECOMMENDED that the local policy takes this into consideration. One is highly RECOMMENDED that the local policy takes this into
consideration. Therefore, in case of authentication failure, one
advice would be not to authenticate such an error message, and when advice would be not to authenticate such an error message, and when
receiving an unauthenticated error message only see it as a receiving an unauthenticated error message only see it as a
recommendation of what may have gone wrong. recommendation of what may have gone wrong.
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 Policy payload). The defined payloads and the exact
exact encoding of each payload are described in Section 6. encoding of each payload are described in Section 6.
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 ! ! ! version ! data type ! next payload ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +
~ Common Header... ~ ~ Common Header... ~
! ! ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload 1 ... ! ! next payload ! Payload 1 ... !
skipping to change at page 25, line 4 skipping to change at page 27, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : : : :
: : : : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload x ... ! ! next payload ! Payload x ... !
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MAC/Signature ~ ! MAC/Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.1. MIKEY payload message example. Note that the payloads are Figure 5.1. MIKEY payload message example. Note that the payloads are
byte aligned and not 32-bit aligned. byte aligned and not 32-bit aligned.
The process of generating a MIKEY message consists of the following The process of generating a MIKEY message consists of the following
steps: steps:
* Create an initial MIKEY message starting with the Common header * Create an initial MIKEY message starting with the Common Header
payload. payload.
* Concatenate necessary payloads to the MIKEY message (see the * Concatenate necessary payloads to the MIKEY message (see the
exchange definitions for payloads that may be included and exchange definitions for payloads that may be included, and
recommended order). recommended order).
* As a last step (for messages that must be authenticated, this also * As a last step (for messages that must be authenticated, this also
include the verification message), create and concatenate the include the verification message), create and concatenate the
MAC/signature payload without the MAC/signature field filled in (if a MAC/signature payload without the MAC/signature field filled in (if a
Next payload field is included in this payload, it is set to Last Next payload field is included in this payload, it is set to Last
payload). payload).
* Calculate the MAC/signature over the entire MIKEY message, except * Calculate the MAC/signature over the entire MIKEY message, except
the MAC/Signature field, and add the MAC/signature in the field. In the MAC/Signature field, and add the MAC/signature in the field. In
skipping to change at page 25, line 44 skipping to change at page 28, line 18
data transport payload except the MAC field. Before calculating the data transport payload except the MAC field. Before calculating the
MAC, the Next payload field is set to zero. MAC, the Next payload field is set to zero.
Note that all messages from the Initiator MUST use a unique Note that all messages from the Initiator MUST use a unique
timestamp. The Responder does not create a new timestamp, but uses timestamp. The Responder does not create a new timestamp, but uses
the timestamp used by the Initiator. the timestamp used by the Initiator.
5.3. Parsing a message 5.3. Parsing a message
In general, parsing of a MIKEY message is done by extracting payload In general, parsing of a MIKEY message is done by extracting payload
by payload and checking that no errors occur (the exact procedure is by payload and checking that no errors occur. The exact procedure is
implementation specific). However, for the Responder, it is implementation specific; however, for the Responder, it is
RECOMMENDED that the following procedure is followed: RECOMMENDED that the 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 (if not, discard the message). Also check the replay cache clock skew (if not, discard the message). Also check the replay cache
so that the message is not replayed (see also Section 5.4). If the (Section 5.4) so that the message is not replayed (see also Section
message is replayed, discard it. 5.4). If the message is replayed, discard it.
* Extract ID and authentication algorithm (if not included, assume * Extract ID and authentication algorithm (if not included, assume
the default one). the 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 is possibly sent to the Initiator (if SIP is used, this is message MAY be sent to the Initiator. The message is then discarded
signaled to SIP as a rejection of the offer). The message is then from further processing. See also Section 5.1.2 for treatment of
discarded from further processing. See also Section 5.1.2 for errors.
treatment of errors.
* If the authentication is successful, the message is processed and * If the authentication is successful, the message is processed and
also added to the replay cache. How it is processed is implementation also added to the replay cache. How it is processed is implementation
specific. Note also that it is only successfully authenticated specific. Note also that it is only successfully authenticated
messages that are stored in the replay cache. messages that are stored in the replay cache.
* If any unsupported parameters or errors occur during the * If any unsupported parameters or errors occur during the
processing, these are reported to the Initiator by sending an error processing, these MAY be reported to the Initiator by sending an
message. The processing is then aborted. The error message can also error message. The processing is then aborted. The error message can
include payloads to describe the supported parameters. If SIP is also include payloads to describe the supported parameters.
used, this is signaled to SIP as a rejection of the offer (see also
Section 7.2).
* If the processing was successful and if needed, a verification/ * If the processing was successful and in case the Initiator
response message is created and sent to the Initiator. requested it, a verification/ response message MAY be created and
sent to the Initiator.
5.4. Replay handling and timestamp usage 5.4. Replay handling and timestamp usage
MIKEY does not use a challenge-response mechanism for replay handling MIKEY does not use a challenge-response mechanism for replay
instead timestamps are used. This requires that the clocks are handling; instead timestamps are used. This requires that the clocks
synchronized. The required synchronization is dependent on the number are synchronized. The required synchronization is dependent on the
of messages that can be cached (note though, that the replay cache number of messages that can be cached (note though, that the replay
only contain messages that has been successfully authenticated). If cache only contain messages that have been successfully
we could assume an unlimited cache, the terminals would not need to authenticated). If we could assume an unlimited cache, the terminals
be synchronized at all (as the cache could then contain all previous would not need to be synchronized at all (as the cache could then
messages). However, if there are restrictions on the size of the contain all previous messages). However, if there are restrictions on
replay cache, the clocks will need to be synchronized to some extent. the size of the replay cache, the clocks will need to be synchronized
In short, one can in general say that it is a tradeoff between the to some extent. In short, one can in general say that it is a
size of the replay cache and the required synchronization. tradeoff between the size of the replay cache and the required
synchronization.
Timestamp usage prevents against replay attacks under the following Timestamp usage prevents against replay attacks under the following
assumptions: assumptions:
* Each host have a clock which is at least "loosely synchronized" to * Each host has a clock which is at least "loosely synchronized" to
the clocks of the other hosts. the clocks 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 is used. network clock synchronization protocol SHOULD be used, e.g. [ISO3].
* Each Responder utilizes a replay cache in order to remember the * Each Responder utilizes a replay cache in order to remember the
successfully authenticated messages presented within an allowable successfully authenticated messages presented within an allowable
clock skew (which is set by the local policy). clock skew (which is set by the local policy).
* Replayed and outdated messages, i.e., messages that can be found in * Replayed and outdated messages, i.e., messages that can be found in
the replay cache or which have an outdated timestamp, are discarded the replay cache or which have an outdated timestamp, are discarded
and not processed. and not processed.
* 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 rejects all incoming requests until the clock skew overload), it rejects all incoming requests until the clock skew
interval has passed. interval has passed.
In a client-server scenario, servers may be the entities that will In a client-server scenario, servers may encounter high workload,
have the highest workload. It is therefore RECOMMENDED that the especially if a replay cache is needed. However, servers that assume
servers are the Initiators of MIKEY. This will result in that the the role of Initiators of MIKEY will not need to manage any
servers will not need to manage any significant replay cache as they significant replay cache as they will refuse all incoming messages
will refuse all incoming messages that are not a response to an that are not a response to a message previously sent by the server.
already (by the server) sent message.
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
order of several minutes to hours. If a (D)DoS attack is launched and order of several minutes to hours. If a (D)DoS attack is launched and
the replay cache grows too large, MIKEY MAY dynamically decrease the the replay cache grows too large, MIKEY MAY dynamically decrease the
looseness so that the replay cache becomes manageable (however, note looseness so that the replay cache becomes manageable. However, note
that such (D)DoS can only be performed by peers that can authenticate that such (D)DoS can only be performed by peers that can authenticate
themselves). Another, way to treat the problem is of course to reject themselves (hence, such attack is very easy to trace and mitigate).
all incoming messages from the specific peer(s) that executes the
attack.
The maximum number of messages that a client will need to cache may The maximum number of messages that a client will need to cache may
vary depending on the capacity of the client itself and the network, vary depending on the capacity of the client itself and the network,
but also the number of expected messages should be taken into but also the number of expected messages should be taken into
account. account.
For example, assume that we can at most spend 6kB on a replay cache. For example, assume that we can at most spend 6kB on a replay cache.
Assume further that we need to store 30 bytes for each incoming Assume further that we need to store 30 bytes for each incoming
authenticated message (the hash of the message is 20 bytes). This authenticated message (the hash of the message is 20 bytes). This
implies that it is possible to cache approximately 204 messages. If implies that it is possible to cache approximately 204 messages. If
skipping to change at page 28, line 17 skipping to change at page 30, line 34
fix a size for the replay cache, and let the allowable clock skew be fix a size for the replay cache, and let the allowable clock skew be
large (the initial clock skew can be set depending on the application large (the initial clock skew can be set depending on the application
in which it is used). As the replay cache grows, the clock skew is in which it is used). As the replay cache grows, the clock skew is
decreased depending on how many percent of the replay cache that are decreased depending on how many percent of the replay cache that are
used. Note that this is locally handled, which will not require used. Note that this is locally handled, which will not require
interaction with the peer (even though it may indirectly affect the interaction with the peer (even though it may indirectly affect the
peer). Exactly how to implement such functionality is however out of peer). Exactly how to implement such functionality is however out of
the scope of this document and considered implementation specific. the scope of this document and considered implementation specific.
In case of a DoS attack, the client will most likely be able to In case of a DoS attack, the client will most likely be able to
handle the replay cache. A bigger problem will probably be to process handle the replay cache. A more likely (and serious) DoS attack is a
the messages (verify signatures/MACs), due to the computational CPU DoS attack where the attacker sends messages to the peer, which
workload this implies. then needs to engage resources on verifying MACs/signatures of the
incoming messages.
5.5. Reliability
If MIKEY is sent on an unreliable transport, the basic processing
applied to ensure protocol reliability is the following.
The transmitting entity (Initiator or Responder) MUST:
* Set a timer and initialize a retry counter
* If the timer expires, the message is resent and the retry counter
is decreased.
* If the retry counter reaches zero (0), the event MAY be logged in
the appropriate system audit file.
6. Payload Encoding 6. Payload Encoding
This section describes in detail all the payloads. For all encoding, This section describes in detail all the payloads. For all encoding,
Network byte order is always used. network byte order is always used. While defining supported types,
for example which hash functions are supported, the mandatory-to-
implement are indicated (as Mandatory), as well as the default (note,
default also implies mandatory to implement). The other types are
implicitly assumed optional to support.
6.1. Common header payload (HDR) Note that in the following the support for SRTP [SRTP] as security
protocol is defined. This will help better understanding the purpose
of the different payloads and fields. Other security protocol MAY be
specified to use within MIKEY, see Section 10.
The Common header payload MUST always be present as the first payload In the following, the sign ~ indicates variable length field.
in each message. The common header includes general description of
6.1. Common Header payload (HDR)
The Common Header payload MUST always be present as the first payload
in each message. The Common Header includes general description of
the exchange message. 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 !V! PRF func ! ! version ! data type ! next payload !V! PRF func !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! CSB ID ! ! CSB ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! #CS ! CS ID map type! CS ID map info ~ ! #CS ! CS ID map type! CS ID map info ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The common header contains the following information:
* version: the version number of MIKEY. * version (8 bits): the version number of MIKEY.
version = 1 version = 0x01 refers to MIKEY as defined in this document.
* data type: describes the type of message (e.g. public-key transport * data type (8 bits): describes the type of message (e.g. public-key
message, verification message, error message). transport message, verification message, error message).
Data type | Value | Comment Data type | Value | Comment
-------------------------------------- --------------------------------------
Pre-shared | 0 | Initiator's pre-shared key message Pre-shared | 0 | Initiator's pre-shared key message
PSK ver msg | 1 | Verification message of a Pre-shared PSK ver msg | 1 | Verification message of a Pre-shared
| | key message | | 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 PK ver msg | 3 | Verification message of a public-key
| | message | | 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 Table 6.1.a
payload.
* next payload (8 bits): identifies the payload that is added after
this payload.
Next payload | Value | Section Next payload | Value | Section
------------------------------ ------------------------------
Last payload | 0 | - Last payload | 0 | -
KEMAC | 1 | 6.2 KEMAC | 1 | 6.2
PKE | 2 | 6.3 PKE | 2 | 6.3
DH | 3 | 6.4 DH | 3 | 6.4
SIGN | 4 | 6.5 SIGN | 4 | 6.5
T | 5 | 6.6 T | 5 | 6.6
ID | 6 | 6.7 ID | 6 | 6.7
CERT | 7 | 6.7 CERT | 7 | 6.7
CHASH | 8 | 6.8 CHASH | 8 | 6.8
V | 9 | 6.9 V | 9 | 6.9
SP | 10 | 6.10 SP | 10 | 6.10
RAND | 11 | 6.11 RAND | 11 | 6.11
ERR | 12 | 6.12 ERR | 12 | 6.12
Key data | 20 | 6.13 Key data | 20 | 6.13
General Ext. | 21 | 6.15 General Ext. | 21 | 6.15
Note that some of the payloads cannot possibly come right after the Table 6.1.b
header (such as "Last payload", "Signature", etc.). However, the Next
Note that some of the payloads cannot come right after the header
(such as "Last payload", "Signature", etc.). However, the Next
payload field is generic for all payloads. Therefore, a value is payload field is generic for all payloads. Therefore, a value is
allocated for each payload. allocated for each payload. The Next payload field is set to zero
(Last payload) if the current payload is the last payload.
* V: flag to indicate whether a verification message is expected or * V (1 bit): flag to indicate whether a verification message is
not (this has only meaning when it is set by the Initiator). expected or not (this has only meaning when it is set by the
Initiator). The V flag SHALL be ignored by the receiver in the DH
method (as the response is MANDATORY).
V = 0 ==> no response expected V = 0 ==> no response expected
V = 1 ==> response expected V = 1 ==> response expected
* PRF func: Indicates the PRF function that has been/will be used for * PRF func (7 bits): indicates the PRF function that has been/will be
key derivation etc. used for key derivation.
PRF func | Value | Comments PRF func | Value | Comments
-------------------------------------------------------- --------------------------------------------------------
MIKEY-1 | 0 | Mandatory, Default (see Section 4.1.2-3) MIKEY-1 | 0 | Mandatory (see Section 4.1.3)
MIKEY-256 | 1 | (as MIKEY-1 but using a HMAC with SHA256)
MIKEY-384 | 2 | (as MIKEY-1 but using a HMAC with SHA384)
MIKEY-512 | 3 | (as MIKEY-1 but using a HMAC with SHA512)
* CSB ID: A 32-bit integer to identify the CSB. It is RECOMMENDED Table 6.1.c
that it is chosen at random by the Initiator. This ID MUST be unique
between each Initiator-Responder pair, i.e., not globally unique. An * CSB ID (32 bits): identifies the CSB. It is RECOMMENDED that it is
chosen at random by the Initiator. This ID MUST be unique between
each Initiator-Responder pair, i.e., not globally unique. An
Initiator MUST check for collisions when choosing the ID (if the Initiator MUST check for collisions when choosing the ID (if the
Initiator already has one or more established CSB with the Initiator already has one or more established CSB with the
Responder). The Responder uses the same CSB ID in the response. Responder). The Responder uses the same CSB ID in the response.
* #CS: Indicates the number of Crypto Sessions that will be handled. * #CS (8 bits): indicates the number of Crypto Sessions that will be
Note that even though it is possible to use 255 CSs, it is not likely handled within the CBS. Note that even though it is possible to use
that a CSB will include this many CSs. The integer 0 is interpreted 255 CSs, it is not likely that a CSB will include this many CSs. The
as no CS included. This may be the case in an initial setup message. integer 0 is interpreted as no CS included. This may be the case in
an initial setup message.
* CS ID map type: specifies the method to uniquely map Crypto * CS ID map type (8 bits): specifies the method to uniquely map
Sessions to the security protocol sessions. Crypto Sessions to the security protocol sessions.
CS ID map type | Value CS ID map type | Value
----------------------- -----------------------
SRTP-ID | 0 SRTP-ID | 0
* CS ID map info: Identifies the crypto session(s) that the SA should Table 6.1.d
be created for. The currently defined map type is the SRTP-ID
(defined in Section 6.1.1). * CS ID map info (16 bits): identifies the crypto session(s) that the
SA should be created for. The currently defined map type is the SRTP-
ID (defined in Section 6.1.1).
6.1.1. SRTP ID 6.1.1. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_1 ! SSRC_1 ~ ! Policy_no_1 ! SSRC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SSRC_1 (cont) ! ROC_1 ~ ! SSRC_1 (cont) ! ROC_1 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ROC_1 (cont) ! Policy_no_2 ! SSRC_2 ~ ! ROC_1 (cont) ! Policy_no_2 ! SSRC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SSRC_2 (cont) ! ROC_2 ~ ! SSRC_2 (cont) ! ROC_2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ROC_2 (cont) ! : ! ROC_2 (cont) ! :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
: : : : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy_no_#CS ! SSRC_#CS ~ ! Policy_no_#CS ! SSRC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~SSRC_#CS (cont)! ROC_#CS ~ !SSRC_#CS (cont)! ROC_#CS !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ROC_#CS (cont)! ! ROC_#CS (cont)!
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
* Policy_no_i: The policy applied for the stream with SSRC_i. The * Policy_no_i (8 bits): The security policy applied for the stream
same policy may apply for all CSs. with SSRC_i. The same security policy may apply for all CSs.
* SSRC_i: specifies the SSRC that MUST be used for the i-th SRTP * SSRC_i (32 bits): specifies the SSRC that MUST be used for the i-th
stream. Note that it is the sender of the streams who chooses the SRTP stream. Note that it is the sender of the streams who chooses
SSRC. Therefore, it might be that the Initiator of MIKEY can not fill the SSRC. Therefore, it might be that the Initiator of MIKEY can not
in all fields. In this case, SSRCs that are not chosen by the fill in all fields. In this case, SSRCs that are not chosen by the
Initiator are set to zero and the Responder fills in these field in Initiator are set to zero and the Responder fills in these fields in
the response message. It is in general RECOMMENDED or required to use the response message. Note that SRTP specifies requirements on the
unique SSRCs (both to avoid RTP SSRC collision, and from an SRTP uniqueness of the SSRCs (to avoid two-time pad problems if the same
perspective, to avoid two-time pad problems if the same TEK is used TEK is used for more than one stream), see [SRTP].
for more than one stream).
* ROC_i: Current rollover counter used in SRTP. If the SRTP session * ROC_i (32 bits): Current rollover counter used in SRTP. If the SRTP
has not started, this field is set to 0. This field is used to be session has not started, this field is set to 0. This field is used
able for a member to join and synchronize to an already started to be able for a member to join and synchronize to an already started
stream. stream.
NOTE: The stream using SSRC_i will also have Crypto Session ID equal NOTE: The stream using SSRC_i will also have Crypto Session ID equal
to no i (NOT to the SSRC). to no i (NOT to the SSRC).
6.2. Key data transport payload (KEMAC) 6.2. Key data transport payload (KEMAC)
The Key data transport payload contains encrypted Key data payloads The Key data transport payload contains encrypted Key data sub-
(see Section 6.13 for definition of Key data payloads). It may payloads (see Section 6.13 for definition of the Key data sub-
contain one or more Key data payloads each including a TGK. The last payload). It may contain one or more Key data payloads each including
Key data payload has its Next payload field set to Last payload. For e.g. a TGK. The last Key data payload has its Next payload field set
an update message (see also Section 4.5), it is allowed to skip the to Last payload. For an update message (see also Section 4.5), it is
Key data payloads (which will result in that the Encr data len is allowed to skip the Key data sub-payloads (which will result in that
equal to 0). the Encr data len is equal to 0).
Note that the MAC coverage depends on the method used, i.e. pre-
shared vs public key, see below.
If the transport method used is the pre-shared key method, this Key If the transport method used is the pre-shared key method, this Key
data transport payload is the last payload in the message (note that data transport payload is the last payload in the message (note that
the Next payload field is set to Last payload). The MAC is then the Next payload field is set to Last payload). The MAC is then
calculated over the entire MIKEY message (as described in Section calculated over the entire MIKEY message following the directives in
5.2). Section 5.2.
If the transport method used is the public-key method, the If the transport method used is the public-key method, the
Initiator's identity is added in the encrypted data. This is done by Initiator's identity is added in the encrypted data. This is done by
adding the ID payload as the first payload, which then are followed adding the ID payload as the first payload, which then is followed by
by the Key data payloads. Note that for an update message, the ID is the Key data sub-payloads. Note that for an update message, the ID is
still sent encrypted to the Responder (this is to avoid certain re- still sent encrypted to the Responder (this is to avoid certain re-
direction attacks) even though no Key data payloads is added after. direction attacks) even though no Key data sub-payload is added
after.
The MAC field is in the public-key case calculated only over the Key The coverage of the MAC field is in the public-key case over the Key
data transport payload except the MAC field and where the Next data transport payload only, instead of the complete MIKEY message,
as in the pre-shared case. The MAC is therefore calculated over the
Key data transport payload except the MAC field and where the Next
payload field has been set to zero (see also Section 5.2). payload field has been set to zero (see also Section 5.2).
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 ! Encr alg ! Encr data len ! ! Next payload ! Encr alg ! Encr data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encr data ~ ! Encr data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Mac alg ! MAC ~ ! Mac alg ! MAC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * Next payload (8 bits): identifies the payload that is added after
payload (see Section 6.1 for defined values). this payload. See Section 6.1 for defined values.
* Encr alg: The encryption algorithm used to encrypt the TGK. * Encr alg (8 bits): the encryption algorithm used to encrypt the
Encr data field.
Encr alg | Value | Comments Encr alg | Value | Comment
------------------------------------------- -------------------------------------------
AES-CM-128 | 1 | Mandatory (as defined in Section 4.2.3, NULL | 0 | Very restricted usage, see Section 4.2.3!
using a 128-bit key) AES-CM-128 | 1 | Mandatory ; AES-CM using a 128-bit key, see
NULL | 2 | Very restricted usage, see Section 4.2.3! Section 4.2.3)
AES-KW-128 | 3 | Optional (AES Key Wrap, see also Section AES-KW-128 | 2 | AES Key Wrap using a 128-bit key, see
4.2.3) Section 4.2.3
* Encr len: Length of encrypted part (in bytes). Table 6.2.a
* Encr data: The encrypted TGK sub-payloads (see Section 6.13). * Encr data len (16 bits): length of Encr data (in bytes).
* MAC alg specifies the authentication algorithm used. * Encr data (variable length): the encrypted key sub-payloads (see
Section 6.13).
MAC alg | Value | Comments * MAC alg (8 bits): specifies the authentication algorithm used.
--------------------------------------
HMAC-SHA1-160 | 0 | Mandatory (see Section 4.2.4)
NULL | 1 | Very restricted usage, see Section 4.2.4!
* MAC: The message authentication code of the entire message. MAC alg | Value | Comments | Length (bits)
-------------------------------------------------------------------
NULL | 0 | restricted usage (Sec 4.2.4)| 0
HMAC-SHA-1-160| 1 | Mandatory, Section 4.2.4 | 160
Table 6.2.b
* MAC (variable length): the message authentication code of the
entire message.
6.3. Envelope data payload (PKE) 6.3. Envelope data payload (PKE)
The Envelope data payload contains the encrypted envelope key that is The Envelope data payload contains the encrypted envelope key that is
used in the public-key transport to protect the data in the Key data used in the public-key transport to protect the data in the Key data
transport payload. The encryption algorithm used is implicit from the transport payload. The encryption algorithm used is implicit from the
certificate/public key used. certificate/public key 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 ! C ! Data len ! Data ~ ! Next Payload ! C ! Data len ! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * Next payload (8 bits): identifies the payload that is added after
payload. this payload. See Section 6.1 for values.
* C: Envelope key cache indicator (see also Section 3.2, for more * C (2 bits): envelope key cache indicator (Section 3.2).
information of the usage).
Cache type | Value | Comments Cache type | Value | Comments
-------------------------------------- --------------------------------------
No cache | 0 | The envelope key MUST NOT be cached No cache | 0 | The envelope key MUST NOT be cached
Cache | 1 | The envelope key MUST be cached Cache | 1 | The envelope key MUST be cached
Cache for CSB | 2 | The envelope key MUST be cached, but only Cache for CSB | 2 | The envelope key MUST be cached, but only
| | to be used for the specific CSB. | | to be used for the specific CSB.
Table 6.3
* Data len: The length of the data field (in bytes). * Data len (14 bits): the length of the data field (in bytes).
* Data: The encrypted envelope key (if nothing else stated in the * Data (variable length): the encrypted envelope key.
certificate, padding and formatting is done according to RSA/PKCS#1
if RSA is used).
6.4. DH data payload (DH) 6.4. DH data payload (DH)
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. Notice that in this sub-section "MANDATORY" is conditioned upon used. Notice that in this sub-section "MANDATORY" is conditioned upon
DH being supported at all. DH being supported at all.
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-value ~ ! Next Payload ! DH-Group ! DH-value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Reserv! KV ! KV data (optional) ~ ! Reserv! KV ! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this
payload.
* DH-Group: identifies the DH group used. * Next payload (8 bits): identifies the payload that is added after
this payload. See Section 6.1 for values.
DH-Group | Value | Comments * DH-Group (8 bits): identifies the DH group used.
--------------------------------------
OAKLEY 5 | 0 | Mandatory
OAKLEY 1 | 1 |
OAKLEY 2 | 2 |
* DH-value: The public DH-value (the length is implicit from the DH-Group | Value | Comment | DH Value length (bits)
group used). --------------------------------------|---------------------
OAKLEY 5 | 0 | Mandatory | 1536
OAKLEY 1 | 1 | | 768
OAKLEY 2 | 2 | | 1024
Table 6.4
* KV: Indicates the type of key validity period specified. This may * DH-value (variable length): the public DH-value (the length is
be done by using an SPI (alternatively an MKI) or by providing an implicit from the group used).
interval in which the key is valid (e.g. in the latter case, for SRTP
this will be the index range where the key is valid). See Section
6.13 for pre-defined values.
* KV data: This includes either the SPI/MKI or an interval (see * KV (4 bits): indicates the type of key validity period specified.
Section 6.14). If KV is NULL, this field is not included. This may be done by using an SPI (alternatively an MKI) or by
providing an interval in which the key is valid (e.g. in the latter
case, for SRTP this will be the index range where the key is valid).
See Section 6.13 for pre-defined values.
* KV data (variable length): This includes either the SPI/MKI or an
interval (see Section 6.14). If KV is NULL, this field is not
included.
6.5. Signature payload (SIGN) 6.5. Signature payload (SIGN)
The Signature payload carries the signature and its related data. The The Signature payload carries the signature and its related data. The
signature payload is always the last payload in the PK transport and signature payload is always the last payload in the PK transport and
DH exchange messages. The signature algorithm used is implicit from DH exchange messages. The signature algorithm used is implicit from
the certificate/public key used. the certificate/public key 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! S type| Signature len ! Signature ~ ! S type| Signature len ! Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* S type: Indicates the signature algorithm applied by signer. * S type (4 bits): indicates the signature algorithm applied by
signer.
S type | Value | Comments S type | Value | Comments
------------------------------------- -------------------------------------
RSA/PKCS#1/1.5| 0 | Denotes a PKCS #1 version 1.5 signature RSA/PKCS#1/1.5| 0 | Mandatory, PKCS #1 version 1.5 signature
RSA/PSS | 1 | Denotes a PSS signature [PSS]
RSA/PSS | 1 | RSASSA-PSS signature [PSS]
* Signature len: The length of the signature field (in bytes). Table 6.5
* Signature: The signature (if nothing else stated in the * Signature len (12 bits): the length of the signature field (in
certificate, padding and formatting is done according to RSA/PKCS#1 bytes).
if RSA is used).
* Signature (variable length): the signature (its formatting and
padding depend on the type of signature).
6.6. Timestamp payload (T) 6.6. Timestamp payload (T)
The timestamp payload carries the timestamp information. The timestamp payload carries the timestamp information.
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 ! TS value ~ ! Next Payload ! TS type ! TS value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * Next payload (8 bits): identifies the payload that is added after
payload. If no more payload follows, it MUST be set to Last payload. this payload. See Section 6.1 for values.
See Section 6.1 for values.
* TS type: specifies the timestamp type used. * TS type (8 bits): specifies the timestamp type used.
TS type | Value | Comments TS type | Value | Comments | length of TS value
------------------------------------- -------------------------------------|-------------------
NTP-UTC | 0 | Mandatory (64-bits) NTP-UTC | 0 | Mandatory | 64-bits
NTP | 1 | Mandatory (64-bits) NTP | 1 | Mandatory | 64-bits
COUNTER | 2 | Optional (32-bits) COUNTER | 2 | Optional | 32-bits
* TS-value: The timestamp value of the specified TS type. Table 6.6
Note: COUNTER SHALL be padded (with leading zeros) to 64-bit value
when used as input to the default PRF.
* TS-value (variable length): The timestamp value of the specified TS
type.
6.7. ID payload (ID) / Certificate payload (CERT) 6.7. ID payload (ID) / Certificate payload (CERT)
Note that the ID payload and the Certificate payload are two Note that the ID payload and the Certificate payload are two
completely different payloads (having different payload identifiers). completely different payloads (having different payload identifiers).
However, as they share the same payload structure they are described However, as they share the same payload structure they are described
in the same section. in the same section.
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. If a certificate chain are provided as well as the certificate data. If a certificate chain is
to be provided, each certificate in the chain should be included in a to be provided, each certificate in the chain should be included in a
separate CERT payload. separate CERT 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 ! 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 (8 bits): identifies the payload that is added after
payload. See Section 6.1 for values. this payload. See Section 6.1 for values.
If the payload is an ID payload the following values applies for the If the payload is an ID payload the following values applies for the
ID type field: ID type field:
* ID Type: specifies the identifier type used. * ID Type (8 bits): 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])
Table 6.7.a
If the payload is an Certificate payload the following values applies If the payload is an Certificate payload the following values applies
for the Cert type field: for the Cert type field:
* Cert Type: specifies the certificate type used. * Cert Type (8 bits): specifies the certificate type used.
Cert Type | Value | Comments Cert Type | Value | Comments
---------------------------------------------- ----------------------------------------------
X.509v3 | 0 | Mandatory X.509v3 | 0 | Mandatory
X.509v3 URL | 1 | plain ASCII URL to the location of the Cert X.509v3 URL | 1 | plain ASCII URL to the location of the Cert
X.509v3 Sign | 2 | Mandatory (used for signatures only) X.509v3 Sign | 2 | Mandatory (used for signatures only)
X.509v3 Encr | 3 | Mandatory (used for encryption only) X.509v3 Encr | 3 | Mandatory (used for encryption only)
* ID/Cert len: The length of the ID or Certificate field (in bytes). Table 6.7.b
* ID/Certificate: The ID or Certificate data. The X.509 [X.509] * ID/Cert len (16 bits): the length of the ID or Certificate field
certificates are included as a bytes string using DER encoding as (in bytes).
specified in X.509.
* ID/Certificate (variable length): The ID or Certificate data. The
X.509 [X.509] certificates are included as a bytes string using DER
encoding as specified in X.509.
6.8. Cert hash payload (CHASH) 6.8. Cert hash payload (CHASH)
The Cert hash payload contains the hash of the certificate used. The Cert hash payload contains the hash of the certificate 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 ! Hash func ! Hash ~ ! Next Payload ! Hash func ! Hash ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * Next payload (8 bits): identifies the payload that is added after
payload. this payload. See Section 6.1 for values.
* Hash func: Indicates the hash function that is used (see also * Hash func (8 bits): indicates the hash function that is used (see
Section 4.2.1). also Section 4.2.1).
Hash func | Value Hash func | Value | Comment | hash length (bits)
---------------------- -------------------------------------------------
SHA-1 | 0 Mandatory SHA-1 | 0 | Mandatory | 160
SHA256 | 1 MD5 | 1 | | 128
SHA384 | 2
SHA512 | 3 Table 6.8
MD5 | 4
* Hash: The hash data. Note: the hash length is implicit from the * Hash (variable length): the hash data. The hash length is implicit
hash function used. from the hash function used.
6.9. Ver msg payload (V) 6.9. Ver msg payload (V)
The Ver msg payload contains the calculated verification message in The Ver msg payload contains the calculated verification message in
the pre-shared key and the public-key transport methods. Note that the pre-shared key and the public-key transport methods. Note that
the MAC is calculated over the entire MIKEY message as well as the the MAC is calculated over the entire MIKEY message as well as the
IDs and Timestamp (see also Section 5.2). IDs and Timestamp (see also Section 5.2).
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 ! Ver data ~ ! Next Payload ! Auth alg ! Ver data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * Next payload (8 bits): identifies the payload that is added after
payload. If no more payload follows, it is set to Last payload. See this payload. See Section 6.1 for values.
Section 6.1 for values.
* Auth alg: specifies the MAC algorithm used for the verification * Auth alg (8 bits): specifies the MAC algorithm used for the
message. See Section 6.2 for defined (MAC field) for defined values. verification message. See Section 6.2 for defined values.
* Ver data: The verification message data. Note: the length is * Ver data (variable length): the verification message data. The
implicit from the authentication algorithm used. length is implicit from the authentication algorithm used.
6.10. Security Policy payload (SP) 6.10. Security Policy payload (SP)
The Security Policy payload defines a set of policies that applies to The Security Policy payload defines a set of policies that applies to
a specific security protocol. a specific security 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 ! Policy no ! Prot type ! Policy param ~ ! Next payload ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~ ~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload: identifies the payload that is added after this * Next payload (8 bits): identifies the payload that is added after
payload. See Section 6.1 for values. this payload. See Section 6.1 for values.
* Policy no: Each security policy payload must be given a distinct * Policy no (8 bits): each security policy payload must be given a
number for the current MIKEY session by the local peer. This number distinct number for the current MIKEY session by the local peer. This
is used to be able to map a crypto session to a specific policy (see number is used to be able to map a crypto session to a specific
also Section 6.1.1). policy (see also Section 6.1.1).
* Prot type: defines the security protocol. * Prot type (8 bits): defines the security protocol.
Prot type | Value | Prot type | Value |
--------------------------- ---------------------------
SRTP | 0 | SRTP | 0 |
* Policy param length: defines the total length of the policy Table 6.10
parameters for the specific security protocol.
* Policy param: defines the policy for the specific security * Policy param length (16 bits): defines the total length of the
protocol. policy parameters for the specific security protocol.
* Policy param (variable length): defines the policy for the specific
security protocol.
The Policy param part is built up by a set of Type/Length/Value The Policy param part is built up by a set of Type/Length/Value
fields. For each security protocol, a set of possible types/values fields. For each security protocol, a set of possible types/values
that can be negotiated are defined. that can be negotiated is defined.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ! Value ~ ! Type ! Length ! Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Type: specifies the type of the parameter. * Type (8 bits): specifies the type of the parameter.
* Length: specifies the length of the Value field (in bytes). * Length (8 bits): specifies the length of the Value field (in
bytes).
* Value: specifies the value of the parameter. * Value (variable length): specifies the value of the parameter.
6.10.1. SRTP policy 6.10.1. SRTP policy
This policy specifies the parameters for SRTP and SRTCP. The This policy specifies the parameters for SRTP and SRTCP. The
types/values that can be negotiated are defined by the following types/values that can be negotiated are defined by the following
table: table:
Type | Meaning | Possible values Type | Meaning | Possible values
---------------------------------------------------- ----------------------------------------------------
0 | Encryption algorithm | see below 0 | Encryption algorithm | see below
1 | Session Encr. key length | depends on cipher used 1 | Session Encr. key length | depends on cipher used
2 | Authentication algorithm | see below 2 | Authentication algorithm | see below
3 | Session Auth. key length | depends on MAC used 3 | Session Auth. key length | depends on MAC used
4 | Session Salt key length | see [SRTP] for recommendations 4 | Session Salt key length | see [SRTP] for recommendations
5 | SRTP Pseudo Random Function | see below 5 | SRTP Pseudo Random Function | see below
6 | Key derivation rate | see [SRTP] for recommendations 6 | Key derivation rate | see [SRTP] for recommendations
7 | SRTP encryption off/on | 0 if off, 1 if on 7 | SRTP encryption off/on | 0 if off, 1 if on
8 | SRTCP encryption off/on | 0 if off, 1 if on 8 | SRTCP encryption off/on | 0 if off, 1 if on
9 | senderĂs FEC order | see below 9 | sender's FEC order | see below
10 | SRTP authentication off/on | 0 if off, 1 if on 10 | SRTP authentication off/on | 0 if off, 1 if on
11 | Authentication tag length | in bytes 11 | Authentication tag length | in bytes
12 | SRTP prefix length | in bytes 12 | SRTP prefix length | in bytes
Table 6.10.1.a
Note that if a Type/Value is not set, the default one is used Note that if a Type/Value is not set, the default one is used
(according to SRTPs own criteria). (according to SRTPs own criteria).
For the Encryption algorithm, it is enough with a one byte length and For the Encryption algorithm, it is enough with a one byte length and
the currently defined possible Values are: the currently defined possible Values are:
SRTP encr alg | Value SRTP encr alg | Value
--------------------- ---------------------
NULL | 0 NULL | 0
AES-CM | 1 AES-CM | 1
AES-F8 | 2 AES-F8 | 2
where AES-CM is AES in CM and AES-F8 is AES in f8 mode [SRTP]. Table 6.10.1.b
where AES-CM is AES in CM, and AES-F8 is AES in f8 mode [SRTP].
For the Authentication algorithm, it is enough with a one byte length For the Authentication algorithm, it is enough with a one byte length
and the currently define possible Values are: and the currently define possible Values are:
SRTP auth alg | Value SRTP auth alg | Value
--------------------- ---------------------
NULL | 0 NULL | 0
HMAC-SHA1 | 1 HMAC-SHA-1 | 1
For the SRTP pseudo random function, it is also enough with a one Table 6.10.1.c
For the SRTP pseudo-random function, it is also enough with a one
byte length and the currently define possible Values are: byte length and the currently define possible Values are:
SRTP PRF | Value SRTP PRF | Value
--------------------- ---------------------
AES-CM | 0 AES-CM | 0
Table 6.10.1.d
If FEC is used at the same time as SRTP is used, MIKEY can negotiate If FEC is used at the same time as SRTP is used, MIKEY can negotiate
the order in which these should be applied at the sender side. the order in which these should be applied at the sender side.
FEC order | Value | Comments FEC order | Value | Comments
-------------------------------- --------------------------------
FEC-SRTP | 0 | First FEC, then SRTP FEC-SRTP | 0 | First FEC, then SRTP
SRTP-FEC | 1 | First SRTP, then FEC
Table 6.10.1.e
6.11. RAND payload (RAND) 6.11. RAND payload (RAND)
The RAND payload consist of a (pseudo)random bit-string. The RAND The RAND payload consists of a (pseudo-)random bit-string. The RAND
MUST be independently generated per CSB (note that the if a CSB has MUST be independently generated per CSB (note that the if a CSB has
several members, the Initiator MUST use the same RAND to all the several members, the Initiator MUST use the same RAND to all the
members). members). For randomness recommendations for security, see [RAND].
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 ! RAND len ! RAND ~ ! Next payload ! RAND len ! RAND ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload: identifies the payload that is added after this * Next payload (8 bits): identifies the payload that is added after
payload. this payload. See Section 6.1 for values.
* RAND len: Length of the RAND (in bytes). SHOULD be at least 16. * RAND len (8 bits): length of the RAND (in bytes). It SHOULD be at
least 16.
* RAND: a (pseudo)randomly chosen bit-string. * RAND (variable length): a (pseudo-)randomly chosen bit-string.
6.12. Error payload (ERR) 6.12. Error payload (ERR)
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 no ! Reserved ! ! Next Payload ! Error no ! Reserved !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * Next payload (8 bits): identifies the payload that is added after
payload. If no more payload follows, it is set to Last payload. See this payload. See Section 6.1 for values.
Section 6.1 for values.
* Error no indicates the type of error that was encountered. * Error no (8 bits): indicates the type of error that was
encountered.
Error no | Value | Comment Error no | Value | Comment
------------------------------------------------------- -------------------------------------------------------
Auth failure | 0 | Authentication failure Auth failure | 0 | Authentication failure
Invalid TS | 1 | Invalid timestamp Invalid TS | 1 | Invalid timestamp
Invalid PRF | 2 | PRF function not supported Invalid PRF | 2 | PRF function not supported
Invalid MAC | 3 | MAC algorithm not supported Invalid MAC | 3 | MAC algorithm not supported
Invalid EA | 4 | Encryption algorithm not supported Invalid EA | 4 | Encryption algorithm not supported
Invalid HA | 5 | Hash function not supported Invalid HA | 5 | Hash function not supported
Invalid DH | 6 | DH group not supported Invalid DH | 6 | DH group not supported
Invalid ID | 7 | ID not supported Invalid ID | 7 | ID not supported
Invalid Cert | 8 | Certificate not supported Invalid Cert | 8 | Certificate not supported
Invalid SP | 9 | SP type not supported Invalid SP | 9 | SP type not supported
Invalid SPpar | 10 | SP parameters not supported Invalid SPpar | 10 | SP parameters not supported
Invalid DT | 11 | not supported Data type
Unspecified error | 12 | an unspecified error occurred
Table 6.12
6.13. Key data sub-payload 6.13. Key data sub-payload
The Key data payload contains TGKs. The Key data payloads are never The Key data payload contains key material, e.g. TGKs. The Key data
included in clear, but as an encrypted part of the Key data transport payloads are never included in clear, but as an encrypted part of the
payload. Key data transport payload.
Note that a Key data transport payload can contain multiple Key data
sub-payloads.
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 ! Type ! KV ! Key data len ! ! Next Payload ! Type ! KV ! Key data len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key data ~ ! Key data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len (optional) ! Salt data (optional) ~ ! Salt len (optional) ! Salt data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV 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 * Next payload (8 bits): identifies the payload that is added after
that generally TEKs are not sent directly, but a TGK, which is then this payload. See Section 6.1 for values.
used to derive the TEK (or TEKs if there are several crypto sessions)
as described in Section 4.1.4.
Type | Value | Comments * Type (4 bits): indicates the type of the key included in the
--------------------------------------- payload.
TGK | 0 | A TGK (used to derive TEKs from)
TGK+SALT | 1 | A TGK + a salt key are included
TEK | 2 | A plain TEK
TEK+SALT | 3 | A plain TEK + a salt key are included
Type | Value
-----------------
TGK | 0
TGK+SALT | 1
TEK | 2
TEK+SALT | 3
Table 6.13.a
Note that the possibility to include a TEK (instead of using the TGK) Note that the possibility to include a TEK (instead of using the TGK)
is provided. However, if this is used, the TEK can generally not be is provided. When sent directly, the TEK can generally not be shared
shared between more than one Crypto Session. The recommended use of a between more than one Crypto Session (unless the Security protocol
TEK instead of a TGK is when pre-encrypted material exists and allows for this, e.g. [SRTP]). The recommended use of sending a TEK
therefore, the TEK must be known in advance. instead of a TGK is when pre-encrypted material exists and therefore,
the TEK must be known in advance.
* KV: Indicates the type of key validity period specified. This may * KV (4 bits): indicates the type of key validity period specified.
be done by using an SPI (or MKI in the case of [SRTP]) or by This may be done by using an SPI (or MKI in the case of [SRTP]) or by
providing an interval in which the key is valid (e.g., in the latter providing an interval in which the key is valid (e.g., in the latter
case, for SRTP this will be the index range where the key is valid). case, for SRTP this will be the index range where the key is valid).
KV | Value | Comments KV | Value | Comments
------------------------------------------- -------------------------------------------
Null | 0 | No specific usage rule (e.g. a TEK Null | 0 | No specific usage rule (e.g. a TEK
| | that has no specific lifetime) | | that has no specific lifetime)
SPI | 1 | The key is associated with the SPI/MKI SPI | 1 | The key is associated with the SPI/MKI
Interval | 2 | The key has a start and expiration time Interval | 2 | The key has a start and expiration time
| | (e.g. an SRTP TEK) | | (e.g. an SRTP TEK)
Table 6.13.b
Note that when NULL is specified, any SPI or Interval is valid. For 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 an Interval this means that the key is valid from the first observed
sequence number until the key is replaced (or the security protocol sequence number until the key is replaced (or the security protocol
is shutdown). is shutdown).
* Key data len: The length of the Key data field (in bytes). Note * Key data len (16 bits): the length of the Key data field (in
that the sum of the overall length of all the Key data sub-payloads bytes). Note that the sum of the overall length of all the Key data
contained in a single Key data transport payload (KEMAC) MUST be such payloads contained in a single Key data transport payload (KEMAC)
that the KEMAC payload does not exceed a length of 2^16 bytes (total MUST be such that the KEMAC payload does not exceed a length of 2^16
length of KEMAC, see Section 6.2). bytes (total length of KEMAC, see Section 6.2).
* Key data: The TGK or TEK data. * Key data (variable length): The TGK or TEK data.
* Salt len: The salt key length in bytes. Note that this field is * Salt len (16 bits): The salt key length in bytes. Note that this
only included if the salt is specified in the Type-field. 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 * Salt data (variable length): The salt key data. Note that this
if the salt is specified in the Type-field. (For SRTP, this is the field is only included if the salt is specified in the Type-field.
so-called master salt.) (For SRTP, this is the so-called master salt.)
* KV data: This includes either the SPI or an interval (see Section * KV data (variable length): This includes either the SPI or an
6.14). If KV is NULL, this field is not included. interval (see Section 6.14). If KV is NULL, this field is not
included.
6.14. Key validity data 6.14. Key validity data
The Key validity data is not a standalone payload, but part of either The Key validity data is not a standalone payload, but part of either
the Key data payload (see Section 6.13) or the DH payload (see the Key data payload (see Section 6.13) or the DH payload (see
Section 6.4). The Key validity data gives a guideline of when the key Section 6.4). The Key validity data gives a guideline of when the key
should be used. This can be done, using an SPI/MKI or a lifetime should be used. There are two KV types defined (see Section 6.13),
range. SPI/MKI (SPI) or a lifetime range (interval).
SPI/MKI SPI/MKI
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI Length ! SPI ~ ! SPI Length ! SPI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* SPI Length: The length of the SPI (or MKI) in bytes. * SPI Length (8 bits): the length of the SPI (or MKI) in bytes.
* SPI: The SPI (or MKI) value. * SPI (variable length): the SPI (or MKI) value.
Interval Interval
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VF Length ! Valid from ~ ! VF Length ! Valid From ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VT Length ! Valid to (expires) ~ ! VT Length ! Valid To (expires) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* VF Length: Length of the Valid From field in bytes. * VF Length (8 bits): length of the Valid From field in bytes.
* Valid From: Sequence number, index, timestamp, or other start value * Valid From (variable length): Sequence number, index, timestamp, or
that the security protocol uses to identify the start position of the other start value that the security protocol uses to identify the
key usage. start position of the key usage.
* VT Length: Length of the Valid To field in bytes. * VT Length (8 bits): length of the Valid To field in bytes.
* Valid to: Sequence number, index, timestamp, or other expiration * Valid To (variable length): sequence number, index, timestamp, or
value that the security protocol can use to identify the expiration other expiration value that the security protocol can use to identify
of the key usage. the expiration of the key usage.
Note that for SRTP usage, the key validity period for a TGK should be Note that for SRTP usage, the key validity period for a TGK/TEK
specified with either an interval, where the VF/VT length is equal to should be specified with either an interval, where the VF/VT Length
6 bytes (i.e., the size of the index), or, with an MKI. It is is equal to 6 bytes (i.e., the size of the index), or with an MKI. It
RECOMMENDED that if more than one SRTP stream is sharing the same 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 MKI keys and key update/re-keying is desired, this is handled using MKI
rather than the From-To method. rather than the From-To method.
6.15. General Extension Payload 6.15. General Extension Payload
The General extensions payload is included to allow possible The General extensions payload is included to allow possible
extensions to MIKEY without the need to define a complete new payload extensions to MIKEY without the need to define a complete new payload
each time. This payload can be used in any MIKEY message and is part each time. This payload can be used in any MIKEY message and is part
of the authenticated/signed data part. of the authenticated/signed data part.
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 ! Type ! Length ! ! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~ ! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload: identifies the payload that is added after this * Next payload (8 bits): identifies the payload that is added after
payload. this payload.
* Type: identifies the type of the general payload. * Type (8 bits): identifies the type of the general payload.
Type | Value | Comments Type | Value | Comments
--------------------------------------- ---------------------------------------
Vendor ID | 0 | Vendor specific byte string Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs (see also Section 7.1) SDP IDs | 1 | List of SDP key mgmt IDs (allocated for use in
[KMASDP])
* Length: the length in bytes of the Data field.
* Data: the general payload data.
7. 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
SIP/SDP and RTSP to carry key management protocol information.
7.1. SDP integration
SDP descriptions [SDP] can be carried by several protocols, such as
SIP and RTSP. Both SIP and RTSP often use SDP to describe the media
sessions. Therefore, it is also convenient to be able to integrate
the key management in the session description it is supposed to
protect. [KMASDP] describes attributes that should be used by a key
management protocol that is integrated in SDP. We refer to [KMASDP]
for both definitions and examples. Note that MIKEY SHALL use the name
"mikey" as a protocol identifier in SDP and RTSP. The key management
data that is placed in SDP or RTSP MUST be base64 encoded.
Following the requirements in [KMASDP] (to avoid certain types of
bidding down attacks when more than one key management protocol is
offered within SDP), MIKEY SHALL specify how to authenticate the list
of identifiers in SDP. In MIKEY, the list of protocol identifiers
MUST be input to MIKEY by SDP with ";" separated identifiers. All the
offered protocol identifiers MUST be included, in the same order as
they appear in the corresponding SDP description; if only MIKEY is
offered, the only protocol identifier to be included SHALL be
"mikey". MIKEY MUST place this list in a General Extension Payload
(of type "SDP IDs") which then automatically will be integrity
protected/signed. The receiver can then match the list in the General
Extension Payload with the list included in SDP and SHOULD (according
to policy) if they differ, or if integrity/signature verification
fails, reject the offer. Further description can be found in
[KMASDP].
7.2. MIKEY within SIP
In e.g., a basic SIP call (see Figure 7.1.), SIP (Session Initiation
Protocol, [SIP]) is used as a session 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|
|Server | SIP/MIKEY |Server |
--------- ---------
^ ^
. .
++++ SIP/MIKEY . . SIP/MIKEY ++++
| | <............. ..............> | |
| | | |
++++ <-------------------------------------------> ++++
SRTP
Fig 7.1.: SIP-based call example. The two parties uses MIKEY over SIP
to set up an SRTP stream between A and B.
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
Initiator's message is included, and in the answer to the offer, the
MIKEY Responder's message is included.
If the MIKEY part of the offer is not accepted, a MIKEY error message
is provided in the answer (following Section 5.1.2). The MIKEY
implementation signals to the SIP implementation whether the MIKEY
message was an acceptable offer or not.
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.
Updating of the CSB (e.g. TEK update) is only supposed to be seen as
a new offer. Note that it might not be necessary to send all
information, such as the certificate, due to the already established
call (see also Section 4.5).
7.3. MIKEY with RTSP
The Real Time Streaming Protocol (RTSP) [RTSP] is used to control
media streaming from a server. The media session is typically
obtained via an SDP description, received by a DESCRIBE message, or
by other means (e.g., HTTP). To be able to pass the MIKEY messages in
RTSP messages which does not contain an SDP description, the RTSP
KeyMgmt header (defined in [KMASDP]) is used. This header includes
basically the same fields as the SDP extensions. As for SDP, "mikey"
is used as the protocol identifier.
In an RTSP scenario, the RTSP server and the MIKEY Initiator will be
the same entity. The Initiator/RTSP server includes the MIKEY message
in an SDP description. When responding to this, the client uses the
defined 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
this case. This has some advantages. First, the server will always be
able to choose the key for the content it distributes. Secondly, it
will then have the possibility to use the same key for the same
content that are streamed/sent to more than one client.
To be able to have a server-initiated CSB update procedure, the
ANNOUNCE message is used to send the updated MIKEY material. Note
that the ANNOUNCE method has the ability to send SDP descriptions to
update previous ones (i.e., it is not required to use the RTSP
KeyMgmt header from server to client).
7.4. MIKEY Interface
The SDP, SIP, and RTSP processing is defined in [KMASDP]. However, it
is necessary that MIKEY can work properly with these protocols. This
subsection describes some aspects which implementers SHOULD consider.
If the MIKEY implementation is separate from the SDP/SIP/RTSP, an
application programming interface (API) between MIKEY and these
protocols is needed with certain functionality (however, exactly what
it looks like is implementation dependent).
Implementers of MIKEY are RECOMMENDED to consider providing at least
the following functionality:
* the possibility for 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 be provided to MIKEY.
* the possibility for MIKEY to receive incoming MIKEY messages and Table 6.15
return a status code from/to the SIP/RTSP application.
* the possibility for the SIP or RTSP applications to receive * Length (16 bits): the length in bytes of the Data field.
information from MIKEY. This would typically include the receiving of
the CSB ID or the SSRCs for SRTP. It is also RECOMMENDED that extra
information about errors can be received.
* the possibility for the SIP or RTSP application to receive outgoing * Data (variable length): the general payload data.
MIKEY messages.
* the possibility to tear down a MIKEY CSB (e.g. if the SIP session 7. Transport protocols
is closed, the CSB SHOULD also be closed).
Note that if a CSB has already been established, it is still valid MIKEY MAY be integrated within session establishment protocols.
for the SIP or RTSP implementation to request a new message from Currently integration of MIKEY within SIP/SDP and RTSP is defined in
MIKEY, e.g. when a new offer is issued. MIKEY SHOULD then send an [KMASDP]. MIKEY MAY use other transport, in which case it has to be
update message to the Responder (see also Section 4.5). defined how MIKEY is transported over such transport protocol.
8. Groups 8. Groups
What has been discussed up to now is not limited to single peer-to- What has been discussed up to now is not limited to single peer-to-
peer communication (except for the DH method), but can be used to peer communication (except for the DH method), but can be used to
distribute group keys for small-size interactive groups and simple distribute group keys for small-size interactive groups and simple
one-to-many scenarios. This section describes how MIKEY is used in a one-to-many scenarios. Section 2.1. describes the scenarios in the
group scenario (though, see also Section 4.3 for issues related to focus of MIKEY. This section describes how MIKEY is used in a group
scenario (though, see also Section 4.3 for issues related to
authorization). authorization).
8.1. Simple one-to-many 8.1. Simple one-to-many
++++ ++++
|S | |S |
| | | |
++++ ++++
| |
--------+-------------- - - --------+-------------- - -
skipping to change at page 47, line 33 skipping to change at page 48, line 33
group of clients. RTSP or SIP is used for the registration and the group of clients. RTSP or SIP is used for the registration and the
key management set up. The streaming server acts as the Initiator of key management set up. The streaming server acts as the Initiator of
MIKEY. In this scenario the pre-shared key or public key transport MIKEY. In this scenario the pre-shared key or public key transport
mechanism will be appropriate to use to transport the same TGK to all mechanism will be appropriate to use to transport the same TGK to all
the clients (which will result in common TEKs for the group). the clients (which will result in common TEKs for the group).
Note, if the same TGK/TEK(s) should be used by all the group members, Note, if the same TGK/TEK(s) should be used by all the group members,
the streaming server MUST specify the same CSB_ID and CS_ID(s) for the streaming server MUST specify the same CSB_ID and CS_ID(s) for
the session to all the group members. the session to all the group members.
As the communication may be performed using multicast, the members
need a common security policy if they want to be part of the group.
This limits the possibility for negotiation.
Furthermore, the Initiator should carefully consider whether to
request the verification message in reply from each receiver, as this
may result in a certain load for the Initiator itself, as the group
size increases.
8.2. Small-size interactive group 8.2. Small-size interactive group
As described in the overview section, for small-size interactive As described in the overview section, for small-size interactive
groups, one may expect that each client will be in charge for setting groups, one may expect that each client will be in charge for setting
up the security for its outgoing streams. In these scenarios, the up the security for its outgoing streams. In these scenarios, the
pre-shared key or the public-key transport method is used. pre-shared key or the public-key transport method is used.
++++ ++++ ++++ ++++
|A | -------> |B | |A | -------> |B |
| | <------- | | | | <------- | |
skipping to change at page 48, line 42 skipping to change at page 50, line 8
corresponds to the desired 96 bit level, with some margin). corresponds to the desired 96 bit level, with some margin).
In summary, key size for the key-exchange mechanism MUST be weighed In summary, key size for the key-exchange mechanism MUST be weighed
against the size of the exchanged TGK so that it offers at least the against the size of the exchanged TGK so that it offers at least the
required level. For efficiency reasons, one SHOULD also avoid a required level. For efficiency reasons, one SHOULD also avoid a
security overkill, e.g. by not using a public key transport with security overkill, e.g. by not using a public key transport with
public keys giving a security level that is orders of magnitude public keys giving a security level that is orders of magnitude
higher than length of the transported TGK. We refer to [LV] for higher than length of the transported TGK. We refer to [LV] for
concrete key size recommendations. concrete key size recommendations.
Moreover, if the TGKs are not random (or pseudorandom), a brute force Moreover, if the TGKs are not random (or pseudo-random), a brute
search may be facilitated, again lowering the effective key size. force search may be facilitated, again lowering the effective key
Therefore, care MUST be taken when designing the (pseudo) random size. Therefore, care MUST be taken when designing the (pseudo-)
generators for TGK generation, see [FIPS][RAND]. random generators for TGK generation, see [FIPS][RAND].
For the selection of the hash function, SHA-1 with 160-bit output is For the selection of the hash function, SHA-1 with 160-bit output is
the default one. In general, hash sizes should be twice the "security the default one. In general, hash sizes should be twice the "security
level", indicating that SHA1-256, [SHA256], should be used for the level", indicating that SHA-1-256, [SHA256], should be used for the
default 128-bit level. However, due to the real-time aspects in the default 128-bit level. However, due to the real-time aspects in the
scenarios we are treating, hash size slightly below 256 are scenarios we are treating, hash size slightly below 256 are
acceptable as the normal "existential" collision probabilities would acceptable as the normal "existential" collision probabilities would
be of secondary importance. be of secondary importance.
In a Crypto Session Bundle, the Crypto Sessions can share the same In a Crypto Session Bundle, the Crypto Sessions can share the same
TGK as discussed earlier. From a security point of view, the TGK as discussed earlier. From a security point of view, the
criterion to be satisfied is that the encryption of the individual criterion to be satisfied in case the TGK is shared, is that the
Crypto Sessions are performed "independently". In MIKEY this is encryption of the individual Crypto Sessions are performed
accomplished by having unique Crypto Session identifiers (see also "independently". In MIKEY this is accomplished by having unique
Section 4.1) and a TEK derivation method that provides Crypto Session identifiers (see also Section 4.1) and a TEK
cryptographically independent TEKs to distinct Crypto Sessions derivation method that provides cryptographically independent TEKs to
(within the Crypto Session Bundle), regardless of the security distinct Crypto Sessions (within the Crypto Session Bundle),
protocol used. regardless of the security protocol used.
Specifically, the key derivations, as specified in Section 4.1, are Specifically, the key derivations, as specified in Section 4.1, are
implemented by a pseudo-random function. The one used here is a implemented by a pseudo-random function. The one used here is a
simplified version of that used in TLS [TLS]. Here, only one single simplified version of that used in TLS [TLS]. Here, only one single
hash function is used, whereas TLS uses two different functions. This hash function is used, whereas TLS uses two different functions. This
choice is motivated by the high confidence in the SHA-1 hash choice is motivated by the high confidence in the SHA-1 hash
function, and, by efficiency and simplicity of design (complexity function, and by efficiency and simplicity of design (complexity does
does not imply security). Indeed, as shown in [DBJ], if one of the not imply security). Indeed, as shown in [DBJ], if one of the two
two hashes is severely broken, the TLS PRF is actually less secure hashes is severely broken, the TLS PRF is actually less secure than
than if a single hash had been used on the whole key, as is done in if a single hash had been used on the whole key, as is done in MIKEY.
MIKEY.
In the pre-shared key and public-key schemes, the TGK is generated by In the pre-shared key and public-key schemes, the TGK is generated by
a single party (Initiator). This makes MIKEY somewhat more sensitive a single party (Initiator). This makes MIKEY somewhat more sensitive
if the Initiator uses a bad random number generator. It should also if the Initiator uses a bad random number generator. It should also
be noted that neither the pre-shared nor the public-key scheme be noted that neither the pre-shared nor the public-key scheme
provides perfect forward secrecy. If mutual contribution or perfect provides perfect forward secrecy. If mutual contribution or perfect
forward secrecy is desired, the Diffie-Hellman method is to be used. forward secrecy is desired, the Diffie-Hellman method is to be used.
Authentication (e.g. signatures) in the Diffie-Hellman method is
required to prevent man-in-the-middle attacks.
Forward/backward security: if the TGK is exposed, all TEKs generated Forward/backward security: if the TGK is exposed, all TEKs generated
from it are compromised. However, under the assumption that the from it are compromised. However, under the assumption that 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 TGK. The Diffie-Hellman mode can be considered derived from the same TGK. The Diffie-Hellman mode can be considered
by cautious users as it is the only one that supports so called by cautious users as it is the only one that supports so called
perfect forward secrecy (PFS). This is in contrast to a compromise of perfect forward secrecy (PFS). This is in contrast to a compromise of
the pre-shared key (or the secret key of the public key mode), where the pre-shared key (or the secret key of the public key mode), where
future sessions and recorded session from the past are then also future sessions and recorded session from the past are then also
skipping to change at page 50, line 6 skipping to change at page 51, line 24
consecutive key updates, assuming the TGKs and RAND are each n bits consecutive key updates, assuming the TGKs and RAND are each n bits
long, is about L = n*(k+1)/2 bits, compared to the theoretical long, is about L = n*(k+1)/2 bits, compared to the theoretical
maximum of n*k bits. In other words, a 2^L work effort MAY enable an maximum of n*k bits. In other words, a 2^L work effort MAY enable an
attacker to get all k n-bit keys, which is better than brute force attacker to get all k n-bit keys, which is better than brute force
(except when k = 1). While this might seem as a defect, first note (except when k = 1). While this might seem as a defect, first note
that for proper choice of n, the 2^L complexity of the attack is way that for proper choice of n, the 2^L complexity of the attack is way
out of reach. Moreover, the fact that more than one key can be out of reach. Moreover, the fact that more than one key can be
compromised in a single attack is inherent to the key exchange compromised in a single attack is inherent to the key exchange
problematic. Consider for instance a user who, using say a fixed problematic. Consider for instance a user who, using say a fixed
1024-bit RSA key, exchanges keys and communicates during one or two 1024-bit RSA key, exchanges keys and communicates during one or two
years life-time of the public key. Breaking this single RSA key will years lifetime of the public key. Breaking this single RSA key will
enable access to all exchanged keys and consequently the entire enable access to all exchanged keys and consequently the entire
communication of that user over the whole period. communication of that user over the whole period.
All the pre-defined transforms in MIKEY use state-of-the-art All the pre-defined transforms in MIKEY use state-of-the-art
algorithms that has undergone large amounts of public evaluation. One algorithms that have undergone large amounts of public evaluation.
of the reasons to use AES-CM from SRTP [SRTP] is to have the One of the reasons to use AES-CM from SRTP [SRTP] is to have the
possibility to limit the overall number of different encryption modes possibility to limit the overall number of different encryption modes
and algorithms, at the same time that it offers a high level of and algorithms, at the same time that it offers a high level of
security. security.
9.2. Key lifetime 9.2. Key lifetime
Even if the lifetime of a TGK (or TEK) is not specified, it MUST be Even if the lifetime of a TGK (or TEK) is not specified, it MUST be
taken into account that the encryption transform in the underlying taken into account that the encryption transform in the underlying
security protocol can in some way degenerate after a certain amount security protocol can in some way degenerate after a certain amount
of encrypted data. It is not possible to here state general key life- of encrypted data. It is not possible to here state general key
time bounds, universally applicable; each security protocol should lifetime bounds, universally applicable; each security protocol
define such maximum amount and trigger a re-keying procedure before should define such maximum amount and trigger a re-keying procedure
the "exhaustion" of the key. E.g., according to SRTP [SRTP] the TEK before the "exhaustion" of the key. E.g., according to SRTP [SRTP]
MUST be changed at least every 2^48 SRTP packet (i.e. every time the the TEK, together with the corresponding TGK, MUST be changed at
ROC || SEQ no in SRTP wraps). least every 2^48 SRTP packet.
Still, the following can be said as a rule of thumb. If the security Still, the following can be said as a rule of thumb. If the security
protocol uses an "ideal" b-bit block cipher (in CBC mode, counter protocol uses an "ideal" b-bit block cipher (in CBC mode, counter
mode, or a feedback mode, e.g OFB, with full b-bit feedback), mode, or a feedback mode, e.g. OFB, with full b-bit feedback),
degenerate behavior in the crypto stream, possibly useful for an degenerate behavior in the crypto stream, possibly useful for an
attacker, is (with constant probability) expected to occur after a attacker, is (with constant probability) expected to occur after a
total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs). total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs).
For security margin, re-keying MUST be triggered well in advance For security margin, re-keying MUST be triggered well in advance
compared to the above bound. See [BDJR] for more details. 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.
9.3. Timestamps 9.3. Timestamps
skipping to change at page 50, line 53 skipping to change at page 52, line 20
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 roundtrip (i.e., two messages), but still allow a maximum of one roundtrip (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. For a detailed based version would require at least three messages. For a detailed
description of the timestamp and replay handling in MIKEY, see description of the timestamp and replay handling in MIKEY, see
Section 5.4. Section 5.4.
Practical experiences of Kerberos and other timestamp based systems Practical experiences of Kerberos and other timestamp-based systems
indicate that it is not always necessary to synchronize the terminals indicate that it is not always necessary to synchronize the terminals
over the network. Manual configuration could be a feasible over the network. Manual configuration could be a feasible
alternative in many cases (especially in scenarios where the degree alternative in many cases (especially in scenarios where the degree
of looseness is high). However, the choice must be carefully based of looseness is high). However, the choice must be carefully based
with respect to the usage scenario. with respect to the usage scenario.
9.4. Identity protection 9.4. Identity protection
Identity protection was not a main design goal for MIKEY. Such User privacy is a complex matter that to some extent can be enforced
feature will add more complexity to the protocol and was therefore by cryptographic mechanisms, but also requires policy enforcement and
chosen not to be included. As MIKEY is anyway proposed to be various other functionalities. One particular facet of privacy is
transported over e.g. SIP, the identity may be exposed by this. user identity protection. However, identity protection was not a main
However, if the transporting protocol is secured and also provides design goal for MIKEY. Such feature will add more complexity to the
identity protection, MIKEY might inherit the same feature. How this protocol and was therefore chosen not to be included. As MIKEY is
should be done is for future study. anyway proposed to be transported over e.g. SIP, the identity may be
exposed by this. However, if the transporting protocol is secured and
also provides identity protection, MIKEY might inherit the same
feature. How this should be done is for future study.
9.5. Denial of Service 9.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 IP addresses to create a large number of fake requests. This may
e.g., be solved by letting the protocol transporting MIKEY do an IP e.g., be solved by letting the protocol transporting MIKEY do an IP
address validity test. For example, the SIP protocol can provide this address validity test. For example, the SIP protocol can provide this
skipping to change at page 52, line 15 skipping to change at page 53, line 35
Re-direction of streams can of course be done even if it is not a Re-direction of streams can of course be done even if it is not a
group. However, the effect will not be the same compared to a group group. However, the effect will not be the same compared to a group
where impersonation can be done if SOA is not used. Instead, re- where impersonation can be done if SOA is not used. Instead, re-
direction will only deny the receiver the possibility to receive (or direction will only deny the receiver the possibility to receive (or
just delay) the data. just delay) the data.
10. IANA considerations 10. IANA considerations
This document defines several new name spaces associated with the This document defines several new name spaces associated with the
MIKEY payloads. This section summarizes the name spaces for which MIKEY payloads. This section summarizes the name spaces for which
IANA is requested to manage the allocation of values. A new port is IANA is requested to manage the allocation of values.
required for MIKEY for stand alone use (the assignment should be for
UDP, TCP, and SCTP).
IANA is requested to record the pre-defined values defined in the IANA is requested to record the pre-defined values defined in the
given sections for each name space. IANA is also requested to manage given sections for each name space. IANA is also requested to manage
the definition of additional values in the future. Unless explicitly the definition of additional values in the future. Unless explicitly
stated otherwise, values in the range 0-240 for each name space stated otherwise, values in the range 0-240 for each name space
should be approved by the process of IETF consensus and values in the SHOULD be approved by the process of IETF consensus and values in the
range 241-255 are reserved for Private Use. range 241-255 are reserved for Private Use, according to [RFC2434].
The name spaces for the following fields in the Common header payload The name spaces for the following fields in the Common header payload
(from Section 6.1) are requested to be managed by IANA: (from Section 6.1) are requested to be managed by IANA (in bracket is
the reference to the table with initial registered values):
* version * version
* data type * data type (Table 6.1.a)
* Next payload
* PRF func. This name space is between 0-127 where values between 0- * Next payload (Table 6.1.b)
111 should be approved by the process of IETF consensus and values * PRF func (Table 6.1.c). This name space is between 0-127 where
between 112-127 are reserved for Private Use. values between 0-111 should be approved by the process of IETF
consensus and values between 112-127 are reserved for Private Use.
* CS ID map type * CS ID map type (Table 6.1.d)
The name spaces for the following fields in the Key data transport The name spaces for the following fields in the Key data transport
payload (from Section 6.2) are requested to be managed by IANA: payload (from Section 6.2) are requested to be managed by IANA:
* Encr alg * Encr alg (Table 6.2.a)
* MAC alg * MAC alg (Table 6.2.b)
The name spaces for the following fields in the Envelope data payload
(from Section 6.3) are requested to be managed by IANA:
* C (Table 6.3)
The name spaces for the following fields in the DH data payload (from The name spaces for the following fields in the DH data payload (from
Section 6.4) are requested to be managed by IANA: Section 6.4) are requested to be managed by IANA:
* DH-Group * DH-Group (Table 6.4)
The name spaces for the following fields in the Signature payload
(from Section 6.5) are requested to be managed by IANA:
* S type (Table 6.5)
The name spaces for the following fields in the Timestamp payload The name spaces for the following fields in the Timestamp payload
(from Section 6.6) are requested to be managed by IANA: (from Section 6.6) are requested to be managed by IANA:
* TS type * TS type (Table 6.6)
The name spaces for the following fields in the ID payload and the The name spaces for the following fields in the ID payload and the
Certificate payload (from Section 6.7) are requested to be managed by Certificate payload (from Section 6.7) are requested to be managed by
IANA: IANA:
* ID type * ID type (Table 6.7.a)
* Cert type * Cert type (Table 6.7.b)
The name spaces for the following fields in the Cert hash payload The name spaces for the following fields in the Cert hash payload
(from Section 6.8) are requested to be managed by IANA: (from Section 6.8) are requested to be managed by IANA:
* Hash func * Hash func (Table 6.8)
The name spaces for the following fields in the Security policy The name spaces for the following fields in the Security policy
payload (from Section 6.10) are requested to be managed by IANA: payload (from Section 6.10) are requested to be managed by IANA:
* Prot type * Prot type (Table 6.10)
For each security protocol that uses MIKEY, a set of unique
parameters MAY be registered.
From Section 6.10.1. From Section 6.10.1.
* SRTP Type * SRTP Type (Table 6.10.1.a)
* SRTP encr alg * SRTP encr alg (Table 6.10.1.b)
* SRTP auth alg * SRTP auth alg (Table 6.10.1.c)
* SRTP PRF * SRTP PRF (Table 6.10.1.d)
* FEC order * FEC order (Table 6.10.1.e)
The name spaces for the following fields in the Error payload (from The name spaces for the following fields in the Error payload (from
Section 6.12) are requested to be managed by IANA: Section 6.12) are requested to be managed by IANA:
* Error no * Error no (Table 6.12)
The name spaces for the following fields in the Key data payload The name spaces for the following fields in the Key data payload
(from Section 6.13) are requested to be managed by IANA: (from Section 6.13) are requested to be managed by IANA:
* Type. This name space is between 0-16 which should be approved by * Type (Table 6.13.a). This name space is between 0-16 which should
the process of IETF consensus. be approved by the process of IETF consensus.
* KV. This name space is between 0-16 which should be approved by the * KV (Table 6.13.b). This name space is between 0-16 which should be
process of IETF consensus. approved by the process of IETF consensus.
The name spaces for the following fields in the General Extensions The name spaces for the following fields in the General Extensions
payload (from Section 6.15) are requested to be managed by IANA: payload (from Section 6.15) are requested to be managed by IANA:
* Type * Type (Table 6.15).
11. Conclusions 10.1 MIME Registration
Work for securing real-time applications have started to appear. This This section gives instructions to IANA to register the
has brought forward the need for a key management solution to support application/mikey MIME media type. This registration is as follows:
the security protocol. The key management has to fulfil requirements,
which make it suitable in the context of conversational multimedia in
a heterogeneous environment and small interactive groups. MIKEY is
designed to fulfill such requirements and optimized so that it also
may be integrated in other protocols such as SIP and RTSP.
MIKEY is designed to be used in scenarios for peer-to-peer MIME media type name : application
communication, simple one-to-many, and for small-size interactive MIME subtype name : mikey
groups without a centralized group server. Required parameters : none
Optional parameters : version
version: The MIKEY version number of the enclosed message
(e.g., 1). If not present, the version defaults to 1.
Encoding Considerations : binary, base64 encoded
Security Considerations : see section 9 in this memo
Interoperability considerations : none
Published specification : this memo
12. Acknowledgments 11. Acknowledgments
The authors would like to thank Mark Baugher, Ran Canetti, Martin The authors would like to thank Mark Baugher, Ran Canetti, Martin
Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with
his group), Rolf Blom, and Magnus Westerlund, for their valuable his group), Rolf Blom, Magnus Westerlund, Johan Bilien, Jon-Olov
feedback. Vatn, and Erik Eliasson for their valuable feedback.
13. Author's Addresses 12. 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@ericsson.com
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@ericsson.com
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@ericsson.com
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@ericsson.com
14. References 13. References
14.1. Normative References 13.1. Normative References
[AES] Advanced Encryption Standard (AES), Federal Information [AES] Advanced Encryption Standard (AES), Federal Information
Processing Standard Publications (FIPS PUBS) 197, November 2001. Processing Standard Publications (FIPS PUBS) 197, November 2001.
[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.
[KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
Norrman, K., "Key Management Extensions for SDP and RTSP", Internet
Draft, Work in Progress (MMUSIC WG).
[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.
[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 [PSS] PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories,
SDP", Internet Draft, IETF, Work in progress (MMUSIC). June 14, 2002, www.rsalabs.com
[RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Streaming Protocol (RTSP)", RFC 2326, April 1998. Requirement Levels", RFC 2119, March 1997.
[SDP] Handley, M., and Jacobson, V., "Session Description Protocol [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
(SDP), IETF, RFC2327 Considerations Section in RFCs", RFC 2434, October 1998.
[SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. [RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining
http://csrc.nist.gov/fips/fip180-1.ps Digital Signatures and Public-Key Cryptosystems". Communications of
the ACM. Vol.21. No.2. pp.120-126. 1978.
[SIP] Rosenberg, J. et al, "SIP: Session Initiation Protocol", IETF, [SHA-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
RFC3261. http://csrc.nist.gov/fips/fip180-1.ps
[SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M, [SRTP] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M,
Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol", Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol",
Internet Draft, IETF, Work in Progress (AVT WG). Internet Draft, IETF, Work in Progress (AVT WG).
[URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource [URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax", IETF, RFC 2396. Identifiers (URI): Generic Syntax", IETF, RFC 2396.
[X.509] Housley, R., Polk, W., Ford, W., and Solo, D., "Internet [X.509] Housley, R., Polk, W., Ford, W., and Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and Certificate X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", IETF, RFC 3280. Revocation List (CRL) Profile", IETF, RFC 3280.
[AESKW] Schaad, J., Housley R., "Advanced Encryption Standard (AES) [AESKW] Schaad, J., Housley R., "Advanced Encryption Standard (AES)
Key Wrap Algorithm", IETF, RFC 3394. Key Wrap Algorithm", IETF, RFC 3394.
14.2. Informative References 13.2. Informative References
[AKE] Canetti, R. and Krawczyk, H., "Analysis of Key-Exchange [AKE] Canetti, R. and Krawczyk, H., "Analysis of Key-Exchange
Protocols and their use for Building Secure Channels", Eurocrypt Protocols and their use for Building Secure Channels", Eurocrypt
2001, LNCS 2054, pp. 453-474, 2001. 2001, LNCS 2054, pp. 453-474, 2001.
[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.
[BMGL] Hastad, J. and Naslund, M.: "Practical Construction and [BMGL] Hastad, J. and Naslund, M.: "Practical Construction and
Analysis of Pseduo-randomness Primitives", Proceedings of Analysis of Pseduo-randomness Primitives", Proceedings of Asiacrypt
AsiacryptĂ01, Lecture Notes in Computer Science vol 2248, pp. 442- '01, Lecture Notes in Computer Science vol 2248, pp. 442-459.
459.
[DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use of [DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use of
MD5", Contribution to ANSI X9F1 WG, 2001. MD5", Contribution to ANSI X9F1 WG, 2001.
[FIPS] "Security Requirements for Cryptographic Modules", Federal [FIPS] "Security Requirements for Cryptographic Modules", Federal
Information Processing Standard Publications (FIPS PUBS) 140-2, Information Processing Standard Publications (FIPS PUBS) 140-2,
December 2002. December 2002.
[GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F., [GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.,
"Group Key Management Architecture", Internet Draft, Work in Progress "Group Key Management Architecture", Internet Draft, Work in Progress
skipping to change at page 56, line 54 skipping to change at page 58, line 35
RFC 2409, November 1998. RFC 2409, November 1998.
[ISO1] ISO/IEC 9798-3: 1997, Information technology - Security [ISO1] ISO/IEC 9798-3: 1997, Information technology - Security
techniques - Entity authentication - Part 3: Mechanisms using digital techniques - Entity authentication - Part 3: Mechanisms using digital
signature techniques. signature techniques.
[ISO2] ISO/IEC 11770-3: 1997, Information technology - Security [ISO2] ISO/IEC 11770-3: 1997, Information technology - Security
techniques - Key management - Part 3: Mechanisms using digital techniques - Key management - Part 3: Mechanisms using digital
signature techniques. signature techniques.
[LOA] Burrows, Abadi, and Needham, ˘A logic of authentication÷, ACM [ISO3] ISO/IEC 18014 Information technology - Security techniques -
Time-stamping services, Part 1-3.
[KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
Norrman, K., "Key Management Extensions for SDP and RTSP", Internet
Draft, Work in Progress (MMUSIC WG).
[LOA] Burrows, Abadi, and Needham, "A logic of authentication", ACM
Transactions on Computer Systems 8 No.1 (Feb. 1990), 18-36. Transactions on Computer Systems 8 No.1 (Feb. 1990), 18-36.
[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
[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.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams
C., "X.509 Internet Public Key Infrastructure Online Certificate C., "X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", IETF, RFC 2560. Status Protocol - OCSP", IETF, RFC 2560.
[PKCS1] PKCS #1 - RSA Cryptography Standard,
http://www.rsalabs.com/pkcs/pkcs-1/
[RAND] Eastlake, D., Schiller, J., and Crocker, S., "Randomness [RAND] Eastlake, D., Schiller, J., and Crocker, S., "Randomness
Requirements for Security", Internet Draft, Work in Progress. Requirements for Security", RFC 1750, December 1994.
[RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining [RTSP] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time
Digital Signatures and Public-Key Cryptosystems". Communications of Streaming Protocol (RTSP)", RFC 2326, April 1998.
the ACM. Vol.21. No.2. pp.120-126. 1978.
[SDP] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session
Description Protocol", Internet Draft, IETF, Work in progress
(MMUSIC), draft-ietf-mmusic-sdp-new-15.txt.
[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] Rosenberg, J. et al, "SIP: Session Initiation Protocol", IETF,
RFC3261.
[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.
Appendix A. - MIKEY - SRTP relation Appendix A. - MIKEY - SRTP relation
The terminology in MIKEY differs from the one used in SRTP as MIKEY The terminology in MIKEY differs from the one used in SRTP as MIKEY
needs to be more general. Therefore it might be hard to see the needs to be more general, nor is tight to SRTP only. Therefore it
relations between keys and parameters generated in MIKEY and the ones might be hard to see the relations between keys and parameters
used by SRTP. This section provides some hints on their relation. generated in MIKEY and the ones used by SRTP. This section provides
some hints on their relation.
MIKEY | SRTP MIKEY | SRTP
------------------------------------------------- -------------------------------------------------
Crypto Session | SRTP stream Crypto Session | SRTP stream (typically with related SRTCP stream)
Data SA | input to SRTP's crypto context Data SA | input to SRTP's crypto context
TEK | SRTP master key TEK | SRTP master key
The Data SA is built up by a TEK and the security policy exchanged. The Data SA is built up by a TEK and the security policy exchanged.
SRTP may use a MKI to index the TEK. The TEK is then derived from the SRTP may use a MKI to index the TEK, or TGK (the TEK is then derived
TGK that have the corresponding MKI. from the TGK that is associated with the corresponding MKI), see
below.
Revision History since -06 draft A.1 MIKEY-SRTP interactions
This section summarizes the most important changes in the document In the following, we give a brief outline of the interface between
since the last version. SRTP and MIKEY and the processing that takes place. We describe SRTP
receiver side only, the sender side will require analogous
interfacing.
- Section 2.5. "Existing Solutions" moved to Section 1.1. 1. When an SRTP packet arrives at the receiver and is processed, the
- Clarifications of scenarios (Section 2.1). triple <SSRC, destination address, destination port> is extracted
from the packet and used to retrieve the correct SRTP crypto context,
hence the Data SA. (The actual retrieval can e.g. be done by an
explicit request from the SRTP implementation to MIKEY, or, by the
SRTP implementation accessing a "data base", maintained by MIKEY. The
application will typically decide which implementation is preferred.)
- Number of clarifications in section 3. 2. If an MKI is present in the SRTP packet, it is used to point to
- Certificate discussions in Section 3.2 moved to new Section 4.3.1. the correct key within the SA. (Alternatively, if SRTPĂs <From, To>
feature is used, the ROC||SEQ of the packet is used to determine the
correct key.)
- How to use AES Key wrap added to Section 4.2.3. 3. Depending on whether the key sent in MIKEY (as obtained in step 2)
- How to add a new DH group added to section 4.2.9. was a TEK or a TGK, there are now two cases.
- New section about Certificate handling, policies and authorization
added (replaces the old Section 4.3).
- Examples in section 5.4 updated. - If the key obtained in step 2 is the TEK itself, it is used
directly by STRP as a master key.
- AES Key Wrap added as an optional mode in Section 6.2. - If the key instead is a TGK, the mapping with the CS_ID (internal
- Signature type field added in signature payload (Section 6.5). to MIKEY, Section 6.1.1) allows MIKEY to compute the correct TEK
from the TGK as described in Section 4.1 before SRTP uses it.
- More rational added to the security considerations (Section 9). If multiple TGKs (or TEKs) are sent, it is RECOMMENDED to associate
each TGK (or TEK) to a distinct MKI. It is RECOMMENDED to limit the
use of <From, To> in this scenario to very simple cases, e.g. one
stream only.
This Internet-Draft expires in December 2003. Besides the actual master key, other information in the Data SA (e.g.
transform identifiers) will of course also be communicated from MIKEY
to SRTP.
IPR Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires in June 2004.
 End of changes. 

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