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

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