draft-ietf-msec-mikey-04.txt   draft-ietf-msec-mikey-05.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: March 2003 M. Naslund Expires: April 2003 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
October 29, 2002
September, 2002
MIKEY: Multimedia Internet KEYing MIKEY: Multimedia Internet KEYing
<draft-ietf-msec-mikey-04.txt> <draft-ietf-msec-mikey-05.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 3, line 39 skipping to change at page 3, line 38
9.4. Identity protection...........................................47 9.4. Identity protection...........................................47
9.5. Denial of Service.............................................47 9.5. Denial of Service.............................................47
9.6. Session establishment.........................................47 9.6. Session establishment.........................................47
10. IANA considerations............................................48 10. IANA considerations............................................48
11. Conclusions....................................................49 11. Conclusions....................................................49
12. Acknowledgments................................................50 12. Acknowledgments................................................50
13. Author's Addresses.............................................50 13. Author's Addresses.............................................50
14. References.....................................................50 14. References.....................................................50
14.1. Normative References.........................................50 14.1. Normative References.........................................50
14.2. Informative References.......................................51 14.2. Informative References.......................................51
Appendix A. - MIKEY - SRTP relation................................53 Appendix A. - MIKEY - SRTP relation................................52
Revision history...................................................53
1. Introduction 1. Introduction
There has recently been work to define a security protocol for the There has recently been work to define a security protocol for the
protection of real-time applications running over RTP, [SRTP]. protection of real-time applications running over RTP, [SRTP].
However, a security protocol needs a key management solution to However, a security protocol needs a key management solution to
exchange keys, security parameters, etc. There are some fundamental exchange keys, security parameters, etc. There are some fundamental
properties that such a key management scheme has to fulfil with properties that such a key management scheme has to fulfill with
respect to the kind of real-time applications (streaming, unicast, respect to the kind of real-time applications (streaming, unicast,
groups, multicast, etc.) and to the heterogeneous nature of the groups, multicast, etc.) and to the heterogeneous nature of the
scenarios dealt with. scenarios dealt with.
This document describes a key management solution, that address 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. 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.
skipping to change at page 6, line 44 skipping to change at page 6, line 42
++++ ++++ ++++ ++++
Figure 2.1: Examples of the four scenarios: peer-to-peer, simple one- Figure 2.1: Examples of the four scenarios: peer-to-peer, simple one-
to-many, many-to-many without centralized server (also denoted as to-many, many-to-many without centralized server (also denoted as
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 parties where it may be desirable that the security is either set up
up by mutual agreement or that each party sets up the security by mutual agreement or that each party sets up the security for its
for its own outgoing streams. own outgoing streams.
b) many-to-many, without a centralized control unit, e.g. for small- b) many-to-many, without a centralized control unit, e.g. for small-
size interactive groups where each party may set up the security size interactive groups where each party may set up the security for
for its own outgoing media. its own outgoing media.
c) many-to-many, with a centralized control unit, e.g. for larger c) many-to-many, with a centralized control unit, e.g. for larger
groups with some kind of Group Controller that sets up the groups with some kind of Group Controller that sets up the security.
security.
d) simple one-to-many (multicast), e.g. real-time presentations, d) simple one-to-many (multicast), e.g. real-time presentations,
where the sender is in charge of setting up the security. where the sender is in charge of setting up the security.
The key management solutions may be different in the above scenarios. The key management solutions may be different in the above scenarios.
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 d.
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
skipping to change at page 7, line 44 skipping to change at page 7, line 40
* 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 used as
the input to the security protocol. the input to the security protocol.
MIKEY supports the possibility to negotiate keys and parameters for MIKEY supports the possibility to negotiate keys and parameters for
more than one security protocol at the same time. Therefore, the more than one security protocol at the same time. The concept of
concept of Crypto Session Bundle (CSB) is used, which is a collection Crypto Session Bundle (CSB) is used to denote a collection of one or
of one or more Crypto Sessions that can have common TEK Generation more Crypto Sessions that can have common TEK Generation Keys and
Keys and security parameters. security parameters.
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 agreed upon for the Crypto Session Bundle (this is done by one of the
the three alternative key transport/exchange mechanisms, see three alternative key transport/exchange mechanisms, see Section 3).
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 |
skipping to change at page 10, line 21 skipping to change at page 10, line 19
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 bit-string, which is always included in the first
message from the Initiator. It is not included in update message from the Initiator. It is not included in update messages of
messages of a CSB. See Section 6.11 for payload definition. 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 12, line 43 skipping to change at page 12, line 41
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 Certificate handling may involve a number of additional tasks not
shown here, and effect the inclusion of certain parts of the message. shown here, and effect the inclusion of certain parts of the message.
The following observations can, however, be made: The following observations can, however, be made:
* the Initiator typically has to find the certificate of the * the Initiator typically has to find the certificate of the
Responder in order to send the first message. If the Initiator Responder in order to send the first message. If the Initiator does
does not have the Responder's certificate already, this may not have the Responder's certificate already, this may involve one or
involve one or more roundtrips to a central directory agent. more roundtrips to a central directory agent.
* it will be possible for the Initiator to omit its own certificate * it will be possible for the Initiator to omit its own certificate
and rely on the Responder getting this certificate using other and rely on the Responder getting this certificate using other means.
means. However, we recommend doing this, only when it is However, we recommend doing this, only when it is reasonable to
reasonable to expect that the Responder has cached the certificate expect that the Responder has cached the certificate from a previous
from a previous connection. Otherwise accessing the certificate connection. Otherwise accessing the certificate would mean additional
would mean additional roundtrips for the Responder as well. roundtrips for the Responder as well.
* verification of the certificates using Certificate Revocation Lists * verification of the certificates using Certificate Revocation Lists
(CRLs) or an on-line verification protocol may mean additional (CRLs) or an on-line verification protocol may mean additional
roundtrips for both parties. If a small number of roundtrips is roundtrips for both parties. If a small number of roundtrips is
required for acceptable performance, it may be necessary to omit required for acceptable performance, it may be necessary to omit some
some of these checks. 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, group, (G,*), for g in G and a natural
number x, we let g^x denote g*g*..*g (x times). Choices for the number x, we let g^x denote g*g*..*g (x times). Choices for the
parameters are given in Section 4.2.7. The other transforms below are parameters are given in Section 4.2.7. The other transforms below are
described in Section 4.2. described in Section 4.2.
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.
skipping to change at page 13, line 50 skipping to change at page 13, line 46
xr is randomly and secretly chosen). xr is randomly 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.
The group parameters (e.g., the group G) are a set of parameters The group parameters (e.g., the group G) are a set of parameters
chosen by the Initiator. Both parties calculate the TGK, g^(xi*xr) chosen by the Initiator. Both parties calculate the TGK, g^(xi*xr)
from the exchanged DH-values. from the exchanged DH-values.
Note that this approach does not require that the Initiator has to Note that this approach does not require that the Initiator has to
posses any of the responder's certificate before the setup. Instead, posses any of the responder's 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 4. Key Management
4.1. Key Calculation 4.1. Key Calculation
We define in the following a general method (pseudo random function) We define in the following a general method (pseudo random function)
to derive one or more keys from a "master" key. This method is used to derive one or more keys from a "master" key. This method is used
to derive: to derive:
skipping to change at page 18, line 24 skipping to change at page 18, line 24
New transforms and parameters SHALL be added by registering a new New transforms and parameters SHALL be added by registering a new
number for the payload, and also if necessary, document how the new number for the payload, and also if necessary, document how the new
transform/parameter is used. Sometimes it might be enough to point to transform/parameter is used. Sometimes it might be enough to point to
an already specified document for the usage, e.g., when adding a new an already specified document for the usage, e.g., when adding a new
already standardized hash function. already standardized hash function.
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 a crypto session to the right instance of the data security protocol
protocol and possibly also to provide individual parameters for and possibly also to provide individual parameters for each data
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. 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). Whether with an Interval (e.g. a sequence number interval for SRTP),
an SPI or an Interval should be used, depends on the security depending on the security protocol.
protocol.
New parameters can be added to a policy by documenting how they New parameters can be added to a policy by documenting how they
should be interpreted by MIKEY and also by registering new values in should be interpreted by MIKEY and also by registering new values in
the appropriate name space. If a completely new policy is needed, see the appropriate name space. If a completely new policy is needed, see
Section 4.2.9 for guidelines. Section 4.2.9 for guidelines.
4.4. Retrieving the Data SA 4.4. Retrieving the Data SA
The retrieval of a Data SA will depend on the security protocol as The retrieval of a Data SA will depend on the security protocol as
different security protocols will have different characteristics. different security protocols will have different characteristics.
skipping to change at page 22, line 42 skipping to change at page 22, line 42
* Create an initial MIKEY message starting with the Common header * Create an initial MIKEY message starting with the Common header
payload. payload.
* Concatenate necessary payloads to the MIKEY message (see the * Concatenate necessary payloads to the MIKEY message (see the
exchange definitions for payloads that may be included and exchange definitions for payloads that may be included and
recommended order). recommended order).
* As a last step (for messages that must be authenticated, this also * As a last step (for messages that must be authenticated, this also
include the verification message), create and concatenate the include the verification message), create and concatenate the
MAC/signature payload without the MAC/signature field filled in MAC/signature payload without the MAC/signature field filled in (if a
(if a Next payload field is included in this payload, it is set to Next payload field is included in this payload, it is set to Last
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 the MAC/Signature field, and add put the MAC/signature in the field.
field. In the case of the verification message, the IDi || IDr || In the case of the verification message, the IDi || IDr || T MUST
T MUST follow directly after the MIKEY message in the MAC follow directly after the MIKEY message in the MAC calculation.
calculation.
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.
5.3. Parsing a message 5.3. Parsing a message
In general, parsing of a MIKEY message is done by extracting payload In general, parsing of a MIKEY message is done by extracting payload
by payload and checking that no errors occur (the exact procedure is by payload and checking that no errors occur (the exact procedure is
implementation specific). However, for the Responder, it is implementation specific). However, for the Responder, it is
RECOMMENDED that the following procedure is followed: RECOMMENDED that the following procedure is followed:
* Extract the Timestamp and check that it is within the allowable * Extract the Timestamp and check that it is within the allowable
clock skew (if not, discard the message). Also check the replay clock skew (if not, discard the message). Also check the replay cache
cache so that the message is not replayed (see also Section 5.4). so that the message is not replayed (see also Section 5.4). If the
If the message is replayed, discard it. message is replayed, discard it.
* Extract ID and authentication algorithm (if not included, assume * Extract ID and authentication algorithm (if not included, assume
the default one). the default one).
* Verify the MAC/signature. * Verify the MAC/signature.
* If the authentication is not successful, an Auth failure Error * If the authentication is not successful, an Auth failure Error
message is possibly sent to the Initiator (if SIP is used, this is message 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.
Though how it is processed is implementation specific. Though how it is processed is implementation specific.
* If any unsupported parameters or errors occur during the * If any unsupported parameters or errors occur during the
processing, these are reported to the Initiator by sending an processing, these are reported to the Initiator by sending an error
error message. The processing is then aborted. The error message message. The processing is then aborted. The error message can also
can also include payloads to describe the supported parameters. If include payloads to describe the supported parameters. If SIP is
SIP is used, this is signaled to SIP as a rejection of the offer used, this is signaled to SIP as a rejection of the offer (see also
(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 MIKEY does not use a challenge-response mechanism for replay handling
handling, instead timestamps are used. This requires that the clocks instead timestamps are used. This requires that the clocks are
are synchronized. The required synchronization is dependent on the synchronized. The required synchronization is dependent on the number
number of messages that can be cached. If we could assume an of messages that can be cached. If we could assume an unlimited
unlimited cache, the terminals would not need to be synchronized at cache, the terminals would not need to be synchronized at all (as the
all (as the cache could then contain all previously messages). cache could then contain all previous messages). However, if there
are restrictions on the size of the replay cache, the clocks will
However, if there are restrictions on the size of the replay cache, need to be synchronized to some extent. In short, one can in general
the clocks will need to be synchronized to some extent. In short, one say that it is a tradeoff between the size of the replay cache and
can in general say that it is a tradeoff between the size of the the required synchronization.
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 utilize 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 messages presented within an allowable clock skew (which is set by
the local policy). 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 the replay cache or which have an outdated timestamp, are discarded
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
skipping to change at page 27, line 4 skipping to change at page 27, line 4
T | 5 | 6.6 T | 5 | 6.6
ID | 6 | 6.7 ID | 6 | 6.7
CERT | 7 | 6.7 CERT | 7 | 6.7
CHASH | 8 | 6.8 CHASH | 8 | 6.8
V | 9 | 6.9 V | 9 | 6.9
SP | 10 | 6.10 SP | 10 | 6.10
RAND | 11 | 6.11 RAND | 11 | 6.11
ERR | 12 | 6.12 ERR | 12 | 6.12
Key data | 20 | 6.13 Key data | 20 | 6.13
General Ext. | 21 | 6.15 General Ext. | 21 | 6.15
Note that some of the payloads cannot possibly come right after Note that some of the payloads cannot possibly come right after the
the header (such as "Last payload", "Signature", etc.). However, header (such as "Last payload", "Signature", etc.). However, the Next
the Next payload field is generic for all payloads. Therefore, a payload field is generic for all payloads. Therefore, a value is
value is allocated for each payload. allocated for each payload.
* V: flag to indicate whether a verification message is expected or * V: flag to indicate whether a verification message is expected or
not (this has only meaning when it is set by the Initiator). not (this has only meaning when it is set by the Initiator).
V = 0 ==> no response expected V = 0 ==> no response expected
V = 1 ==> response expected V = 1 ==> response expected
* PRF func: Indicates the PRF function that has been/will be used for * PRF func: Indicates the PRF function that has been/will be used for
key derivation etc. key derivation etc.
PRF func | Value | Comments PRF func | Value | Comments
-------------------------------------------------------- --------------------------------------------------------
MIKEY-1 | 0 | Mandatory, Default (see Section 4.1.2-3) MIKEY-1 | 0 | Mandatory, Default (see Section 4.1.2-3)
MIKEY-256 | 1 | (as MIKEY-1 but using a HMAC with SHA256) MIKEY-256 | 1 | (as MIKEY-1 but using a HMAC with SHA256)
MIKEY-384 | 2 | (as MIKEY-1 but using a HMAC with SHA384) MIKEY-384 | 2 | (as MIKEY-1 but using a HMAC with SHA384)
MIKEY-512 | 3 | (as MIKEY-1 but using a HMAC with SHA512) MIKEY-512 | 3 | (as MIKEY-1 but using a HMAC with SHA512)
* CSB ID: A 32-bit integer to identify the CSB. It is RECOMMENDED * CSB ID: A 32-bit integer to identify the CSB. It is RECOMMENDED
that it is chosen at random by the Initiator. This ID MUST be that it is chosen at random by the Initiator. This ID MUST be unique
unique between each Initiator-Responder pair, i.e., not globally between each Initiator-Responder pair, i.e., not globally unique. An
unique. An Initiator MUST check for collisions when choosing the Initiator MUST check for collisions when choosing the ID (if the
ID (if the Initiator already has one or more established CSB with Initiator already has one or more established CSB with the
the Responder). The Responder uses the same CSB ID in the Responder). The Responder uses the same CSB ID in the response.
response.
* #CS: Indicates the number of Crypto Sessions that will be handled. * #CS: Indicates the number of Crypto Sessions that will be handled.
Note that even though it is possible to use 255 CSs, it is not Note that even though it is possible to use 255 CSs, it is not likely
likely that a CSB will include this many CSs. The integer 0 is that a CSB will include this many CSs. The integer 0 is interpreted
interpreted as no CS included. This may be the case in an initial as no CS included. This may be the case in an initial setup message.
setup message.
* CS ID map type: specifies the method to uniquely map Crypto * CS ID map type: specifies the method to uniquely map Crypto
Sessions to the security protocol sessions. Sessions to the security protocol sessions.
CS ID map type | Value CS ID map type | Value
----------------------- -----------------------
SRTP-ID | 0 SRTP-ID | 0
* CS ID map info: Identifies the crypto session(s) that the SA should * CS ID map info: Identifies the crypto session(s) that the SA should
be created for. The currently defined map type is the SRTP-ID be created for. The currently defined map type is the SRTP-ID
(defined in Section 6.1.1). (defined in Section 6.1.1).
6.1.1. SRTP ID 6.1.1. SRTP ID
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy no 1 ! SSRC 1 ~ ! Policy_no_1 ! SSRC_1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SSRC 1 (cont) ! ROC 1 ~ ~ SSRC_1 (cont) ! ROC_1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ROC 1 (cont) ! Policy no 2 ! SSRC 2 ~ ~ ROC_1 (cont) ! Policy_no_2 ! SSRC_2 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SSRC 2 (cont) ! ROC 2 ~ ~ SSRC_2 (cont) ! ROC_2 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ROC 2 (cont) ! ~ ROC_2 (cont) ! :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
: : : : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Policy no #CS ! SSRC #CS ~ ! Policy_no_#CS ! SSRC_#CS ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~SSRC #CS (cont)! ROC #CS ~ ~SSRC_#CS (cont)! ROC_#CS ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ROC #CS (cont)! ~ ROC_#CS (cont)!
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
* Policy no x: The policy applied for the stream with SSRC x. The * Policy_no_i: The policy applied for the stream with SSRC_i. The
same policy may apply for all CSs. same policy may apply for all CSs.
* SSRC x: specifies the SSRC that MUST be used for the SRTP streams. * SSRC_i: specifies the SSRC that MUST be used for the i-th SRTP
Note that it is the sender of the streams who chooses the SSRC. stream. Note that it is the sender of the streams who chooses the
Therefore, it might be that the Initiator of MIKEY can not fill in SSRC. Therefore, it might be that the Initiator of MIKEY can not fill
all fields. In this case, SSRCs that are not chosen by the in all fields. In this case, SSRCs that are not chosen by the
Initiator are set to zero and the Responder fills in these field Initiator are set to zero and the Responder fills in these field in
in the response message. It is in general RECOMMENDED or required the response message. It is in general RECOMMENDED or required to use
to use unique SSRCs (both to avoid RTP SSRC collision, and from an unique SSRCs (both to avoid RTP SSRC collision, and from an SRTP
SRTP perspective, to avoid two-time pad problems if the same TEK perspective, to avoid two-time pad problems if the same TEK is used
is used for more than one stream). for more than one stream).
* ROC x: Current rollover counter used in SRTP. If the SRTP session * ROC_i: Current rollover counter used in SRTP. If the SRTP session
has not started, this field is set to 0. This field is used to be has not started, this field is set to 0. This field is used to be
able for a member to join and synchronize to an already started able for a member to join and synchronize to an already started
stream. stream.
NOTE: The stream using SSRC x will also have Crypto Session ID equal NOTE: The stream using SSRC_i will also have Crypto Session ID equal
to x (NOT to SSRC). to no i (NOT to the SSRC).
6.2. Key data transport payload (KEMAC) 6.2. Key data transport payload (KEMAC)
The Key data transport payload contains encrypted Key data payloads The Key data transport payload contains encrypted Key data payloads
(see Section 6.13 for definition of Key data payloads). It may (see Section 6.13 for definition of Key data payloads). It may
contain one or more Key data payloads each including a TGK. The last contain one or more Key data payloads each including a TGK. The last
Key data payload has its Next payload field set to Last payload. For Key data payload has its Next payload field set to Last payload. For
an update message (see also Section 4.5), it is allowed to skip the an update message (see also Section 4.5), it is allowed to skip the
Key data payloads (which will result in that the Encr data len is Key data payloads (which will result in that the Encr data len is
equal to 0). equal to 0).
skipping to change at page 30, line 35 skipping to change at page 30, line 35
Cache type | Value | Comments Cache type | Value | Comments
-------------------------------------- --------------------------------------
No cache | 0 | The envelope key MUST NOT be cached No cache | 0 | The envelope key MUST NOT be cached
Cache | 1 | The envelope key MUST be cached Cache | 1 | The envelope key MUST be cached
Cache for CSB | 2 | The envelope key MUST be cached, but only Cache for CSB | 2 | The envelope key MUST be cached, but only
| | to be used for the specific CSB. | | to be used for the specific CSB.
* 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 certificate, padding and formatting is done according to RSA/PKCS#1
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.
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 ~
skipping to change at page 31, line 18 skipping to change at page 31, line 18
-------------------------------------- --------------------------------------
OAKLEY 5 | 0 | Mandatory OAKLEY 5 | 0 | Mandatory
OAKLEY 1 | 1 | OAKLEY 1 | 1 |
OAKLEY 2 | 2 | OAKLEY 2 | 2 |
* DH-value: The public DH-value (the length is implicit from the * DH-value: The public DH-value (the length is implicit from the
group used). group used).
* 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 (alternatively an MKI) or by providing an be done by using an SPI (alternatively an MKI) or by providing an
interval in which the key is valid (e.g. in the latter case, for interval in which the key is valid (e.g. in the latter case, for SRTP
SRTP this will be the index range where the key is valid). See this will be the index range where the key is valid). See Section
Section 6.13 for pre-defined values. 6.13 for pre-defined values.
* KV data: This includes either the SPI/MKI or an interval (see * KV data: This includes either the SPI/MKI or an interval (see
Section 6.14). If KV is NULL, this field is not included. Section 6.14). If KV is NULL, this field is not included.
6.5. Signature payload (SIGN) 6.5. Signature payload (SIGN)
The Signature payload carries the signature and its related data. The The Signature payload carries the signature and its related data. The
signature payload is always the last payload in the PK transport and signature payload is always the last payload in the PK transport and
DH exchange messages. The signature algorithm used is implicit from DH exchange messages. The signature algorithm used is implicit from
the certificate/public key used. the certificate/public key used.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature len ! Signature ~ ! Signature len ! Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Signature len: The length of the signature field (in bytes). * Signature len: The length of the signature field (in bytes).
* Signature: The signature (if nothing else stated in the * Signature: The signature (if nothing else stated in the
certificate, padding and formatting is done according to certificate, padding and formatting is done according to RSA/PKCS#1
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.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! TS type ! TS value ~ ! Next Payload ! TS type ! TS value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. If no more payload follows, it MUST be set to Last payload. If no more payload follows, it MUST be set to Last payload.
payload. See Section 6.1 for values. See Section 6.1 for values.
* TS type: specifies the timestamp type used. * TS type: specifies the timestamp type used.
TS type | Value | Comments TS type | Value | Comments
------------------------------------- -------------------------------------
NTP-UTC | 0 | Mandatory (64-bits) NTP-UTC | 0 | Mandatory (64-bits)
NTP | 1 | Mandatory (64-bits) NTP | 1 | Mandatory (64-bits)
COUNTER | 2 | Optional (32-bits)
* TS-value: The timestamp value of the specified TS type. * TS-value: The timestamp value of the specified TS type.
6.7. ID payload (ID) / Certificate payload (CERT) 6.7. ID payload (ID) / Certificate payload (CERT)
Note that the ID payload and the Certificate payload are two Note that the ID payload and the Certificate payload are two
completely different payloads (having different payload identifiers). completely different payloads (having different payload identifiers).
However, as they share the same payload structure they are described However, as they share the same payload structure they are described
in the same section. in the same section.
skipping to change at page 34, line 12 skipping to change at page 34, line 12
the MAC is calculated over the entire MIKEY message as well as the the MAC is calculated over the entire MIKEY message as well as the
IDs and Timestamp (see also Section 5.2). IDs and Timestamp (see also Section 5.2).
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Auth alg ! Ver data ~ ! Next Payload ! Auth alg ! Ver data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. If no more payload follows, it is set to Last payload. payload. If no more payload follows, it is set to Last payload. See
See Section 6.1 for values. Section 6.1 for values.
* Auth alg: specifies the MAC algorithm used for the verification * Auth alg: specifies the MAC algorithm used for the verification
message. See Section 6.2 for defined (MAC field) for defined message. See Section 6.2 for defined (MAC field) for defined values.
values.
* Ver data: The verification message data. Note: the length is * Ver data: The verification message data. Note: the length is
implicit from the authentication algorithm used. implicit from the authentication algorithm used.
6.10. Security Policy payload (SP) 6.10. Security Policy payload (SP)
The Security Policy payload defines a set of policies that applies to The Security Policy payload defines a set of policies that applies to
a specific security protocol. a specific security protocol.
1 2 3 1 2 3
skipping to change at page 37, line 5 skipping to change at page 37, line 5
6.12. Error payload (ERR) 6.12. Error payload (ERR)
The Error payload is used to specify the error(s) that may have The Error payload is used to specify the error(s) that may have
occurred. occurred.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! Error no ! Reserved ! ! Next Payload ! Error no ! Reserved !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. If no more payload follows, it is set to Last payload. payload. If no more payload follows, it is set to Last payload. See
See Section 6.1 for values. Section 6.1 for values.
* Error no indicates the type of error that was encountered. * Error no indicates the type of error that was encountered.
Error no | Value | Comment Error no | Value | Comment
------------------------------------------------------- -------------------------------------------------------
Auth failure | 0 | Authentication failure Auth failure | 0 | Authentication failure
Invalid TS | 1 | Invalid timestamp Invalid TS | 1 | Invalid timestamp
Invalid PRF | 2 | PRF function not supported Invalid PRF | 2 | PRF function not supported
Invalid MAC | 3 | MAC algorithm not supported Invalid MAC | 3 | MAC algorithm not supported
Invalid EA | 4 | Encryption algorithm not supported Invalid EA | 4 | Encryption algorithm not supported
skipping to change at page 37, line 46 skipping to change at page 37, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Salt len (optional) ! Salt data (optional) ~ ! Salt len (optional) ! Salt data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KV data (optional) ~ ! KV data (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload: identifies the payload that is added after this * Next payload: identifies the payload that is added after this
payload. payload.
* Type: Indicates the type of the key included in the payload. Note * Type: Indicates the type of the key included in the payload. Note
that generally TEKs are not sent directly, but a TGK, which is that generally TEKs are not sent directly, but a TGK, which is then
then used to derive the TEK (or TEKs if there are several crypto used to derive the TEK (or TEKs if there are several crypto sessions)
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 is provided. However, if this is used, the TEK can generally not be
TGK is provided). However, if this is used, the TEK can generally shared between more than one Crypto Session. The recommended use of a
not be shared between more than one Crypto Session. The TEK instead of a TGK is when pre-encrypted material exists and
recommended use of a TEK instead of a TGK is when pre-encrypted therefore, the TEK must be known in advance.
material exist and therefore, the TEK must be known in advance.
* KV: Indicates the type of key validity period specified. This may * KV: Indicates the type of key validity period specified. This may
be done by using an SPI/MKI or by providing an interval in which be done by using an SPI/MKI or by providing an interval in which the
the key is valid (e.g., in the latter case, for SRTP this will be key is valid (e.g., in the latter case, for SRTP this will be the
the index range where the key is valid). 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. Note that when NULL is specified, any SPI or Interval is valid. For
For an Interval this means that the key is valid from the first an Interval this means that the key is valid from the first observed
observed sequence number until the key is replaced (or the sequence number until the key is replaced (or the security protocol
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).
* Key data: The TGK 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.)
* KV data: This includes either the SPI or an interval (see Section * KV data: This includes either the SPI or an interval (see Section
6.14). If KV is NULL, this field is not included. 6.14). If KV is NULL, this field is not included.
skipping to change at page 39, line 28 skipping to change at page 39, line 28
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VF Length ! Valid from ~ ! VF Length ! Valid from ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! VT Length ! Valid to (expires) ~ ! VT Length ! Valid to (expires) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* VF Length: Length of the Valid From field in bytes. * VF Length: Length of the Valid From field in bytes.
* Valid From: Sequence number, index, timestamp, or other start value * Valid From: Sequence number, index, timestamp, or other start value
that the security protocol uses to identify the start position of that the security protocol uses to identify the start position of the
the key usage. key usage.
* VT Length: Length of the Valid To field in bytes. * VT Length: Length of the Valid To field in bytes.
* Valid to: Sequence number, index, timestamp, or other expiration * Valid to: Sequence number, index, timestamp, or other expiration
value that the security protocol can use to identify the value that the security protocol can use to identify the expiration
expiration of the key usage. of the key usage.
Note that for SRTP usage, the key validity period for a TGK should be Note that for SRTP usage, the key validity period for a TGK should be
specified with either an interval, where the VF/VT length is equal to specified with either an interval, where the VF/VT length is equal to
6 bytes (i.e., the size of the index), or, with an MKI. It is 6 bytes (i.e., the size of the index), or, with an MKI. It is
RECOMMENDED that if more than one SRTP stream is sharing the same RECOMMENDED that if more than one SRTP stream is sharing the same
keys and key update/re-keying is desired, this is handled using MKI keys and key update/re-keying is desired, this is handled using MKI
rather than the From-To method. rather than the From-To method.
6.15. General Extension Payload 6.15. General Extension Payload
skipping to change at page 40, line 29 skipping to change at page 40, line 29
--------------------------------------- ---------------------------------------
Vendor ID | 0 | Vendor specific byte string Vendor ID | 0 | Vendor specific byte string
* Length: the length in bytes of the Data field. * Length: the length in bytes of the Data field.
* Data: the general payload data. * Data: the general payload data.
7. Integration with session establishment protocols 7. Integration with session establishment protocols
This section describes how MIKEY should be integrated with SDP, SIP This section describes how MIKEY should be integrated with SDP, SIP
and RTSP. It is based on [KMASDP], which describes extensions to SDP and RTSP. It is based on [KMASDP], which describes extensions to
and SIP to carry key management protocol information. SIP/SDP and RTSP to carry key management protocol information.
7.1. SDP integration 7.1. SDP integration
SDP descriptions [SDP] can be carried by several protocols, such as SDP descriptions [SDP] can be carried by several protocols, such as
SIP and RTSP. Both SIP and RTSP often use SDP to describe the media SIP and RTSP. Both SIP and RTSP often use SDP to describe the media
sessions. Therefore, it is also convenient to be able to integrate sessions. Therefore, it is also convenient to be able to integrate
the key management in the session description it is supposed to the key management in the session description it is supposed to
protect. [KMASDP] describes attributes that should be used by a key protect. [KMASDP] describes attributes that should be used by a key
management protocol that is integrated in SDP. We refer to [KMASDP] management protocol that is integrated in SDP. We refer to [KMASDP]
for both definitions and examples. Note that MIKEY uses the name for both definitions and examples. Note that MIKEY uses the name
"mikey" as a protocol name in SDP and RTSP. The key management data "mikey" as a protocol name in SDP and RTSP. The key management data
that is placed in SDP or RTSP MUST be base64 encoded. that is placed in SDP or RTSP MUST be base64 encoded.
7.2. MIKEY within SIP 7.2. MIKEY within SIP
In e.g., a basic SIP call between two parties (see Figure 7.1.), SIP In e.g., a basic SIP call (see Figure 7.1.), SIP (Session Initiation
(Session Initiation Protocol, [SIP]) is used as a session Protocol, [SIP]) is used as a session establishment protocol between
establishment protocol between two or more parties. In general an two or more parties. In general an offer is made, whereby it is
offer is made, whereby it is either accepted or rejected by the either accepted or rejected by the answerer. SIP complies to the
answerer. SIP complies to the offer/answer model [OFFANS], to which offer/answer model [OFFANS], to which MIKEY over SIP MUST be
MIKEY over SIP MUST be compliant with as well. compliant with as well.
--------- --------- --------- ---------
|A's SIP| <.......> |B's SIP| |As SIP| <.......> |Bs SIP|
|Server | SIP/MIKEY |Server | |Server | SIP/MIKEY |Server |
--------- --------- --------- ---------
^ ^ ^ ^
. . . .
++++ SIP/MIKEY . . SIP/MIKEY ++++ ++++ SIP/MIKEY . . SIP/MIKEY ++++
| | <............. ..............> | | | | <............. ..............> | |
| | | | | | | |
++++ <-------------------------------------------> ++++ ++++ <-------------------------------------------> ++++
SRTP SRTP
skipping to change at page 41, line 31 skipping to change at page 41, line 31
be the MIKEY Responder. This implies that in the offer, the MIKEY be the MIKEY Responder. This implies that in the offer, the MIKEY
Initiator's message is included, and in the answer to the offer, the Initiator's message is included, and in the answer to the offer, the
MIKEY Responder's message is included. MIKEY Responder's message is included.
If the MIKEY part of the offer is not accepted, a MIKEY error message If the MIKEY part of the offer is not accepted, a MIKEY error message
is provided in the answer (following Section 5.1.2). The MIKEY is provided in the answer (following Section 5.1.2). The MIKEY
implementation signals to the SIP implementation whether the MIKEY implementation signals to the SIP implementation whether the MIKEY
message was an acceptable offer or not. message was an acceptable offer or not.
It may be assumed that the offerer knows the identity of the It may be assumed that the offerer knows the identity of the
answerer. However, unless the Initiator's identity can be derived answerer. However, unless the Initiators identity can be derived
from SIP itself, the Initiator (caller) MUST provide the identity to from SIP itself, the Initiator (caller) MUST provide the identity to
the callee. It is RECOMMENDED to use the same identity for both SIP the callee. It is RECOMMENDED to use the same identity for both SIP
and MIKEY. and MIKEY.
Updating of the CSB (e.g. TEK update) is only supposed to be seen as Updating of the CSB (e.g. TEK update) is only supposed to be seen as
a new offer. Note that it might not be necessary to send all a new offer. Note that it might not be necessary to send all
information, such as the certificate, due to the already established information, such as the certificate, due to the already established
call (see also Section 4.5). call (see also Section 4.5).
7.3. MIKEY with RTSP 7.3. MIKEY with RTSP
skipping to change at page 42, line 26 skipping to change at page 42, line 26
update previous ones (i.e., it is not required to use the RTSP update previous ones (i.e., it is not required to use the RTSP
KeyMgmt header from server to client). KeyMgmt header from server to client).
7.4. MIKEY Interface 7.4. MIKEY Interface
The SDP, SIP, and RTSP processing is defined in [KMASDP]. However, it The SDP, SIP, and RTSP processing is defined in [KMASDP]. However, it
is necessary that MIKEY can work properly with these protocols. This is necessary that MIKEY can work properly with these protocols. This
subsection describes some aspects which implementers SHOULD consider. subsection describes some aspects which implementers SHOULD consider.
If the MIKEY implementation is separate from the SDP/SIP/RTSP, an If the MIKEY implementation is separate from the SDP/SIP/RTSP, an
application programming interface (API) between MIKEY and these application programming interface (API) between MIKEY and these
protocols is needed with certain functionality (however, exactly protocols is needed with certain functionality (however, exactly what
what it looks like is implementation dependent). it looks like is implementation dependent).
Implementers of MIKEY are RECOMMENDED to consider providing at least Implementers of MIKEY are RECOMMENDED to consider providing at least
the following functionality: the following functionality:
* the possibility for MIKEY to receive information about the sessions * the possibility for MIKEY to receive information about the sessions
negotiated. This is to some extent implementation dependent. But negotiated. This is to some extent implementation dependent. But it
it is RECOMMENDED that, in the case of SRTP streams, the number of is RECOMMENDED that, in the case of SRTP streams, the number of SRTP
SRTP streams are included (and the direction of these). The streams are included (and the direction of these). The destination
destination addresses and ports is also RECOMMENDED to be provided addresses and ports is also RECOMMENDED to be provided to MIKEY.
to MIKEY.
* the possibility for MIKEY to receive incoming MIKEY messages and * the possibility for MIKEY to receive incoming MIKEY messages and
return a status code from/to the SIP/RTSP application. return a status code from/to the SIP/RTSP application.
* the possibility for the SIP or RTSP applications to receive * the possibility for the SIP or RTSP applications to receive
information from MIKEY. This would typically include the receiving information from MIKEY. This would typically include the receiving of
of the CSB ID or the SSRCs for SRTP. It is also RECOMMENDED that the CSB ID or the SSRCs for SRTP. It is also RECOMMENDED that extra
extra information about errors can be received. information about errors can be received.
* the possibility for the SIP or RTSP application to receive outgoing * the possibility for the SIP or RTSP application to receive outgoing
MIKEY messages. MIKEY messages.
* the possibility to tear down a MIKEY CSB (e.g. if the SIP session * the possibility to tear down a MIKEY CSB (e.g. if the SIP session
is closed, the CSB SHOULD also be closed). is closed, the CSB SHOULD also be closed).
Note that if a CSB has already been established, it is still valid Note that if a CSB has already been established, it is still valid
for the SIP or RTSP implementation to request a new message from 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
skipping to change at page 48, line 8 skipping to change at page 48, line 8
Re-direction of streams can of course be done even if it is not a Re-direction of streams can of course be done even if it is not a
group. However, the effect will not be the same compared to a group group. However, the effect will not be the same compared to a group
where impersonation can be done if SOA is not used. Instead, re- where impersonation can be done if SOA is not used. Instead, re-
direction will only deny the receiver the possibility to receive (or direction will only deny the receiver the possibility to receive (or
just delay) the data. just delay) the data.
10. IANA considerations 10. IANA considerations
This document defines several new name spaces associated with the This document defines several new name spaces associated with the
MIKEY payloads. This section summarize the name spaces for which IANA MIKEY payloads. This section summarizes the name spaces for which
is requested to manage the allocation of values. IANA is requested to manage the allocation of values. A new port is
required for MIKEY for stand alone use (the assignment should be for
UDP, TCP, and SCTP).
IANA is requested to record the pre-defined values defined in the IANA is requested to record the pre-defined values defined in the
given sections for each name space. IANA is also requested to manage given sections for each name space. IANA is also requested to manage
the definition of additional values in the future. Unless explicitly the definition of additional values in the future. Unless explicitly
stated otherwise, values in the range 0-240 for each name space stated otherwise, values in the range 0-240 for each name space
should be approved by the process of IETF consensus and values in the should be approved by the process of IETF consensus and values in the
range 241-255 are reserved for Private Use. range 241-255 are reserved for Private Use.
The name spaces for the following fields in the Common header payload The name spaces for the following fields in the Common header payload
(from Section 6.1) are requested to be managed by IANA: (from Section 6.1) are requested to be managed by IANA:
skipping to change at page 51, line 53 skipping to change at page 51, line 53
14.2. Informative References 14.2. Informative References
[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- Asiacrypt01, Lecture Notes in Computer Science vol 2248, pp. 442-
459. 459.
[DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use of [DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use of
MD5", Contribution to ANSI X9F1 WG, 2001. MD5", Contribution to ANSI X9F1 WG, 2001.
[GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F., [GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and Lindholm, F.,
"Group Key Management Architecture", Internet Draft, Work in Progress "Group Key Management Architecture", Internet Draft, Work in Progress
(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
skipping to change at page 53, line 17 skipping to change at page 53, line 4
The terminology in MIKEY differs from the one used in SRTP as MIKEY The terminology in MIKEY differs from the one used in SRTP as MIKEY
needs to be more general. Therefore it might be hard to see the needs to be more general. Therefore it might be hard to see the
relations between keys and parameters generated in MIKEY and the ones relations between keys and parameters generated in MIKEY and the ones
used by SRTP. This section provides some hints on their relation. used by SRTP. This section provides some hints on their relation.
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.
Revision history This Internet-Draft expires in April 2003.
Changes from -01 draft:
* Removed: Support for Re-key SA including KEK transport for all
methods.
* Timestamp required explicitly in the verification message
* Renamed R flag in Common header to V (for verification)
* Change of notation
- Pre-Master Key (PMK) --> TEK Generation Key (TGK)
- Multimedia Crypto Session (MCS) --> Crypto Session Bundle (CSB)
- Some payloads have also had their name changed.
- Seed (in the PRF definition) --> Label
* General extensions payload added.
* Possibility to send a TEK only (instead of a TGK) is provided for
pre-encryption purposes.
* General updates of all sections (trying to address all comments
received from the list).
* IANA considerations added
Changes from -02 draft:
* General editorial updates
* Clarifications about replay cache added in Section 5.4
* Clarification about replay/timestamps usage vs DoS added in
Section 9.5
This Internet-Draft expires in March 2003.
 End of changes. 

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