draft-ietf-msec-mikey-06.txt   draft-ietf-msec-mikey-07.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 2003 M. Naslund Expires: December 2003 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
February, 2003 June, 2003
MIKEY: Multimedia Internet KEYing MIKEY: Multimedia Internet KEYing
<draft-ietf-msec-mikey-06.txt> <draft-ietf-msec-mikey-07.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 38 skipping to change at page 1, line 38
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
Security protocols for real-time multimedia applications have started Security protocols for real-time multimedia applications have started
to appear. This has brought forward the need for a key management to appear. This has brought forward the need for a key management
solution to support these protocols. Such a solution has to be solution to support these protocols.
suitable to be used in the context of conversational multimedia in a
heterogeneous environment.
This document describes a key management scheme that can be used for This document describes a key management scheme that can be used for
real-time applications (both for peer-to-peer communication and group real-time applications (both for peer-to-peer communication and group
communication), and shows how it may work together with protocols communication), and shows how it may work together with protocols
such as SIP and RTSP. 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. Existing solutions.............................................4
1.2. Definitions....................................................4 1.2. Notational Conventions.........................................4
1.3. Abbreviations..................................................5 1.3. Definitions....................................................4
1.4. Outline........................................................5 1.4. Abbreviations..................................................5
1.5. Outline........................................................6
2. Basic Overview...................................................6 2. Basic Overview...................................................6
2.1. Scenarios......................................................6 2.1. Scenarios......................................................6
2.2. Design Goals...................................................7 2.2. Design Goals...................................................7
2.3. System Overview................................................7 2.3. System Overview................................................8
2.4. Relation to GKMARCH............................................8 2.4. Relation to GKMARCH............................................9
2.5. Existing solutions.............................................9
3. Basic Key Transport and Exchange Methods.........................9 3. Basic Key Transport and Exchange Methods.........................9
3.1. Pre-shared key................................................10 3.1. Pre-shared key................................................11
3.2. Public-key encryption.........................................11 3.2. Public-key encryption.........................................12
3.3. Diffie-Hellman key exchange...................................13 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....................................................15
4.1.3. PRF Description.............................................15 4.1.3. PRF Description.............................................15
4.1.4. Generating keys from TGK....................................15 4.1.4. Generating keys from TGK....................................16
4.1.5. Generating keys from an envelope/pre-shared key.............15 4.1.5. Generating keys from an envelope/pre-shared key.............16
4.2 Pre-defined Transforms and Timestamp Formats...................16 4.2 Pre-defined Transforms and Timestamp Formats...................17
4.2.1 Hash functions...............................................16 4.2.1 Hash functions...............................................17
4.2.2 Pseudo random number generator and PRF.......................16 4.2.2 Pseudo random number generator and PRF.......................17
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........................18
4.2.5 Envelope Key encryption......................................17 4.2.5 Envelope Key encryption......................................18
4.2.6 Digital Signatures...........................................17 4.2.6 Digital Signatures...........................................18
4.2.7 Diffie-Hellman Groups........................................17 4.2.7 Diffie-Hellman Groups........................................18
4.2.8. Timestamps..................................................17 4.2.8. Timestamps..................................................18
4.2.9. Adding new parameters to MIKEY..............................18 4.2.9. Adding new parameters to MIKEY..............................19
4.3. Policies......................................................18 4.3. Certificates, Policies and Authorization......................19
4.4. Retrieving the Data SA........................................18 4.3.1. Certificate handling........................................19
4.5. TGK re-keying and CSB updating................................19 4.3.2. Authorization...............................................20
5. Behavior and message handling...................................20 4.3.3. Data Policies...............................................21
5.1. General.......................................................20 4.4. Retrieving the Data SA........................................21
5.1.1. Capability Discovery........................................20 4.5. TGK re-keying and CSB updating................................21
5.1.2. Error Handling..............................................21 5. Behavior and message handling...................................23
5.2. Creating a message............................................21 5.1. General.......................................................23
5.3. Parsing a message.............................................23 5.1.1. Capability Discovery........................................23
5.4. Replay handling and timestamp usage...........................23 5.1.2. Error Handling..............................................23
5.5. Reliability...................................................25 5.2. Creating a message............................................24
6. Payload Encoding................................................25 5.3. Parsing a message.............................................25
6.1. Common header payload (HDR)...................................25 5.4. Replay handling and timestamp usage...........................26
6.1.1. SRTP ID.....................................................28 5.5. Reliability...................................................28
6.2. Key data transport payload (KEMAC)............................28 6. Payload Encoding................................................28
6.3. Envelope data payload (PKE)...................................30 6.1. Common header payload (HDR)...................................28
6.4. DH data payload (DH)..........................................30 6.1.1. SRTP ID.....................................................31
6.5. Signature payload (SIGN)......................................31 6.2. Key data transport payload (KEMAC)............................31
6.6. Timestamp payload (T).........................................31 6.3. Envelope data payload (PKE)...................................33
6.7. ID payload (ID) / Certificate payload (CERT)..................32 6.4. DH data payload (DH)..........................................33
6.8. Cert hash payload (CHASH).....................................33 6.5. Signature payload (SIGN)......................................34
6.9. Ver msg payload (V)...........................................33 6.6. Timestamp payload (T).........................................35
6.10. Security Policy payload (SP).................................34 6.7. ID payload (ID) / Certificate payload (CERT)..................35
6.10.1. SRTP policy................................................35 6.8. Cert hash payload (CHASH).....................................36
6.11. RAND payload (RAND)..........................................36 6.9. Ver msg payload (V)...........................................37
6.12. Error payload (ERR)..........................................36 6.10. Security Policy payload (SP).................................37
6.13. Key data sub-payload.........................................37 6.10.1. SRTP policy................................................38
6.14. Key validity data............................................38 6.11. RAND payload (RAND)..........................................39
6.15. General Extension Payload....................................39 6.12. Error payload (ERR)..........................................40
7. Integration with session establishment protocols................40 6.13. Key data sub-payload.........................................40
7.1. SDP integration...............................................40 6.14. Key validity data............................................42
7.2. MIKEY within SIP..............................................41 6.15. General Extension Payload....................................43
7.3. MIKEY with RTSP...............................................42 7. Integration with session establishment protocols................43
7.4. MIKEY Interface...............................................42 7.1. SDP integration...............................................43
8. Groups..........................................................43 7.2. MIKEY within SIP..............................................44
8.1. Simple one-to-many............................................43 7.3. MIKEY with RTSP...............................................45
8.2. Small-size interactive group..................................44 7.4. MIKEY Interface...............................................45
9. Security Considerations.........................................44 8. Groups..........................................................46
9.1. General.......................................................44 8.1. Simple one-to-many............................................47
9.2. Key lifetime..................................................46 8.2. Small-size interactive group..................................47
9.3. Timestamps....................................................46 9. Security Considerations.........................................48
9.4. Identity protection...........................................47 9.1. General.......................................................48
9.5. Denial of Service.............................................47 9.2. Key lifetime..................................................50
9.6. Session establishment.........................................48 9.3. Timestamps....................................................50
10. IANA considerations............................................48 9.4. Identity protection...........................................51
11. Conclusions....................................................50 9.5. Denial of Service.............................................51
12. Acknowledgments................................................50 9.6. Session establishment.........................................51
13. Author's Addresses.............................................50 10. IANA considerations............................................52
14. References.....................................................51 11. Conclusions....................................................54
14.1. Normative References.........................................51 12. Acknowledgments................................................54
14.2. Informative References.......................................52 13. Author's Addresses.............................................54
Appendix A. - MIKEY - SRTP relation................................53 14. References.....................................................55
14.1. Normative References.........................................55
14.2. Informative References.......................................56
Appendix A. - MIKEY - SRTP relation................................57
Change History since -06 draft.....................................58
1. Introduction 1. Introduction
There has recently been work to define a security protocol for the There has recently been work to define a security protocol for the
protection of real-time applications running over RTP, [SRTP]. protection of real-time applications running over RTP, [SRTP].
However, a security protocol needs a key management solution to However, a security protocol needs a key management solution to
exchange keys, security parameters, etc. There are some fundamental exchange keys and related security parameters. There are some
properties that such a key management scheme has to fulfill with fundamental properties that such a key management scheme has to
respect to the kind of real-time applications (streaming, unicast, fulfill with respect to the kind of real-time applications (such as
groups, multicast, etc.) and to the heterogeneous nature of the streaming, unicast, groups, multicast) and also with respect to
scenarios dealt with. heterogeneous (mix of wired and wireless) networks.
This document describes a key management solution that addresses This document describes a key management solution that addresses
multimedia scenarios (e.g. SIP calls and RTSP sessions). The focus is multimedia scenarios (e.g. SIP calls and RTSP sessions). The focus is
on how to set up key management for secure multimedia sessions such on how to set up key management for secure multimedia sessions such
that requirements in a heterogeneous environment are fulfilled. that requirements in a heterogeneous environment are fulfilled.
1.1. Notational Conventions 1.1. Existing solutions
There is work done in IETF to develop key management schemes. For
example, IKE [IKE] is a widely accepted unicast scheme for IPsec, and
the MSEC WG is developing other schemes, addressed to group
communication [GDOI, GSAKMP]. For reasons discussed below, there is
however a need for a scheme with low latency, suitable for demanding
cases such as real-time data over heterogeneous networks, and small
interactive groups.
1.2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119. this document are to be interpreted as described in RFC-2119.
1.2. Definitions 1.3. Definitions
Crypto Session (CS): uni- or bi-directional data stream(s), protected Crypto Session (CS): uni- or bi-directional data stream(s), protected
by a single instance of a security protocol. E.g. when SRTP is used, by a single instance of a security protocol. E.g. when SRTP is used,
the Crypto Session may contain two streams, an RTP stream and the the Crypto Session will often contain two streams, an RTP stream and
corresponding RTCP as they are both protected by a single instance of the corresponding RTCP which are both protected by a single SRTP
SRTP (i.e. they share key and some other parameters). Cryptographic Context, i.e. share key and the bulk of security
parameters in the SRTP Cryptographic Context (default behavior in
[SRTP]). In the case of IPsec, a Crypto Session would represent an
instantiation of an IPsec SA. A Crypto Session can be viewed as a
Data SA (as defined in [GKMARCH]) and could therefore be mapped to
other security protocols if needed.
Crypto Session Bundle (CSB): collection of one or more Crypto Crypto Session Bundle (CSB): collection of one or more Crypto
Sessions, which can have common TEK Generation Keys and security Sessions, which can have common TEK Generation Keys and security
parameters. parameters.
Crypto Session ID: unique identifier for the Crypto Session within an Crypto Session ID: unique identifier for the Crypto Session within an
CSB. CSB.
Crypto Session Bundle ID: unique identifier for the CSB. Crypto Session Bundle ID: unique identifier for the CSB.
skipping to change at page 5, line 8 skipping to change at page 5, line 26
set of parameters/policies. set of parameters/policies.
PRF(k,x): a keyed pseudo-random function. PRF(k,x): a keyed pseudo-random function.
E(k,m): encryption of m with the key k. E(k,m): encryption of m with the key k.
PKx: the public key of x PKx: the public key of x
[] an optional piece of information [] an optional piece of information
{} denotes zero or more occurrences {} denotes zero or more occurrences
|| concatenation || concatenation
| OR (selection operator) | OR (selection operator)
^ exponentiation ^ exponentiation
XOR binary exclusive or XOR exclusive or
Bit and byte ordering: throughout the document bits and bytes are as Bit and byte ordering: throughout the document bits and bytes are as
usual indexed from left to right, with the leftmost bits/bytes being usual indexed from left to right, with the leftmost bits/bytes being
the most significant. the most significant.
1.3. Abbreviations 1.4. Abbreviations
AES Advanced Encryption Standard AES Advanced Encryption Standard
CM Counter Mode CM Counter Mode (as defined in [SRTP])
CS Crypto Session CS Crypto Session
CSB Crypto Session Bundle CSB Crypto Session Bundle
DH Diffie-Hellman DH Diffie-Hellman
DoS Denial of Service DoS Denial of Service
MAC Message Authentication Code MAC Message Authentication Code
MIKEY Multimedia Internet KEYing MIKEY Multimedia Internet KEYing
PK Public-Key PK Public-Key
PS Pre-Shared key PSK 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 TGK TEK Generation Key
1.4. Outline 1.5. Outline
Section 2 describes the basic scenarios and the design goals for Section 2 describes the basic scenarios and the design goals for
which MIKEY is intended. 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, and other general key management in Section 3. The key derivation, and other general key management
procedures are described in Section 4. procedures are described in Section 4.
skipping to change at page 6, line 6 skipping to change at page 6, line 27
This also includes message creation and parsing. This also includes message creation and parsing.
All definitions of the payloads in MIKEY are described in Section 6. All definitions of the payloads in MIKEY are described in Section 6.
As MIKEY can be carried in SDP over SIP or RTSP, Section 7 describes 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 8 focuses on how MIKEY is used in group scenarios. Section 8 focuses on how MIKEY is used in group scenarios.
The Security Considerations section (Section 9), gives a deeper The Security Considerations section (Section 9), gives a deeper
explanation on different security related topics. explanation of important security related topics.
2. Basic Overview 2. Basic Overview
2.1. Scenarios 2.1. Scenarios
MIKEY is mainly intended to be used for peer-to-peer, simple one-to- MIKEY is mainly intended to be used for peer-to-peer, simple one-to-
many, and small-size (interactive) groups. One of the main multimedia many, and small-size (interactive) groups. One of the main multimedia
scenarios considered when designing MIKEY has been the conversational scenarios considered when designing MIKEY has been the conversational
multimedia scenario, where users may interact and communicate in multimedia scenario, where users may interact and communicate in
real-time. In these scenarios it can be expected that peers set up real-time. In these scenarios it can be expected that peers set up
skipping to change at page 6, line 46 skipping to change at page 7, line 16
small interactive group), and many-to-many with a centralized server. 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 2.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 up parties where it may be desirable that the security is either set up
by mutual agreement or that each party sets up the security for its by mutual agreement or that each party sets up the security for its
own outgoing streams. own outgoing streams.
b) many-to-many, without a centralized control unit, e.g. for small- b) simple one-to-many (multicast), e.g. real-time presentations,
where the sender is in charge of setting up the security.
c) many-to-many, without a centralized control unit, e.g. for small-
size interactive groups where each party may set up the security for size interactive groups where each party may set up the security for
its own outgoing media. its own outgoing media. Two basic models may be used here. In the
first model, the initiator of the group acts as the group server (and
is the only one authorized to include new members). In the second
model, authorization information to include new members can be
delegated to other participants.
c) many-to-many, with a centralized control unit, e.g. for larger d) many-to-many, with a centralized control unit, e.g. for larger
groups with some kind of Group Controller that sets up the security. groups with some kind of Group Controller that sets up the security.
d) simple one-to-many (multicast), e.g. real-time presentations,
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.
When designing MIKEY, the main focus has been on case a, b, and d. When designing MIKEY, the main focus has been on case a, b, and c.
For scenario c, only the first model is covered by this document.
2.2. Design Goals 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 involved in the
generated key(s). communication have access to the 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 roundtrips. - minimal number of roundtrips.
* Tunneling. Possibility to "tunnel"/integrate MIKEY in session * Tunneling. Possibility to "tunnel"/integrate MIKEY in session
establishment protocols (e.g. SIP and RTSP). establishment protocols (e.g. SIP and RTSP).
* Independent of any specific security functionality of the * Independent of any specific security functionality of the
underlying transport. underlying transport.
2.3. System Overview 2.3. System Overview
One objective of MIKEY is to produce a Data security protocol SA One objective of MIKEY is to produce a Data security protocol SA
(Data SA), including a traffic-encrypting key (TEK), which is used as (Data SA), including a traffic-encrypting key (TEK), which is derived
the input to the security protocol. from a TEK Generation Key (TGK) and used as the input to the security
protocol.
MIKEY supports the possibility to negotiate keys and parameters for MIKEY supports the possibility to establish keys and parameters for
more than one security protocol at the same time. The concept of more than one security protocol at the same time. The concept of
Crypto Session Bundle (CSB) is used to denote a collection of one or Crypto Session Bundle (CSB) is used to denote a collection of one or
more Crypto Sessions that can have common TEK Generation Keys and more Crypto Sessions that can have common TEK Generation Keys and
security parameters. security parameters, but which obtain distinct TEKs from MIKEY.
The procedure of setting up a CSB and creating a TEK (and Data SA), The procedure of setting up a CSB and creating a TEK (and Data SA),
is done in accordance with Figure 2.2: is done in accordance with Figure 2.2:
1. A set of security parameters and TEK Generation Key(s) (TGK) are 1. A set of security parameters and TEK Generation Key(s) (TGK) are
agreed upon for the Crypto Session Bundle (this is done by one of the agreed upon for the Crypto Session Bundle (this is done by one of the
three alternative key transport/exchange mechanisms, see Section 3). three alternative key transport/exchange mechanisms, see Section 3).
2. The TGK(s) is used to derive (in a cryptographically secure way) a 2. The TGK(s) is used to derive (in a cryptographically secure way) a
TEK for each Crypto Session. TEK for each Crypto Session.
3. The TEK, together with the security protocol policy parameters 3. The TEK, together with the security protocol policy parameters
represent the Data SA, which is used as the input to the Security represent the Data SA, which is used as the input to the Security
Protocol. Protocol.
+-----------------+ +-----------------+
| CSB | | CSB |
| Key transport | | Key transport | (see Section 3)
| /exchange | | /exchange |
+-----------------+ +-----------------+
| : | :
| TGK : | TGK :
v : v :
+----------+ : +----------+ :
CS ID ->| TEK | : Security protocol CS ID ->| TEK | : Security protocol (see Section 4)
|derivation| : parameters (policies) |derivation| : parameters (policies)
+----------+ : +----------+ :
TEK | : TEK | :
v v v v
Data SA Data SA
| |
v v
+-------------------+ +-------------------+
| Crypto Session | | Crypto Session |
|(Security Protocol)| |(Security Protocol)|
skipping to change at page 8, line 40 skipping to change at page 9, line 12
Figure 2.2: Overview of the key management procedure. Figure 2.2: Overview of the key management procedure.
The security protocol can then either use the TEK directly, or, if The security protocol can then either use the TEK directly, or, if
supported, derive further session keys from the TEK (e.g. see SRTP supported, derive further session keys from the TEK (e.g. see SRTP
[SRTP]). It is however up to the security protocol to define how the [SRTP]). It is however up to the security protocol to define how the
TEK is used. TEK is used.
MIKEY can be used to update TEKs and the Crypto Sessions in a current MIKEY can be used to update TEKs and the Crypto Sessions in a current
Crypto Session Bundle (see Section 4.5). This is done by executing Crypto Session Bundle (see Section 4.5). This is done by executing
the transport/exchange phase once again to derive a new TGK (and the transport/exchange phase once again to obtain a new TGK (and
consequently the TEKs) or to update some other specific Crypto consequently derive new TEKs) or to update some other specific Crypto
Session parameters. Session parameters.
2.4. Relation to GKMARCH 2.4. Relation to GKMARCH
The Group key management architecture (GKMARCH) [GKMARCH] describes a The Group key management architecture (GKMARCH) [GKMARCH] describes a
general architecture for group key management protocols. MIKEY is a general architecture for group key management protocols. MIKEY is a
part of this architecture, and can be used as a so called part of this architecture, and can be used as a so called
Registration protocol. The main entities involved in the architecture Registration protocol. The main entities involved in the architecture
are a group controller/key server (GCKS), the receiver(s), and the are 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 sender could act as GCKS and push down keys to the
which pushes down keys to the receiver(s). Note that e.g., in a SIP- receiver(s).
initiated call, the sender may also be a receiver. As MIKEY addresses
small interactive groups, a member may dynamically change between
being a sender and receiver (or being both simultaneously).
2.5. Existing solutions
There is work done in IETF to develop key management schemes. For Note that e.g., in a SIP-initiated call, the sender may also be a
example, IKE [IKE] is a widely accepted unicast scheme for IPsec, and receiver. As MIKEY addresses small interactive groups, a member may
the MSEC WG is developing other schemes, addressed to group dynamically change between being a sender and receiver (or being both
communication [GDOI, GSAKMP]. For reasons discussed, there is however simultaneously).
a need for a scheme with low latency, suitable for demanding cases
such as real-time data over heterogeneous networks, and small
interactive groups.
3. Basic Key Transport and Exchange Methods 3. Basic Key Transport and Exchange Methods
The following sub-sections define three different methods to The following sub-sections define three different methods to
transport/exchange a TEK Generation Key (TGK): with the use of a pre- transport/establish a TEK Generation Key (TGK): with the use of a
shared key, public-key encryption, and Diffie-Hellman (DH) key pre-shared key, public-key encryption, and Diffie-Hellman (DH) key
exchange. The two first methods are of key transport type. In the exchange. In the following we for simplicity assume unicast
following we for simplicity assume unicast communication. In addition communication. In addition to the TGK, a random "nonce", denoted
to the TGK, a random "nonce", denoted RAND, is also transported. In RAND, is also transported. In all three cases, the TGK and RAND
all three cases, the TGK and RAND values are then used to derive TEKs values are then used to derive TEKs as described in Section 4.1.4.
as described in Section 4.1.4.
The pre-shared key method and the public-key method are both based on
key transport mechanisms, where the actual TGK is pushed (securely)
to the recipient(s). In the Diffie-Hellman method, the actual TGK is
instead derived from the Diffie-Hellman values exchanged between the
peers.
The pre-shared case is, by far, the most efficient way to handle the The pre-shared case is, by far, the most efficient way to handle the
key transport due to the use of symmetric cryptography only. This key transport due to the use of symmetric cryptography only. This
approach has also the advantage that only a small amount of data has approach has also the advantage that only a small amount of data has
to be exchanged. Of course, the problematic issue is scalability. to be exchanged. Of course, the problematic issue is scalability as
it is not always feasible to share individual keys with a large group
of peers. Therefore, this case mainly addresses scenarios such as
server-to-client and also those cases where the public-key modes have
already been used thus allowing to "cache" a symmetric key (see
below and Section 3.2).
Public-key cryptography can be used to create a scalable system. A Public-key cryptography can be used to create a scalable system. A
disadvantage with this approach is that it is more resource consuming disadvantage with this approach is that it is more resource consuming
than the pre-shared key approach. Another disadvantage is that in than the pre-shared key approach. Another disadvantage is that in
most cases a PKI (Public Key Infrastructure) is needed to handle the most cases a PKI (Public Key Infrastructure) is needed to handle the
distribution of public keys. Of course, it is possible to use public distribution of public keys. Of course, it is possible to use public
keys as pre-shared keys (e.g. by using self-signed certificates). keys as pre-shared keys (e.g. by using self-signed certificates). It
should also be noted that, as mentioned above, this method may be
used to establish a "cached" symmetric key that later can be used to
establish subsequent TGKs by using the pre-shared key method (hence,
the subsequent request can be executed more efficiently).
The Diffie-Hellman (DH) key exchange method has in general a higher The Diffie-Hellman (DH) key agreement method has in general a higher
resource consumption (both computationally and in bandwidth) than the resource consumption (both computationally and in bandwidth) than the
previous ones. However, it has the advantage of providing perfect previous ones. However, it has the advantage of providing perfect
forward secrecy (PFS). forward secrecy (PFS) and flexibility by allowing implementation in
several different finite groups.
Note that by using the DH method, the two involved parties will Note that by using the DH method, the two involved parties will
generate a unique random key (which neither of the parties are likely generate a unique random key (which neither of the parties are likely
to significantly affect the outcome of). Therefore, it is not to significantly affect the outcome of). Therefore, it is not
possible to use this DH method to establish a group TEK (as the possible to use this DH method to establish a group TEK (as the
different parties in the group would end up with different TEKs). It different parties in the group would end up with different TEKs). It
is not the intention of the DH method to work in this scenario, but is not the intention of the DH method to work in this scenario, but
be a good alternative in the special peer-to-peer case. be a good alternative in the special peer-to-peer case.
The following general notation is used: The following general notation is used:
HDR: The general MIKEY header, which includes MIKEY CSB related data HDR: The general MIKEY header, which includes MIKEY CSB related data
(e.g. CSB ID) and information mapping to the specific security (e.g. CSB ID) and information mapping to the specific security
protocol used. See Section 6.1 for payload definition. protocol used. See Section 6.1 for payload definition.
T: The timestamp. See Section 6.6 for payload definition and also T: The timestamp. See Section 6.6 for payload definition and also
Section 5.4 for other timestamp related information. Section 5.4 for other timestamp related information.
IDx: The identity of x. See Section 6.7 for payload definition. IDx: The identity of x. See Section 6.7 for payload definition.
RAND: Random bit-string, which is always included in the first RAND: Random/pseudorandom byte-string, which is always included in
message from the Initiator. It is not included in update messages of the first message from the Initiator. It is not included in update
a CSB. See Section 6.11 for payload definition. messages of a CSB. See Section 6.11 for payload definition.
SP: The security policies for the data security protocol. See SP: The security policies for the data security protocol. See
Section 6.10 for payload definition. Section 6.10 for payload definition.
3.1. Pre-shared key 3.1. Pre-shared key
In this method, the pre-shared secret key, s, is used to derive key In this method, the pre-shared secret key, s, is used to derive key
material for both the encryption (encr_key) and the integrity material for both the encryption (encr_key) and the integrity
protection (auth_key) as described in Section 4.1.5. The encryption protection (auth_key) as described in Section 4.1.5. The encryption
and authentication transforms are described in Section 4.2. and authentication transforms are described in Section 4.2.
skipping to change at page 10, line 46 skipping to change at page 11, line 26
{SP}, KEMAC ---> {SP}, KEMAC --->
R_MESSAGE = R_MESSAGE =
[<---] HDR, T, [IDr], V [<---] HDR, T, [IDr], V
The main objective of the Initiator's message is to transport one or The main objective of the Initiator's message is to transport one or
more TGKs and a set of data protocol parameters to the Responder in a more TGKs and a set of data protocol parameters to the Responder in a
secure manner. As the verification message from the Responder is secure manner. As the verification message from the Responder is
optional, the Initiator indicates in the HDR whether it requires a optional, the Initiator indicates in the HDR whether it requires a
verification message or not from the Responder. verification message or not from the Responder.
KEMAC = E(encr_key, {TGK}) || MAC(auth_key, I_MESSAGE). KEMAC = E(encr_key, {TGK}) || MAC
The KEMAC payload contains a set of encrypted sub-payloads and a MAC. The KEMAC payload contains a set of encrypted sub-payloads and a MAC.
Each sub-payload includes a, by the Initiator, randomly and Each sub-payload includes a, by the Initiator, randomly and
independently chosen TGK (and possible other related parameters, independently chosen TGK (and possible other related parameters,
e.g., the key lifetime). The MAC is a Message Authentication Code e.g., the key lifetime). The MAC is a Message Authentication Code
covering the entire MIKEY message (with the exception of the MAC covering the entire MIKEY message (with the exception of the MAC
field) using the authentication key, auth_key. See Section 6.2 for field itself) using the authentication key, auth_key. See Section 6.2
payload definition and Section 5.2 for exact definition of the MAC for payload definition and Section 5.2 for exact definition of the
calculation. MAC calculation.
The main objective of the verification message from the Responder is The main objective of the verification message from the Responder is
to obtain mutual authentication. to obtain mutual authentication. The verification, V, is a MAC
computed over the Responder's entire message (with the exception of
V = MAC(auth_key, R_MESSAGE||IDi||IDr||T). the Verification 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 Verification MAC calculation and Section 6.9 for payload
definition.
The verification, V, is a MAC computed over the Responder's entire The ID fields are optional. However, leaving out an ID can only be
message (with the exception of the MAC field), the timestamp (that done when it can be expected that the peer already knows the other
was included in the Initiator's message), and the two parties party's ID (otherwise it cannot look up the pre-shared key). This
identities, using the authentication key. See also Section 5.2 for could e.g. be the case if the ID is extracted from SIP.
the exact definition of the MAC calculation and Section 6.9 for
payload definition.
3.2. Public-key encryption 3.2. Public-key encryption
Initiator Responder Initiator Responder
I_MESSAGE = I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], {SP}, HDR, T, RAND, [IDi|CERTi], {SP},
[CHASH], KEMAC, PKE, SIGNi ---> [CHASH], KEMAC, PKE, SIGNi --->
R_MESSAGE = R_MESSAGE =
[<---] HDR, T, [IDr], V [<---] HDR, T, [IDr], V
The main objective of the Initiator's message is to transport one or The main objective of the Initiator's message is to transport one or
more TGKs and a set of data protocol parameters to the Responder in a more TGKs and a set of data protocol parameters to the Responder in a
secure manner. This is done using an envelope approach where the TGKs secure manner. This is done using an envelope approach where the TGKs
are encrypted (and integrity protected) with keys derived from a are encrypted (and integrity protected) with keys derived from a
randomly chosen "envelope key". The envelope key is sent to the randomly/pseudorandomly chosen "envelope key". The envelope key is
Responder encrypted with the public key of the Responder. sent to the Responder encrypted with the public key of the Responder.
The KEMAC contains a set of encrypted sub-payloads and a MAC:
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.
KEMAC = K || M KEMAC = E(encr_key, IDi || {TGK}) || MAC
K = E(encr_key, IDi || {TGK})
M = MAC(auth_key, K).
The KEMAC contains a set of encrypted sub-payloads and a MAC. The The first sub-payload is the identity of the Initiator (not a
first sub-payload is the identity of the Initiator (not a
certificate, but generally the same ID as the one specified in the certificate, but generally the same ID as the one specified in the
certificate). Each of the following sub-payloads includes a, by the certificate). Each of the following sub-payloads includes a, by the
Initiator, randomly and independently chosen TGK (and possible other Initiator, randomly and independently chosen TGK (and possible other
related parameters, e.g., the key lifetime). The encrypted part is related parameters, e.g., the key lifetime). The encrypted part is
then followed by a MAC, which is calculated over the KEMAC payload 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 with exception of the MAC field. The encr_key and the auth_key are
the envelope key, env_key (see Section 4.1.5). See also Section 6.2 derived from the envelope key, env_key, see Section 4.1.5. See also
for payload definition. Section 6.2 for payload definition.
PKE = E(PKr, env_key)
The PKE contains the encrypted envelope key. It is encrypted using The PKE contains the encrypted envelope key: PKE = E(PKr, env_key).
the Responder's public key. If the Responder posses several public It is encrypted using the Responder's public key. If the Responder
keys, the Initiator can use CHASH to indicate the key used. posses several public keys, the Initiator can use CHASH to indicate
the key used.
The SIGNi is a signature covering the entire MIKEY message, The SIGNi is a signature covering the entire MIKEY message (excluding
I_MESSAGE, using the Initiator's signature key. SIGN itself), using the Initiator's signature key (see also Section
5.2 for the exact definition).
The main objective of the verification message from the Responder is The main objective of the verification message from the Responder is
to obtain mutual authentication. It is calculated in the same way as to obtain mutual authentication. As the verification message V from
for the one in the pre-shared key mode (see also Section 5.2 for the the Responder is optional, the Initiator indicates in the HDR whether
exact definition). See Section 6.9 for payload definition. it requires a verification message or not from the Responder. V is
calculated in the same way as for the one in the pre-shared key mode
(see also Section 5.2 for the exact definition). See Section 6.9 for
payload definition.
Note that there will be one encrypted IDi and possibly also one Note that there will be one encrypted IDi and possibly also one
unencrypted IDi. The encrypted one is needed to avoid certain man-in- unencrypted IDi. The encrypted one is together with the MAC used as a
the-middle attacks, while the unencrypted is always useful for the countermeasure for certain man-in-the-middle attacks (while the
Responder to immediately identify the Initiator. unencrypted is always useful for the Responder to immediately
identify the Initiator). The encrypted IDi MUST always be verified to
be equal with the expected IDi.
It is possible to cache the envelope key, so that it can be used as a It is possible to cache the envelope key, so that it can be used as a
pre-shared key. It is not recommended to cache this key indefinitely pre-shared key. It is not recommended to cache this key indefinitely
(however it is up to the local policy to decide this). This function (however it is up to the local policy to decide this). This function
may be very convenient during the life-time of a Crypto Session may be very convenient during the life-time of a Crypto Session
Bundle, if a new crypto session needs to be added (or an expired one 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). If the Initiator indicates that the 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 envelope key should be cached, the key is at least to be cached
during the life-time of the entire CSB. during the life-time of the entire CSB.
Certificate handling may involve a number of additional tasks not The ID fields and certificate are optional. However, leaving out an
shown here, and effect the inclusion of certain parts of the message. ID (or certificate) can only be done when it can be expected that the
The following observations can, however, be made: peer already knows the other party's ID (or can obtain the
certificate in some other manner). This could e.g. be the case if the
* the Initiator typically has to find the certificate of the ID is extracted from SIP.
Responder in order to send the first message. If the Initiator does
not have the Responder's certificate already, this may involve one or
more roundtrips to a central directory agent.
* it will be possible for the Initiator to omit its own certificate
and rely on the Responder getting this certificate using other means.
However, we recommend doing this, only when it is reasonable to
expect that the Responder has cached the certificate from a previous
connection. Otherwise accessing the certificate would mean additional
roundtrips for the Responder as well.
* verification of the certificates using Certificate Revocation Lists For certificate handling, authorization and policies, see
(CRLs) or an on-line verification protocol may mean additional Section 4.3.
roundtrips for both parties. If a small number of roundtrips is
required for acceptable performance, it may be necessary to omit some
of these checks.
3.3. Diffie-Hellman key exchange 3.3. Diffie-Hellman key exchange
For a fixed, agreed upon, group, (G,*), for g in G and a natural For a fixed, agreed upon, cyclic group, (G,*), we let g denote a
number x, we let g^x denote g*g*..*g (x times). Choices for the generator for this group. Choices for the parameters are given in
parameters are given in Section 4.2.7. The other transforms below are Section 4.2.7. The other transforms below are described in Section
described in Section 4.2. 4.2.
With this method only one key is created, i.e. the DH-key, which is With this method only one key is created, i.e. the DH-key, which is
used as the TGK. used as the TGK. This implies that this method cannot be used to
create group keys, but only be used to create single peer-to-peer
keys. This method is OPTIONAL to implement.
Initiator Responder Initiator Responder
I_MESSAGE = I_MESSAGE =
HDR, T, RAND, [IDi|CERTi], HDR, T, RAND, [IDi|CERTi],
{SP}, DHi, SIGNi ---> {SP}, DHi, SIGNi --->
R_MESSAGE = R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi, <--- HDR, T, [IDr|CERTr], IDi,
DHr, DHi, SIGNr DHr, DHi, SIGNr
The main objective of the Initiator's message is to, in a secure way, The main objective of the Initiator's message is to, in a secure way,
provide the Responder with its DH value (i.e., DHi = g^xi, where xi provide the Responder with its DH value (i.e., DHi = g^(xi), where xi
is randomly and secretly chosen) and a set of data protocol MUST be randomly/pseudorandomly and secretly chosen) and a set of
parameters. data protocol parameters.
The SIGNi is a signature covering the Initiator's MIKEY message, The SIGNi is a signature covering the Initiator's MIKEY message,
I_MESSAGE, using the Initiator's signature key. I_MESSAGE, using the Initiator's signature key.
The main objective of the Responder's message is to, in a secure way, The main objective of the Responder's message is to, in a secure way,
provide the Initiator with its own DH value (i.e., DHr = g^xr, where provide the Initiator with its own DH value (i.e., DHr = g^(xr),
xr is randomly and secretly chosen). where xr MUST be randomly/pseudorandomly and secretly chosen).
The SIGNr is a signature covering the Responder's MIKEY message, The SIGNr is a signature covering the Responder's MIKEY message,
R_MESSAGE, using the Responder's signature key. R_MESSAGE, using the Responder's signature key (see also Section 5.2
for the exact definition).
The group parameters (e.g., the group G) are a set of parameters The group parameters (e.g., the group G, the generator g, etc) are a
chosen by the Initiator. Both parties calculate the TGK, g^(xi*xr) set of parameters chosen by the Initiator and signaled to the
from the exchanged DH-values. responder. Both parties calculate the TGK, g^(xi*xr) 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 certificates before the setup. Instead, posses any of the responder's certificates before the setup. Instead,
it is sufficient that the responder includes it's signing certificate it is sufficient that the responder includes it's signing certificate
in the response. in the response.
4. Key Management The ID fields and certificate are optional. However, leaving out an
ID (or certificate) can only be done when it can be expected that the
peer already knows the other party's ID (or can obtain the
certificate in some other manner). This could e.g. be the case if the
ID is extracted from SIP.
For certificate handling, authorization and policies, see
Section 4.3.
4. Selected Key Management Functions
4.1. Key Calculation 4.1. Key Calculation
We define in the following a general method (pseudo random function) We define in the following a general method (pseudo random function)
to derive one or more keys from a "master" key. This method is used to derive one or more keys from a "master" key. This method is used
to derive: to derive:
* TEKs from a TGK and the RAND value, * TEKs from a TGK and the RAND value,
* encryption, authentication, or salting key from a pre-shared/ * encryption, authentication, or salting key from a pre-shared/
envelope key and the RAND value. envelope key and the RAND value.
4.1.1. Assumptions 4.1.1. Assumptions
We assume that the following parameters are in place: We assume that the following parameters are in place:
csb_id: Crypto Session Bundle ID (32-bits unsigned integer) csb_id: Crypto Session Bundle ID (32-bits unsigned integer)
cs_id: The Crypto Session ID (8-bits unsigned integer) cs_id: The Crypto Session ID (8-bits unsigned integer)
RAND: An (at least) 128-bit random bit-string sent by the Initiator RAND: An (at least) 128-bit (pseudo)random bit-string sent by the
in the initial exchange. Initiator in the initial exchange.
The key derivation method has the following input parameters: The key derivation method has the following input parameters:
inkey: the input key to the derivation function. inkey: the input key to the derivation function.
inkey_len: the length in bits of the input key. inkey_len: the length in bits of the input key.
label: a specific label, dependent on the type of the key to be label: a specific label, dependent on the type of the key to be
derived, the RAND, and the session IDs. derived, the RAND, and the session IDs.
outkey_len: desired length in bits of the output key. outkey_len: desired length in bits of the output key.
The key derivation method has the following output: The key derivation method has the following output:
skipping to change at page 15, line 15 skipping to change at page 15, line 43
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,label), 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" SHALL 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, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ... PRF(inkey, label) = P(s_1, label, m) XOR P(s_2, label, m) XOR ...
XOR P(s_n, label, m). XOR P(s_n, label, m).
4.1.4. Generating keys from TGK 4.1.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 to generate a TEK: parameters to generate a TEK:
inkey: TGK inkey: TGK
inkey_len: length of TGK inkey_len: bit length of TGK
label: 0x2AD01C64 || cs_id || csb_id || RAND label: 0x2AD01C64 || cs_id || csb_id || RAND
outkey_len: length of the output TEK. outkey_len: bit length of the output TEK.
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.
A salt key can be derived from the TGK as well. This is done by using A salt key can be derived from the TGK as well. This is done by using
the constant 0x39A2C14B. the constant 0x39A2C14B.
skipping to change at page 16, line 12 skipping to change at page 16, line 44
This derivation is to form the symmetric encryption key (and salting This derivation is to form the symmetric encryption key (and salting
key) for the encryption of the TGK in the pre-shared key and public key) for the encryption of the TGK in the pre-shared key and public
key methods. This is also used to derive the symmetric key used for key methods. This is also used to derive the symmetric key used for
the message authentication code in these messages (and the the message authentication code in these messages (and the
corresponding verification messages). Hence, this derivation is corresponding verification messages). Hence, this derivation is
needed in order to get different keys for the encryption and the MAC needed in order to get different keys for the encryption and the MAC
(and in the case of the pre-shared key, it will result in fresh key (and in the case of the pre-shared key, it will result in fresh key
material for each new CSB). material for each new CSB).
inkey: the envelope key or the pre-shared key inkey: the envelope key or the pre-shared key
inkey_len: the length of inkey inkey_len: the bit length of inkey
label: 0x150533E1 || 0xFF || csb_id || RAND (for encryption key) label: 0x150533E1 || 0xFF || csb_id || RAND (for encryption key)
or or
0x2D22AC75 || 0xFF || csb_id || RAND (for auth. key) 0x2D22AC75 || 0xFF || csb_id || RAND (for auth. key)
or or
0x29B88916 || 0xFF || csb_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 bit length of the
key. authentication/encryption/salting key.
4.2 Pre-defined Transforms and Timestamp Formats 4.2 Pre-defined Transforms and Timestamp Formats
This section identifies standard transforms for MIKEY. The following This section identifies standard transforms for MIKEY. The following
transforms are mandatory to implement and support in the respective transforms are mandatory to implement and support in the respective
case. New transforms can be added in the future (see Section 4.2.9 case. New transforms can be added in the future (see Section 4.2.9
for further guidelines). for further guidelines).
4.2.1 Hash functions 4.2.1 Hash functions
In MIKEY, SHA-1 is the default hash function that is mandatory to In MIKEY, SHA-1 is the default hash function that is mandatory to
implement. implement.
4.2.2 Pseudo random number generator and PRF 4.2.2 Pseudo random number generator and PRF
A cryptographically secure pseudo random number generator MUST be A cryptographically secure random or pseudo random number generator
used for the generation of the keying material and nonces, e.g. MUST be used for the generation of the keying material and nonces,
[BMGL]. However, it is implementation specific which one to use (as e.g. [BMGL]. However, it is implementation specific which one to use
the choice will not affect the interoperability). (as the choice will not affect the interoperability).
For the key derivations, the PRF specified in Section 4.1, using SHA- For the key derivations, the PRF specified in Section 4.1, using SHA-
1 is mandatory to implement. This PRF MAY be extended by using SHA- 1 is mandatory to implement. This PRF MAY be extended by using SHA-
256, SHA-384, or SHA-512, instead of SHA-1. However, it is not 256, SHA-384, or SHA-512, instead of SHA-1. However, it is not
mandatory to support these. mandatory to support these.
4.2.3 Key data transport encryption 4.2.3 Key data transport encryption
The default and mandatory-to-implement key transport encryption is The default and mandatory-to-implement key transport encryption is
AES in counter mode, as defined in [SRTP], using a key as derived in AES in counter mode, as defined in [SRTP], using a 128-bit key as
Section 4.1.5, and using initialization vector derived in Section 4.1.5, and using initialization vector
IV = [S XOR (0x0000 || CSB ID || T)] || 0x0000, IV = [S XOR (0x0000 || CSB ID || T)] || 0x0000,
where S is a 112-bit salting key, also derived as in Section 4.1.5, where S is a 112-bit salting key, also derived as in Section 4.1.5,
and where T is the timestamp sent by the Initiator. 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 that can be encrypted to 2^23
bits, which is still enough for all practical purposes. bits, which is still enough for all practical purposes.
The NULL encryption algorithm (i.e., no encryption) can be used (but The NULL encryption algorithm (i.e., no encryption) can be used (but
is not mandatory to implement). Note that this MUST NOT be used is not mandatory to implement). Note that this MUST NOT be used
unless the underlying protocols can guarantee the security. The main unless the underlying protocols can guarantee the security. The main
reason for including this is for certain specific SIP scenarios, reason for including this is for certain specific SIP scenarios,
where SDP is protected end-to-end. For this scenario, MIKEY MAY be 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 used with the pre-shared key method and the NULL encryption and
authentication algorithm while relying on the security of SIP. Use authentication algorithm while relying on the security of SIP. Use
this option with caution! this option with caution!
The AES key wrap function [AESKW] is included as an optional (but not
mandatory to implement) method. If the key wrap function is used, the
NULL MAC is RECOMMENDED to be used when using the public key method
(NOT the pre-shared key method) as the key wrap itself will provide
integrity of the keys. The 128-bit key and a 64-bit salt, S, are
derived in accordance to Section 4.1.5 and the key wrap IV is then
set to S.
4.2.4 MAC and Verification Message function 4.2.4 MAC and Verification Message function
MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1 MIKEY uses a 160-bit authentication tag, generated by HMAC with SHA-1
as the mandatory to implement method, see [HMAC]. Authentication keys as the mandatory to implement method, see [HMAC]. Authentication keys
are derived according to Section 4.1.5. are derived according to Section 4.1.5. Note that the authentication
key size MUST be equal to the size of the hash function's output
(e.g. for HMAC-SHA-1, a 160-bit authentication key is used).
The NULL authentication algorithm (i.e., no MAC) can be used together The NULL authentication algorithm (i.e., no MAC) can be used together
with the NULL encryption algorithm (but is not mandatory to with the NULL encryption algorithm (but is not mandatory to
implement). Note that this MUST NOT be used unless the underlying implement). Note that this MUST NOT be used unless the underlying
protocols can guarantee the security. The main reason for including protocols can guarantee the security. The main reason for including
this is for certain specific SIP scenarios, where SDP is protected 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 end-to-end. For this scenario, MIKEY MAY be used with the pre-shared
key method and the NULL encryption and authentication algorithm while key method and the NULL encryption and authentication algorithm while
relying on the security of SIP. Use this option with caution! relying on the security of SIP. Use this option with caution!
skipping to change at page 17, line 50 skipping to change at page 18, line 41
The signature algorithm applied is defined by, and dependent on the The signature algorithm applied is defined by, and dependent on the
certificate used. certificate used.
4.2.7 Diffie-Hellman Groups 4.2.7 Diffie-Hellman Groups
The Diffie-Hellman key exchange uses OAKLEY 5 [OAKLEY] as mandatory The Diffie-Hellman key exchange uses OAKLEY 5 [OAKLEY] as mandatory
to implement. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are to implement. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are
not mandatory to implement). not mandatory to implement).
See Section 4.2.9 for the guidelines to specify a new DH Group to be
used within MIKEY.
4.2.8. Timestamps 4.2.8. Timestamps
The current defined timestamp is as defined in NTP [NTP], i.e. a 64- The timestamp is as defined in NTP [NTP], i.e. a 64-bit number in
bit number in seconds relative to 0h on 1 January 1900. An seconds relative to 0h on 1 January 1900. An implementation MUST be
implementation must be aware of (and take into account) the fact that aware of (and take into account) the fact that the counter will
the counter will overflow approximately every 136th year. It is overflow approximately every 136th year. It is RECOMMENDED that the
RECOMMENDED that the time is always specified in UTC. time is always specified in UTC.
4.2.9. Adding new parameters to MIKEY 4.2.9. Adding new parameters to MIKEY
There are two different parameter sets that can be added to MIKEY. There are two different parameter sets that can be added to MIKEY.
The first is a set of MIKEY transforms (needed for the exchange The first is a set of MIKEY transforms (needed for the exchange
itself), and the second is the data security protocol policies/ itself), and the second is the data security protocol policies/
parameters. parameters.
New transforms and parameters SHALL be added by registering a new New transforms and parameters SHALL be added by registering (with
number for the payload, and also if necessary, document how the new IANA) a new number for the concerned payload, and also if necessary,
transform/parameter is used. Sometimes it might be enough to point to document how the new transform/parameter is used. Sometimes it might
an already specified document for the usage, e.g., when adding a new be enough to point to an already specified document for the usage,
already standardized hash function. e.g., when adding a new already standardized hash function.
In the case of adding a new DH group, the group needs to be specified
in a companion RFC (it is RECOMMENDED that the specified group uses
the same format as used in [OAKLEY]). A number can then be assigned
by IANA for such a group to be used in MIKEY.
When adding support for a new data security protocol, the following When adding support for a new data security protocol, the following
MUST be specified: MUST be specified:
* A map sub payload (see Section 6.1). This is used to be able to map * A map sub payload (see Section 6.1). This is used to be able to map
a crypto session to the right instance of the data security protocol a crypto session to the right instance of the data security protocol
and possibly also to provide individual parameters for each data and possibly also to provide individual parameters for each data
security protocol. security protocol.
* a policy payload, i.e., specification of parameters and supported * a policy payload, i.e., specification of parameters and supported
values. values.
* general guidelines of usage. * general guidelines of usage.
4.3. Policies 4.3. Certificates, Policies and Authorization
4.3.1. Certificate handling
Certificate handling may involve a number of additional tasks not
shown here, and effect the inclusion of certain parts of the message
(c.f. [X.509]). The following observations can, however, be made:
* The Initiator typically has to find the certificate of the
Responder in order to send the first message. If the Initiator
does not have the Responder's certificate already, this may
involve one or more roundtrips to a central directory agent.
* It will be possible for the Initiator to omit its own certificate
and rely on the Responder getting this certificate using other
means. However, we recommend doing this, only when it is
reasonable to expect that the Responder has cached the certificate
from a previous connection. Otherwise accessing the certificate
would mean additional roundtrips for the Responder as well.
* Verification of the certificates using Certificate Revocation Lists
(CRLs) [X.509] or protocols such as OCSP [OCSP] may be necessary.
All parties in a MIKEY exchange should have a local policy which
dictates whether such checks are made, how they are made, and how
often they are made. Note that performing the checks may imply
additional messaging.
4.3.2. Authorization
In general, there are two different models for making authorization
decisions for both the Initiator and the Responder, in the context of
the applications targeted by MIKEY:
* Specific peer-peer configuration. The user has configured the
application to trust a specific peer.
When pre-shared secrets are used, this is pretty much the only
available scheme. Typically, the configuration/entering of the
pre-shared secret is taken to mean that authorization is implied.
In some cases one could use this also with public keys, e.g. if
two peers exchange keys offline and configure them to be used for
the purpose of running MIKEY.
* Trusted root. The user accepts all peers that can prove to have a
certificate issued by a specific CA. The granularity of
authorization decisions is not very precise in this method.
In order to make this method possible, all participants in the
MIKEY protocol need to configure one or more trusted roots. The
participants also need to be capable of performing certificate
chain validation, and possibly transfer more than a single
certificate in the MIKEY messages (see also Section 6.7).
In practice, a combination of both mentioned methods might be
advantageous. Also, the possibility for a user to explicitly exclude
a specific peer (or sub tree) in a trust chain might be needed.
These authorization policies address the MIKEY scenarios a-c of
Section 2.1, where the Initiator acts as the group owner and who is
also the only one that can invite others. This implies that for each
Responder, the distributed keys MUST NOT be re-distributed to other
parties.
In a many-to-many situation, where the group control functions are
distributed (and/or where it is possible to delegate the group
control function to others), there MUST exist means to distribute
authorization information about who may be added to the group.
However, it is out of scope for this document to specify how this
should be done.
For any broader communication situation, an external authorization
infrastructure may be used (following the assumptions of [GKMARCH]).
4.3.3. Data Policies
Included in the message exchange, policies for the Data security Included in the message exchange, policies for the Data security
protocol are transmitted. The policies are defined in a separate protocol are transmitted. The policies are defined in a separate
payload and are specific to the security protocol (see also Section payload and are specific to the security protocol (see also Section
6.10). Together with the keys, the validity period of these can also 6.10). Together with the keys, the validity period of these can also
be specified. This can be done e.g., with an SPI (or SRTP MKI) or be specified. This can be done e.g., with an SPI (or SRTP MKI) or
with an Interval (e.g. a sequence number interval for SRTP), with an Interval (e.g. a sequence number interval for SRTP),
depending on the security protocol. depending on the security protocol.
New parameters can be added to a policy by documenting how they New parameters can be added to a policy by documenting how they
skipping to change at page 19, line 49 skipping to change at page 22, line 26
As explained in Section 3.2, the envelope key can be "cached" as a As explained in Section 3.2, the envelope key can be "cached" as a
pre-shared key (this is indicated by the Initiator in the first pre-shared key (this is indicated by the Initiator in the first
message sent). If so, the update message is a pre-shared key message message sent). If so, the update message is a pre-shared key message
(with the cached envelope key as the pre-shared key), i.e., it MUST (with the cached envelope key as the pre-shared key), i.e., it MUST
NOT be a public key message. If the public key message is used, but NOT be a public key message. If the public key message is used, but
the envelope key is not cached, the Initiator MUST provide a new the envelope key is not cached, the Initiator MUST provide a new
encrypted envelope key that can be used in the verification message. encrypted envelope key that can be used in the verification message.
However, the Initiator does not need to provide any other keys. However, the Initiator does not need to provide any other keys.
Figure 4.1 visualizes the update messages that can be sent, including Figure 4.1 visualizes the update messages that can be sent, including
the optional parts. The big differences from the original message is the optional parts. The big difference from the original message is
mainly that it is optional to include TGKs (or DH values in the DH mainly that it is optional to include TGKs (or DH values in the DH
method). method). See also Section 3 for more details of the specific methods.
By definition, a Crypto Session Bundle can contain several Crypto By definition, a Crypto Session Bundle can contain several Crypto
Sessions. A problem that then might occur is to synchronize the TGK 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 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 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.
Initiator Responder Initiator Responder
Pre-shared key method: Pre-shared key method:
skipping to change at page 20, line 36 skipping to change at page 23, line 15
I_MESSAGE = I_MESSAGE =
HDR, T, [IDi|CERTi], {SP}, HDR, T, [IDi|CERTi], {SP},
[DHi], SIGNi ---> [DHi], SIGNi --->
R_MESSAGE = R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi, <--- HDR, T, [IDr|CERTr], IDi,
[DHr, DHi], SIGNr [DHr, DHi], SIGNr
Figure 4.1: Update messages. Figure 4.1: Update messages.
Note that for the DH method, if the Initiator includes the DHi
payload, then the responder MUST include DHr, DHi. If the initiator
does not include DHi, the responder MUST NOT include DHr, DHi.
5. Behavior and message handling 5. Behavior and message handling
Each message that is sent by the Initiator or the Responder, is built Each message that is sent by the Initiator or the Responder, is built
by a set of payloads. This section describes how messages are created by a set of payloads. This section describes how messages are created
and also when they can be used. and also when they can be used.
5.1. General 5.1. General
5.1.1. Capability Discovery 5.1.1. Capability Discovery
skipping to change at page 21, line 39 skipping to change at page 24, line 19
The error message should be formed as: The error message should be formed as:
HDR, T, {ERR}, [V|SIGNr] HDR, T, {ERR}, [V|SIGNr]
Note that if the failure is due to the inability to authenticate the Note that if the failure is due to the inability to authenticate the
peer, the error message is OPTIONAL, and does not need to be peer, the error message is OPTIONAL, and does not need to be
authenticated. It is up to the local policy how to treat this kind of authenticated. It is up to the local policy how to treat this kind of
messages. However, if a signed error message in response to a failed messages. However, if a signed error message in response to a failed
authentication is returned this can be used for DoS purposes. authentication is returned this can be used for DoS purposes.
Similarly, an unauthenticated error message could be sent to the Similarly, an unauthenticated error message could be sent to the
Initiator in order to fool her to tear down the CSB. The local policy Initiator in order to fool her to tear down the CSB. It is highly
MUST take this into consideration. One advice would be not to RECOMMENDED that the local policy takes this into consideration. One
authenticate such an error message, and when receiving an advice would be not to authenticate such an error message, and when
unauthenticated error message only see it as a recommendation of what receiving an unauthenticated error message only see it as a
may have gone wrong. recommendation of what may have gone wrong.
5.2. Creating a message 5.2. Creating a message
To create a MIKEY message, a Common header payload is first created. To create a MIKEY message, a Common header payload is first created.
This payload is then followed, depending on the message type, by a This payload is then followed, depending on the message type, by a
set of information payloads (e.g. DH-value payload, Signature set of information payloads (e.g. DH-value payload, Signature
payload, Security Protocol payload). The defined payloads and the payload, Security Protocol payload). The defined payloads and the
exact encoding of each payload are described in Section 6. exact encoding of each payload are described in Section 6.
1 2 3 1 2 3
skipping to change at page 22, line 47 skipping to change at page 25, line 24
exchange definitions for payloads that may be included and exchange definitions for payloads that may be included and
recommended order). recommended order).
* As a last step (for messages that must be authenticated, this also * As a last step (for messages that must be authenticated, this also
include the verification message), create and concatenate the include the verification message), create and concatenate the
MAC/signature payload without the MAC/signature field filled in (if a MAC/signature payload without the MAC/signature field filled in (if a
Next payload field is included in this payload, it is set to Last Next payload field is included in this payload, it is set to Last
payload). payload).
* Calculate the MAC/signature over the entire MIKEY message, except * Calculate the MAC/signature over the entire MIKEY message, except
the MAC/Signature field, and add put the MAC/signature in the field. the MAC/Signature field, and add the MAC/signature in the field. In
In the case of the verification message, the IDi || IDr || T MUST the case of the verification message, the Identity_i || Identity_r ||
follow directly after the MIKEY message in the MAC calculation. Timestamp MUST follow directly after the MIKEY message in the
Verification MAC calculation. Note that the identities and the
timestamp that are added are identical to those transported in the ID
and T payloads.
In the public key case, the Key data transport payload is generated In the public key case, the Key data transport payload is generated
by concatenating the IDi with the TGKs. This is then encrypted and 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 placed in the data field. The MAC is calculated over the entire Key
data transport payload except the MAC field. Before calculating the data transport payload except the MAC field. Before calculating the
MAC, the Next payload field is set to zero. MAC, the Next payload field is set to zero.
Note that all messages from the Initiator MUST use a unique Note that all messages from the Initiator MUST use a unique
timestamp. The Responder does not create a new timestamp, but uses timestamp. The Responder does not create a new timestamp, but uses
the timestamp used by the Initiator. the timestamp used by the Initiator.
skipping to change at page 23, line 34 skipping to change at page 26, line 16
the default one). the default one).
* Verify the MAC/signature. * Verify the MAC/signature.
* If the authentication is not successful, an Auth failure Error * If the authentication is not successful, an Auth failure Error
message is possibly sent to the Initiator (if SIP is used, this is message is possibly sent to the Initiator (if SIP is used, this is
signaled to SIP as a rejection of the offer). The message is then signaled to SIP as a rejection of the offer). The message is then
discarded from further processing. See also Section 5.1.2 for discarded from further processing. See also Section 5.1.2 for
treatment of errors. treatment of errors.
* If the authentication is successful, the message is processed. * If the authentication is successful, the message is processed and
Though how it is processed is implementation specific. also added to the replay cache. How it is processed is implementation
specific. Note also that it is only successfully authenticated
messages that are stored in the replay cache.
* If any unsupported parameters or errors occur during the * If any unsupported parameters or errors occur during the
processing, these are reported to the Initiator by sending an error processing, these are reported to the Initiator by sending an error
message. The processing is then aborted. The error message can also message. The processing is then aborted. The error message can also
include payloads to describe the supported parameters. If SIP is include payloads to describe the supported parameters. If SIP is
used, this is signaled to SIP as a rejection of the offer (see also used, this is signaled to SIP as a rejection of the offer (see also
Section 7.2). Section 7.2).
* If the processing was successful and if needed, a verification/ * If the processing was successful and if needed, a verification/
response message is created and sent to the Initiator. response message is created and sent to the Initiator.
5.4. Replay handling and timestamp usage 5.4. Replay handling and timestamp usage
MIKEY does not use a challenge-response mechanism for replay handling MIKEY does not use a challenge-response mechanism for replay handling
instead timestamps are used. This requires that the clocks are instead timestamps are used. This requires that the clocks are
synchronized. The required synchronization is dependent on the number synchronized. The required synchronization is dependent on the number
of messages that can be cached. If we could assume an unlimited of messages that can be cached (note though, that the replay cache
cache, the terminals would not need to be synchronized at all (as the only contain messages that has been successfully authenticated). If
cache could then contain all previous messages). However, if there we could assume an unlimited cache, the terminals would not need to
are restrictions on the size of the replay cache, the clocks will be synchronized at all (as the cache could then contain all previous
need to be synchronized to some extent. In short, one can in general messages). However, if there are restrictions on the size of the
say that it is a tradeoff between the size of the replay cache and replay cache, the clocks will need to be synchronized to some extent.
the required synchronization. In short, one can in general say that it is a tradeoff between the
size of the replay cache and the required synchronization.
Timestamp usage prevents against replay attacks under the following Timestamp usage prevents against replay attacks under the following
assumptions: assumptions:
* Each host have a clock which is at least "loosely synchronized" to * Each host have a clock which is at least "loosely synchronized" to
the clocks of the other hosts. the clocks of the other hosts.
* If the clocks are to be synchronized over the network, a secure * If the clocks are to be synchronized over the network, a secure
network clock synchronization protocol is used. network clock synchronization protocol is used.
* Each Responder utilizes a replay cache in order to remember the * Each Responder utilizes a replay cache in order to remember the
messages presented within an allowable clock skew (which is set by successfully authenticated messages presented within an allowable
the local policy). clock skew (which is set by the local policy).
* Replayed and outdated messages, i.e., messages that can be found in * Replayed and outdated messages, i.e., messages that can be found in
the replay cache or which have an outdated timestamp, are discarded the replay cache or which have an outdated timestamp, are discarded
and not processed. and not processed.
* If the host loses track of the incoming requests (e.g. due to * If the host loses track of the incoming requests (e.g. due to
overload), it rejects all incoming requests until the clock skew overload), it rejects all incoming requests until the clock skew
interval has passed. interval has passed.
In a client-server scenario, servers may be the entities that will In a client-server scenario, servers may be the entities that will
have the highest work load. It is therefore RECOMMENDED that the have the highest work load. It is therefore RECOMMENDED that the
servers are the Initiators of MIKEY. This will result in 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 servers will not need to manage any significant replay cache as they
will refuse all incoming messages that are not a response to an will refuse all incoming messages that are not a response to an
already (by the server) sent message. already (by the server) sent message.
In general, a client may not expect a very high load of incoming In general, a client may not expect a very high load of incoming
messages and may therefore allow the degree of looseness to be on the messages and may therefore allow the degree of looseness to be on the
order of minutes (5-10 minutes are believed to be acceptable). If a order of several minutes to hours. If a (D)DoS attack is launched and
DoS attack is launched and the replay cache grows too large, MIKEY the replay cache grows too large, MIKEY MAY dynamically decrease the
MAY dynamically decrease the looseness so that the replay cache looseness so that the replay cache becomes manageable (however, note
becomes manageable. that such (D)DoS can only be performed by peers that can authenticate
themselves). Another, way to treat the problem is of course to reject
all incoming messages from the specific peer(s) that executes the
attack.
The maximum number of messages that a client will need to cache may The maximum number of messages that a client will need to cache may
vary depending on the capacity of the client itself and the network, vary depending on the capacity of the client itself and the network,
but also the number of expected messages should be taken into but also the number of expected messages should be taken into
account. account.
For example, assume that we can at most spend 6kB on a replay cache. For example, assume that we can at most spend 6kB on a replay cache.
Assume further that we need to store 30 bytes for each incoming Assume further that we need to store 30 bytes for each incoming
message (the hash of the message is 20 bytes). This implies that it authenticated message (the hash of the message is 20 bytes). This
is possible to cache approximately 204 messages. If the expected implies that it is possible to cache approximately 204 messages. If
number of messages per minute can be estimated, the clock skew can the expected number of messages per minute can be estimated, the
easily be calculated. E.g., in a SIP scenario where the client is clock skew can easily be calculated. E.g., in a SIP scenario where
expected in the most extreme case, a few calls per minute (assume 10 the client is expected in the most extreme case to receive 10 calls
at most in this example), the clock skew that can be used is per minute, the clock skew needed is then approximately 20 minutes.
approximately 20 minutes. In a not so extreme setting, where one could expect an incoming call
every 5th minute, this would result in a clock skew on the order of
16.5 hours (approx 1000 minutes).
In a more extreme case, where the maximum number of incoming messages Consider a very extreme case, where the maximum number of incoming
are assumed to be on the order of 120 messages per minute, and a messages are assumed to be on the order of 120 messages per minute,
requirement that the clock skew is on the order of 10 minutes, a 48kB and a requirement that the clock skew is on the order of 10 minutes,
replay cache would be required. a 48kB replay cache would be required.
One recommendation is to fix a size for the replay cache, and let the Hence, one can note that the required clock skew will depend very
allowable clock skew be large. As the replay cache grows, the clock much on the setting in which MIKEY is used. One recommendation is to
skew is decreased depending on how many percent of the replay cache fix a size for the replay cache, and let the allowable clock skew be
that are used. Note that this is locally handled, which will not large (the initial clock skew can be set depending on the application
require interaction with the peer (even though it may indirectly in which it is used). As the replay cache grows, the clock skew is
affect the peer). Exactly how to implement such functionality is decreased depending on how many percent of the replay cache that are
however out of the scope of this document and considered used. Note that this is locally handled, which will not require
implementation specific. interaction with the peer (even though it may indirectly affect the
peer). Exactly how to implement such functionality is however out of
the scope of this document and considered implementation specific.
In case of a DoS attack, the client will in most cases be able to In case of a DoS attack, the client will most likely be able to
handle the replay cache. A bigger problem will probably be to process handle the replay cache. A 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
If MIKEY is sent on an unreliable transport, the basic processing If MIKEY is sent on an unreliable transport, the basic processing
applied to ensure protocol reliability is the following. applied to ensure protocol reliability is the following.
The transmitting entity (Initiator or Responder) MUST: The transmitting entity (Initiator or Responder) MUST:
skipping to change at page 26, line 27 skipping to change at page 29, line 16
* version: the version number of MIKEY. * version: the version number of MIKEY.
version = 1 version = 1
* data type: describes the type of message (e.g. public-key transport * data type: describes the type of message (e.g. public-key transport
message, verification message, error message). message, verification message, error message).
Data type | Value | Comment Data type | Value | Comment
-------------------------------------- --------------------------------------
Pre-shared | 0 | Initiator's pre-shared key message Pre-shared | 0 | Initiator's pre-shared key message
PS ver msg | 1 | Verification message of a Pre-shared PSK ver msg | 1 | Verification message of a Pre-shared
| | key message | | key message
Public key | 2 | Initiator's public-key transport message Public key | 2 | Initiator's public-key transport message
PK ver msg | 3 | Verification message of a public-key PK ver msg | 3 | Verification message of a public-key
| | message | | message
D-H init | 4 | Initiator's DH exchange message D-H init | 4 | Initiator's DH exchange message
D-H resp | 5 | Responder's DH exchange message D-H resp | 5 | Responder's DH exchange message
Error | 6 | Error message Error | 6 | Error message
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. payload.
skipping to change at page 29, line 42 skipping to change at page 32, line 42
! Mac alg ! MAC ~ ! Mac alg ! MAC ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload (see Section 6.1 for defined values). payload (see Section 6.1 for defined values).
* Encr alg: The encryption algorithm used to encrypt the TGK. * Encr alg: The encryption algorithm used to encrypt the TGK.
Encr alg | Value | Comments Encr alg | Value | Comments
------------------------------------------- -------------------------------------------
AES-CM | 1 | Mandatory (as defined in Section 4.2.3) AES-CM-128 | 1 | Mandatory (as defined in Section 4.2.3,
using a 128-bit key)
NULL | 2 | Very restricted usage, see Section 4.2.3! NULL | 2 | Very restricted usage, see Section 4.2.3!
AES-KW-128 | 3 | Optional (AES Key Wrap, see also Section
4.2.3)
* Encr len: Length of encrypted part (in bytes). * Encr len: Length of encrypted part (in bytes).
* Encr data: The encrypted TGK sub-payloads (see Section 6.13). * 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)
skipping to change at page 30, line 41 skipping to change at page 33, line 47
* 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 (if nothing else stated in the * Data: The encrypted envelope key (if nothing else stated in the
certificate, padding and formatting is done according to RSA/PKCS#1 certificate, padding and formatting is done according to RSA/PKCS#1
if RSA is used). if RSA is used).
6.4. DH data payload (DH) 6.4. DH data payload (DH)
The DH data payload carries the DH-value and indicates the DH-group The DH data payload carries the DH-value and indicates the DH-group
used. used. Notice that in this sub-section "MANDATORY" is conditioned upon
DH being supported at all.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! DH-Group ! DH-value ~ ! Next Payload ! DH-Group ! DH-value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Reserv! KV ! KV data (optional) ~ ! Reserv! KV ! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * 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 31, line 35 skipping to change at page 34, line 37
6.5. Signature payload (SIGN) 6.5. Signature payload (SIGN)
The Signature payload carries the signature and its related data. The The Signature payload carries the signature and its related data. The
signature payload is always the last payload in the PK transport and signature payload is always the last payload in the PK transport and
DH exchange messages. The signature algorithm used is implicit from DH exchange messages. The signature algorithm used is implicit from
the certificate/public key used. the certificate/public key used.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature len ! Signature ~ ! S type| Signature len ! Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* S type: Indicates the signature algorithm applied by signer.
S type | Value | Comments
-------------------------------------
RSA/PKCS#1/1.5| 0 | Denotes a PKCS #1 version 1.5 signature
RSA/PSS | 1 | Denotes a PSS signature
* Signature len: The length of the signature field (in bytes). * Signature len: The length of the signature field (in bytes).
* Signature: The signature (if nothing else stated in the * Signature: The signature (if nothing else stated in the
certificate, padding and formatting is done according to RSA/PKCS#1 certificate, padding and formatting is done according to RSA/PKCS#1
if RSA is used). if RSA is used).
6.6. Timestamp payload (T) 6.6. Timestamp payload (T)
The timestamp payload carries the timestamp information. The timestamp payload carries the timestamp information.
skipping to change at page 34, line 38 skipping to change at page 37, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Policy no ! Prot type ! Policy param ~ ! Next payload ! Policy no ! Prot type ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ length (cont) ! Policy param ~ ~ length (cont) ! Policy param ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload: identifies the payload that is added after this * Next payload: identifies the payload that is added after this
payload. See Section 6.1 for values. payload. See Section 6.1 for values.
* Policy no: Each security policy payload must be given a distinct * Policy no: Each security policy payload must be given a distinct
number. number for the current MIKEY session by the local peer. This number
is used to be able to map a crypto session to a specific policy (see
also Section 6.1.1).
* Prot type: defines the security protocol. * Prot type: defines the security protocol.
Prot type | Value | Prot type | Value |
--------------------------- ---------------------------
SRTP | 0 | SRTP | 0 |
* Policy param length: defines the total length of the policy * Policy param length: defines the total length of the policy
parameters for the specific security protocol. parameters for the specific security protocol.
skipping to change at page 35, line 34 skipping to change at page 38, line 48
---------------------------------------------------- ----------------------------------------------------
0 | Encryption algorithm | see below 0 | Encryption algorithm | see below
1 | Session Encr. key length | depends on cipher used 1 | Session Encr. key length | depends on cipher used
2 | Authentication algorithm | see below 2 | Authentication algorithm | see below
3 | Session Auth. key length | depends on MAC used 3 | Session Auth. key length | depends on MAC used
4 | Session Salt key length | see [SRTP] for recommendations 4 | Session Salt key length | see [SRTP] for recommendations
5 | SRTP Pseudo Random Function | see below 5 | SRTP Pseudo Random Function | see below
6 | Key derivation rate | see [SRTP] for recommendations 6 | Key derivation rate | see [SRTP] for recommendations
7 | SRTP encryption off/on | 0 if off, 1 if on 7 | SRTP encryption off/on | 0 if off, 1 if on
8 | SRTCP encryption off/on | 0 if off, 1 if on 8 | SRTCP encryption off/on | 0 if off, 1 if on
9 | FEC order | see below 9 | senderÆs FEC order | see below
10 | SRTP authentication off/on | 0 if off, 1 if on 10 | SRTP authentication off/on | 0 if off, 1 if on
11 | Authentication tag length | in bytes 11 | Authentication tag length | in bytes
12 | SRTP prefix length | in bytes 12 | SRTP prefix length | in bytes
Note that if a Type/Value is not set, the default one is used Note that if a Type/Value is not set, the default one is used
(according to SRTPs own criteria). (according to SRTPs own criteria).
For the Encryption algorithm, it is enough with a one byte length and For the Encryption algorithm, it is enough with a one byte length and
the currently defined possible Values are: the currently defined possible Values are:
SRTP encr alg | Value SRTP encr alg | Value
--------------------- ---------------------
NULL | 0 NULL | 0
AES-CM | 1 AES-CM | 1
AES-F8 | 2 AES-F8 | 2
where AES-CM is AES in CM and AES-F8 is AES in f8 mode. where AES-CM is AES in CM and AES-F8 is AES in f8 mode [SRTP].
For the Authentication algorithm, it is enough with a one byte length For the Authentication algorithm, it is enough with a one byte length
and the currently define possible Values are: and the currently define possible Values are:
SRTP auth alg | Value SRTP auth alg | Value
--------------------- ---------------------
NULL | 0 NULL | 0
HMAC-SHA1 | 1 HMAC-SHA1 | 1
For the SRTP pseudo random function, it is also enough with a one For the SRTP pseudo random function, it is also enough with a one
byte length and the currently define possible Values are: byte length and the currently define possible Values are:
SRTP PRF | Value SRTP PRF | Value
--------------------- ---------------------
AES-CM | 0 AES-CM | 0
If FEC is used at the same time as SRTP is used, MIKEY can negotiate If FEC is used at the same time as SRTP is used, MIKEY can negotiate
the order in which these should be applied. the order in which these should be applied at the sender side.
FEC order | Value | Comments FEC order | Value | Comments
-------------------------------- --------------------------------
FEC-SRTP | 0 | First FEC, then SRTP FEC-SRTP | 0 | First FEC, then SRTP
SRTP-FEC | 1 | First SRTP, then FEC SRTP-FEC | 1 | First SRTP, then FEC
SPLIT | 2 | SRTP encr., then FEC, finally SRTP auth
6.11. RAND payload (RAND) 6.11. RAND payload (RAND)
The RAND payload consist of a random bit-string. The RAND MUST be The RAND payload consist of a (pseudo)random bit-string. The RAND
chosen at random and per CSB (note that the if a CSB has several MUST be independently generated per CSB (note that the if a CSB has
members, the Initiator MUST use the same RAND to all the members). several 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 (pseudo)randomly chosen bit-string.
6.12. Error payload (ERR) 6.12. Error payload (ERR)
The Error payload is used to specify the error(s) that may have The Error payload is used to specify the error(s) that may have
occurred. occurred.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Error no ! Reserved ! ! Next Payload ! Error no ! Reserved !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 38, line 4 skipping to change at page 41, line 18
that generally TEKs are not sent directly, but a TGK, which is then that generally TEKs are not sent directly, but a TGK, which is then
used to derive the TEK (or TEKs if there are several crypto sessions) used to derive the TEK (or TEKs if there are several crypto sessions)
as described in Section 4.1.4. as described in Section 4.1.4.
Type | Value | Comments Type | Value | Comments
--------------------------------------- ---------------------------------------
TGK | 0 | A TGK (used to derive TEKs from) TGK | 0 | A TGK (used to derive TEKs from)
TGK+SALT | 1 | A TGK + a salt key are included TGK+SALT | 1 | A TGK + a salt key are included
TEK | 2 | A plain TEK TEK | 2 | A plain TEK
TEK+SALT | 3 | A plain TEK + a salt key are included TEK+SALT | 3 | A plain TEK + a salt key are included
Note that the possibility to include a TEK (instead of using the TGK) Note that the possibility to include a TEK (instead of using the TGK)
is provided. However, if this is used, the TEK can generally not be is provided. However, if this is used, the TEK can generally not be
shared between more than one Crypto Session. The recommended use of a shared between more than one Crypto Session. The recommended use of a
TEK instead of a TGK is when pre-encrypted material exists and TEK instead of a TGK is when pre-encrypted material exists and
therefore, the TEK must be known in advance. 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/MKI or by providing an interval in which the be done by using an SPI (or MKI in the case of [SRTP]) or by
key is valid (e.g., in the latter case, for SRTP this will be the providing an interval in which the key is valid (e.g., in the latter
index range where the key is valid). case, for SRTP this will be the index range where the key is valid).
KV | Value | Comments KV | Value | Comments
------------------------------------------- -------------------------------------------
Null | 0 | No specific usage rule (e.g. a TEK Null | 0 | No specific usage rule (e.g. a TEK
| | that has no specific lifetime) | | that has no specific lifetime)
SPI | 1 | The key is associated with the SPI/MKI SPI | 1 | The key is associated with the SPI/MKI
Interval | 2 | The key has a start and expiration time Interval | 2 | The key has a start and expiration time
| | (e.g. an SRTP TEK) | | (e.g. an SRTP TEK)
Note that when NULL is specified, any SPI or Interval is valid. For Note that when NULL is specified, any SPI or Interval is valid. For
an Interval this means that the key is valid from the first observed an Interval this means that the key is valid from the first observed
sequence number until the key is replaced (or the security protocol sequence number until the key is replaced (or the security protocol
is shutdown). is shutdown).
* Key data len: The length of the Key data field (in bytes). * Key data len: The length of the Key data field (in bytes). Note
that the sum of the overall length of all the Key data sub-payloads
contained in a single Key data transport payload (KEMAC) MUST be such
that the KEMAC payload does not exceed a length of 2^16 bytes (total
length of KEMAC, see Section 6.2).
* Key data: The TGK or TEK data. * Key data: The TGK or TEK 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.)
skipping to change at page 43, line 30 skipping to change at page 46, line 39
for the SIP or RTSP implementation to request a new message from 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 MIKEY, e.g. when a new offer is issued. MIKEY SHOULD then send an
update message to the Responder (see also Section 4.5). update message to the Responder (see also Section 4.5).
8. Groups 8. Groups
What has been discussed up to now is not limited to single peer-to- What has been discussed up to now is not limited to single peer-to-
peer communication (except for the DH method), but can be used to peer communication (except for the DH method), but can be used to
distribute group keys for small-size interactive groups and simple distribute group keys for small-size interactive groups and simple
one-to-many scenarios. This section describes how MIKEY is used in a one-to-many scenarios. This section describes how MIKEY is used in a
group scenario. group scenario (though, see also Section 4.3 for issues related to
authorization).
8.1. Simple one-to-many 8.1. Simple one-to-many
++++ ++++
|S | |S |
| | | |
++++ ++++
| |
--------+-------------- - - --------+-------------- - -
| | | | | |
skipping to change at page 44, line 44 skipping to change at page 48, line 15
outgoing stream(s) to the others. outgoing stream(s) to the others.
As for the simple one-to-many case, the streaming client specifies 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 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. TGK/TEK(s) is used for all the group members.
9. Security Considerations 9. Security Considerations
9.1. General 9.1. General
No chain is stronger than its weakest link. The cryptographic Key management protocols based on timestamps/counters and one-
functions protecting the keys during transport/exchange SHOULD offer roundtrip key transport have previously been standardized in e.g.,
a security at least corresponding to the (symmetric) keys they ISO [ISO1, ISO2]. The general security of these types of protocols
protect. For instance, with current state of the art, see [LV], can be found in various literature and articles, c.f. [HAC, AKE,
protecting a 128-bit AES key by a 512-bit RSA [RSA] key offers an LOA].
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 No chain is stronger than its weakest link. If a given level of
facilitated, again lowering the effective key size. Therefore, care protection is wanted, then the cryptographic functions protecting the
MUST be taken when designing the (pseudo) random generators for TGK keys during transport/exchange MUST offer a security at least
generation, see [FIPS][RAND]. corresponding to that level.
For instance, if a security against attacks with complexity 2^96 is
wanted, then one should choose a secure symmetric cipher supporting
at least 96 bit keys (128 bits may be a practical choice) for the
actual media protection, and a key transport mechanism that provides
equivalent protection, e.g. MIKEY's pre-shared key transport with 128
bit TGK, or, RSA with 1024 bit keys (which according to [LV]
corresponds to the desired 96 bit level, with some margin).
In summary, key size for the key-exchange mechanism MUST be weighed
against the size of the exchanged TGK so that it offers at least the
required level. For efficiency reasons, one SHOULD also avoid a
security overkill, e.g. by not using a public key transport with
public keys giving a security level that is orders of magnitude
higher than length of the transported TGK. We refer to [LV] for
concrete key size recommendations.
Moreover, if the TGKs are not random (or pseudorandom), 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, see [FIPS][RAND].
For the selection of the hash function, SHA-1 with 160-bit output is For the selection of the hash function, SHA-1 with 160-bit output is
the default one. In general, hash sizes should be twice the "security the default one. In general, hash sizes should be twice the "security
level", indicating that SHA1-256, [SHA256], should be used for the level", indicating that SHA1-256, [SHA256], should be used for the
default 128-bit level. However, due to the real-time aspects in the default 128-bit level. However, due to the real-time aspects in the
scenarios we are treating, hash size slightly below 256 are scenarios we are treating, hash size slightly below 256 are
acceptable as the normal "existential" collision probabilities would acceptable as the normal "existential" collision probabilities would
be of secondary importance. In general, all pre-defined MIKEY be of secondary importance.
transforms are state-of-the-art with no known weaknesses.
In a Crypto Session Bundle, the Crypto Sessions can share the same In a Crypto Session Bundle, the Crypto Sessions can share the same
TGK as discussed earlier. From a security point of view, the TGK as discussed earlier. From a security point of view, the
criterion to be satisfied is that the encryption of the individual criterion to be satisfied is that the encryption of the individual
Crypto Sessions are performed "independently". In MIKEY this is Crypto Sessions are performed "independently". In MIKEY this is
accomplished by having unique Crypto Session identifiers (see also accomplished by having unique Crypto Session identifiers (see also
Section 4.1) and a TEK derivation method that provides Section 4.1) and a TEK derivation method that provides
cryptographically independent TEKs to distinct Crypto Sessions cryptographically independent TEKs to distinct Crypto Sessions
(within the Crypto Session Bundle), regardless of the security (within the Crypto Session Bundle), regardless of the security
protocol used. protocol used.
Specifically, the key derivations are implemented by a pseudo-random Specifically, the key derivations, as specified in Section 4.1, are
function. The one used here is a simplified version of that used in implemented by a pseudo-random function. The one used here is a
TLS [TLS]. Here, only one single hash function is used, whereas TLS simplified version of that used in TLS [TLS]. Here, only one single
uses two different functions. This choice is motivated by the high hash function is used, whereas TLS uses two different functions. This
confidence in the SHA-1 hash function, and, by efficiency and choice is motivated by the high confidence in the SHA-1 hash
simplicity of design (complexity does not imply security). Indeed, as function, and, by efficiency and simplicity of design (complexity
shown in [DBJ], if one of the two hashes is severely broken, the TLS does not imply security). Indeed, as shown in [DBJ], if one of the
PRF is actually less secure than if a single hash had been used on two hashes is severely broken, the TLS PRF is actually less secure
the whole key, as is done in MIKEY. than if a single hash had been used on the whole key, as is done in
MIKEY.
In the pre-shared key and public-key schemes, the TGK is generated by In the pre-shared key and public-key schemes, the TGK is generated by
a single party (Initiator). This makes MIKEY somewhat more sensitive a single party (Initiator). This makes MIKEY somewhat more sensitive
if the Initiator uses a bad random number generator. It should also if the Initiator uses a bad random number generator. It should also
be noted that neither the pre-shared nor the public-key scheme be noted that neither the pre-shared nor the public-key scheme
provides perfect forward secrecy. If mutual contribution or perfect provides perfect forward secrecy. If mutual contribution or perfect
forward secrecy is desired, the Diffie-Hellman method is to be used. forward secrecy is desired, the Diffie-Hellman method is to be used.
Forward/backward security: if the TGK is exposed, all TEKs generated Forward/backward security: if the TGK is exposed, all TEKs generated
from it are compromised. However, under the assumption that the from it are compromised. However, under the assumption that the
derivation function is a pseudo-random function, disclosure of an derivation function is a pseudo-random function, disclosure of an
individual TEK does not compromise other (previous or later) TEKs individual TEK does not compromise other (previous or later) TEKs
derived from the same TGK. derived from the same TGK. The Diffie-Hellman mode can be considered
by cautious users as it is the only one that supports so called
perfect forward secrecy (PFS). This is in contrast to a compromise of
the pre-shared key (or the secret key of the public key mode), where
future sessions and recorded session from the past are then also
compromised.
The use of random nonces (RANDs) in the key derivation is of utmost The use of random nonces (RANDs) in the key derivation is of utmost
importance to counter off-line pre-computation attacks. Note however importance to counter off-line pre-computation attacks. Note however
that update messages re-use the old RAND. This means that the total that update messages re-use the old RAND. This means that the total
effective key entropy (relative to pre-computation attacks) for k effective key entropy (relative to pre-computation attacks) for k
consecutive key updates, assuming the TGKs and RAND are each n bits consecutive key updates, assuming the TGKs and RAND are each n bits
long, is about L = n*(k+1)/2 bits, compared to the theoretical long, is about L = n*(k+1)/2 bits, compared to the theoretical
maximum of n*k bits. In other words, a 2^L work effort MAY enable an maximum of n*k bits. In other words, a 2^L work effort MAY enable an
attacker to get all k keys. While this might seem as a defect, first attacker to get all k n-bit keys, which is better than brute force
note that for proper choice of n, the 2^L complexity of the attack is (except when k = 1). While this might seem as a defect, first note
way out of reach. Moreover, the fact that more than one key can be that for proper choice of n, the 2^L complexity of the attack is way
out of reach. Moreover, the fact that more than one key can be
compromised in a single attack is inherent to the key exchange compromised in a single attack is inherent to the key exchange
problematic. Consider for instance a user who, using say a fixed problematic. Consider for instance a user who, using say a fixed
1024-bit RSA key, exchanges keys and communicates during one or two 1024-bit RSA key, exchanges keys and communicates during one or two
years life-time of the public key. Breaking this single RSA key will years life-time of the public key. Breaking this single RSA key will
enable access to all exchanged keys and consequently the entire enable access to all exchanged keys and consequently the entire
communication of that user over the whole period. communication of that user over the whole period.
All the pre-defined transforms in MIKEY use state-of-the-art All the pre-defined transforms in MIKEY use state-of-the-art
algorithms that has undergone large amounts of public evaluation. algorithms that has undergone large amounts of public evaluation. One
of the reasons to use AES-CM from SRTP [SRTP] is to have the
possibility to limit the overall number of different encryption modes
and algorithms, at the same time that it offers a high level of
security.
9.2. Key lifetime 9.2. Key lifetime
Even if the lifetime of a TGK (or TEK) is not specified, it MUST be Even if the lifetime of a TGK (or TEK) is not specified, it MUST be
taken into account that the encryption transform in the underlying taken into account that the encryption transform in the underlying
security protocol can in some way degenerate after a certain amount security protocol can in some way degenerate after a certain amount
of encrypted data. It is not possible to here state general key life- of encrypted data. It is not possible to here state general key life-
time bounds, universally applicable; each security protocol should time bounds, universally applicable; each security protocol should
define such maximum amount and trigger a re-keying procedure before define such maximum amount and trigger a re-keying procedure before
the "exhaustion" of the key. E.g., according to SRTP [SRTP] the TEK 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 MUST be changed at least every 2^48 SRTP packet (i.e. every time the
ROC + SEQ no in SRTP wraps). ROC || SEQ no in SRTP wraps).
Still, the following can be said as a rule of thumb. If the security Still, the following can be said as a rule of thumb. If the security
protocol uses an "ideal" b-bit block cipher (in CBC mode, counter protocol uses an "ideal" b-bit block cipher (in CBC mode, counter
mode, or a feedback mode with full b-bit feedback), degenerate mode, or a feedback mode, e.g OFB, with full b-bit feedback),
behavior in the crypto stream, possibly useful for an attacker, is degenerate behavior in the crypto stream, possibly useful for an
(with constant probability) expected to occur after a total of attacker, is (with constant probability) expected to occur after a
roughly 2^(b/2) encrypted b-bit blocks (using random IVs). For total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs).
security margin, re-keying MUST be triggered well in advance compared For security margin, re-keying MUST be triggered well in advance
to the above bound. See [BDJR] for more details. compared to the above bound. See [BDJR] for more details.
For use of a dedicated stream cipher, we refer to the analysis and For use of a dedicated stream cipher, we refer to the analysis and
documentation of said cipher in each specific case. documentation of said cipher in each specific case.
9.3. Timestamps 9.3. Timestamps
The use of timestamps instead of challenge-response requires the The use of timestamps instead of challenge-response requires the
systems to have synchronized clocks. Of course, if two clients are systems to have synchronized clocks. Of course, if two clients are
not synchronized, they will have difficulties with setting up the not synchronized, they will have difficulties with setting up the
security. The current timestamp based solution has been selected to security. The current timestamp based solution has been selected to
allow a maximum of one roundtrip (i.e., two messages), but still allow a maximum of one roundtrip (i.e., two messages), but still
provide a reasonable replay protection. A (secure) challenge-response provide a reasonable replay protection. A (secure) challenge-response
based version would require at least three messages. For a detailed based version would require at least three messages. For a detailed
description of the timestamp and replay handling in MIKEY, see description of the timestamp and replay handling in MIKEY, see
Section 5.4. Section 5.4.
skipping to change at page 50, line 35 skipping to change at page 54, line 22
designed to fulfill such requirements and optimized so that it also designed to fulfill such requirements and optimized so that it also
may be integrated in other protocols such as SIP and RTSP. may be integrated in other protocols such as SIP and RTSP.
MIKEY is designed to be used in scenarios for peer-to-peer MIKEY is designed to be used in scenarios for peer-to-peer
communication, simple one-to-many, and for small-size interactive communication, simple one-to-many, and for small-size interactive
groups without a centralized group server. groups without a centralized group server.
12. Acknowledgments 12. Acknowledgments
The authors would like to thank Mark Baugher, Ran Canetti, Martin The authors would like to thank Mark Baugher, Ran Canetti, Martin
Euchner, the rest of the MSEC WG, Pasi Ahonen (with his group), Rolf Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with
Blom, and Magnus Westerlund, for their valuable feedback. his group), Rolf Blom, and Magnus Westerlund, for their valuable
feedback.
13. Author's Addresses 13. Author's Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
02420 Jorvas Phone: +358 40 5079256 02420 Jorvas Phone: +358 40 5079256
Finland Email: jari.arkko@ericsson.com Finland Email: jari.arkko@ericsson.com
Elisabetta Carrara Elisabetta Carrara
Ericsson Research Ericsson Research
skipping to change at page 52, line 16 skipping to change at page 55, line 51
Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol", Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol",
Internet Draft, IETF, Work in Progress (AVT WG). Internet Draft, IETF, Work in Progress (AVT WG).
[URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource [URI] Berners-Lee. T., Fielding, R., Masinter, L., "Uniform Resource
Identifiers (URI): Generic Syntax", IETF, RFC 2396. Identifiers (URI): Generic Syntax", IETF, RFC 2396.
[X.509] Housley, R., Polk, W., Ford, W., and Solo, D., "Internet [X.509] Housley, R., Polk, W., Ford, W., and Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and Certificate X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", IETF, RFC 3280. Revocation List (CRL) Profile", IETF, RFC 3280.
[AESKW] Schaad, J., Housley R., "Advanced Encryption Standard (AES)
Key Wrap Algorithm", IETF, RFC 3394.
14.2. Informative References 14.2. Informative References
[AKE] Canetti, R. and Krawczyk, H., "Analysis of Key-Exchange
Protocols and their use for Building Secure Channels", Eurocrypt
2001, LNCS 2054, pp. 453-474, 2001.
[BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P., "A [BDJR] Bellare, M., Desai, A., Jokipii, E., and Rogaway, P., "A
Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes Concrete Analysis of Symmetric Encryption: Analysis of the DES Modes
of Operation", in Proceedings of the 38th Symposium on Foundations of of Operation", in Proceedings of the 38th Symposium on Foundations of
Computer Science, IEEE, 1997, pp. 394-403. Computer Science, IEEE, 1997, pp. 394-403.
[BMGL] Hastad, J. and Naslund, M.: "Practical Construction and [BMGL] Hastad, J. and Naslund, M.: "Practical Construction and
Analysis of Pseduo-randomness Primitives", Proceedings of Analysis of Pseduo-randomness Primitives", Proceedings of
AsiacryptÆ01, Lecture Notes in Computer Science vol 2248, pp. 442- AsiacryptÆ01, Lecture Notes in Computer Science vol 2248, pp. 442-
459. 459.
skipping to change at page 52, line 47 skipping to change at page 56, line 40
(MSEC WG). (MSEC WG).
[GDOI] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group [GDOI] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group
Domain of Interpretation", Internet Draft, Work in Progress (MSEC Domain of Interpretation", Internet Draft, Work in Progress (MSEC
WG). WG).
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, [GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer,
R., "Group Secure Association Key Management Protocol", Internet R., "Group Secure Association Key Management Protocol", Internet
Draft, Work in Progress (MSEC WG). Draft, Work in Progress (MSEC WG).
[HAC] Menezes, A., van Oorschot, P., and Vanstone, S., "Handbook of
Applied Cryptography", CRC press, 1996.
[IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[ISO1] ISO/IEC 9798-3: 1997, Information technology - Security
techniques - Entity authentication - Part 3: Mechanisms using digital
signature techniques.
[ISO2] ISO/IEC 11770-3: 1997, Information technology - Security
techniques - Key management - Part 3: Mechanisms using digital
signature techniques.
[LOA] Burrows, Abadi, and Needham, ôA logic of authenticationö, ACM
Transactions on Computer Systems 8 No.1 (Feb. 1990), 18-36.
[LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for [LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for
Cryptosystems", http://www.cryptosavvy.com/suggestions.htm Cryptosystems", http://www.cryptosavvy.com/suggestions.htm
[NTP] Mills, D., "Network Time Protocol (Version 3) specification, [NTP] Mills, D., "Network Time Protocol (Version 3) specification,
implementation and analysis", RFC 1305, March 1992. implementation and analysis", RFC 1305, March 1992.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams
C., "X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", IETF, RFC 2560.
[PKCS1] PKCS #1 - RSA Cryptography Standard, [PKCS1] PKCS #1 - RSA Cryptography Standard,
http://www.rsalabs.com/pkcs/pkcs-1/ http://www.rsalabs.com/pkcs/pkcs-1/
[RAND] Eastlake, D., Schiller, J., and Crocker, S., "Randomness [RAND] Eastlake, D., Schiller, J., and Crocker, S., "Randomness
Requirements for Security", Internet Draft, Work in Progress. Requirements for Security", Internet Draft, Work in Progress.
[RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining [RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining
Digital Signatures and Public-Key Cryptosystems". Communications of Digital Signatures and Public-Key Cryptosystems". Communications of
the ACM. Vol.21. No.2. pp.120-126. 1978. the ACM. Vol.21. No.2. pp.120-126. 1978.
skipping to change at page 53, line 38 skipping to change at page 58, line 5
MIKEY | SRTP MIKEY | SRTP
------------------------------------------------- -------------------------------------------------
Crypto Session | SRTP stream Crypto Session | SRTP stream
Data SA | input to SRTP's crypto context Data SA | input to SRTP's crypto context
TEK | SRTP master key TEK | SRTP master key
The Data SA is built up by a TEK and the security policy exchanged. The Data SA is built up by a TEK and the security policy exchanged.
SRTP may use a MKI to index the TEK. The TEK is then derived from the SRTP may use a MKI to index the TEK. The TEK is then derived from the
TGK that have the corresponding MKI. TGK that have the corresponding MKI.
This Internet-Draft expires in August 2003. Revision History since -06 draft
This section summarizes the most important changes in the document
since the last version.
- Section 2.5. "Existing Solutions" moved to Section 1.1.
- Clarifications of scenarios (Section 2.1).
- Number of clarifications in section 3.
- Certificate discussions in Section 3.2 moved to new Section 4.3.1.
- How to use AES Key wrap added to Section 4.2.3.
- How to add a new DH group added to section 4.2.9.
- New section about Certificate handling, policies and authorization
added (replaces the old Section 4.3).
- Examples in section 5.4 updated.
- AES Key Wrap added as an optional mode in Section 6.2.
- Signature type field added in signature payload (Section 6.5).
- More rational added to the security considerations (Section 9).
This Internet-Draft expires in December 2003.
 End of changes. 

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