draft-ietf-msec-mikey-03.txt   draft-ietf-msec-mikey-04.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: January 2003 M. Naslund Expires: March 2003 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
July, 2002 September, 2002
MIKEY: Multimedia Internet KEYing MIKEY: Multimedia Internet KEYing
<draft-ietf-msec-mikey-03.txt> <draft-ietf-msec-mikey-04.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 2, line 38 skipping to change at page 2, line 38
4.1.5. Generating keys from an envelope/pre-shared key.............15 4.1.5. Generating keys from an envelope/pre-shared key.............15
4.2 Pre-defined Transforms and Timestamp Formats...................16 4.2 Pre-defined Transforms and Timestamp Formats...................16
4.2.1 Hash functions...............................................16 4.2.1 Hash functions...............................................16
4.2.2 Pseudo random number generator and PRF.......................16 4.2.2 Pseudo random number generator and PRF.......................16
4.2.3 Key data transport encryption................................16 4.2.3 Key data transport encryption................................16
4.2.4 MAC and Verification Message function........................17 4.2.4 MAC and Verification Message function........................17
4.2.5 Envelope Key encryption......................................17 4.2.5 Envelope Key encryption......................................17
4.2.6 Digital Signatures...........................................17 4.2.6 Digital Signatures...........................................17
4.2.7 Diffie-Hellman Groups........................................17 4.2.7 Diffie-Hellman Groups........................................17
4.2.8. Timestamps..................................................17 4.2.8. Timestamps..................................................17
4.2.9. Adding new parameters to MIKEY..............................17 4.2.9. Adding new parameters to MIKEY..............................18
4.3. Policies......................................................18 4.3. Policies......................................................18
4.4. Retrieving the Data SA........................................18 4.4. Retrieving the Data SA........................................18
4.5. TGK re-keying and CSB updating................................19 4.5. TGK re-keying and CSB updating................................19
5. Behavior and message handling...................................20 5. Behavior and message handling...................................20
5.1. General.......................................................20 5.1. General.......................................................20
5.1.1. Capability Discovery........................................20 5.1.1. Capability Discovery........................................20
5.1.2. Error Handling..............................................21 5.1.2. Error Handling..............................................21
5.2. Creating a message............................................21 5.2. Creating a message............................................21
5.3. Parsing a message.............................................23 5.3. Parsing a message.............................................23
5.4. Replay handling and timestamp usage...........................23 5.4. Replay handling and timestamp usage...........................23
skipping to change at page 3, line 22 skipping to change at page 3, line 22
6.11. RAND payload (RAND)..........................................36 6.11. RAND payload (RAND)..........................................36
6.12. Error payload (ERR)..........................................36 6.12. Error payload (ERR)..........................................36
6.13. Key data sub-payload.........................................37 6.13. Key data sub-payload.........................................37
6.14. Key validity data............................................38 6.14. Key validity data............................................38
6.15. General Extension Payload....................................39 6.15. General Extension Payload....................................39
7. Integration with session establishment protocols................40 7. Integration with session establishment protocols................40
7.1. SDP integration...............................................40 7.1. SDP integration...............................................40
7.2. MIKEY within SIP..............................................40 7.2. MIKEY within SIP..............................................40
7.3. MIKEY with RTSP...............................................41 7.3. MIKEY with RTSP...............................................41
7.4. MIKEY Interface...............................................42 7.4. MIKEY Interface...............................................42
8. Groups..........................................................42 8. Groups..........................................................43
8.1. Simple one-to-many............................................43 8.1. Simple one-to-many............................................43
8.2. Small-size interactive group..................................43 8.2. Small-size interactive group..................................43
9. Security Considerations.........................................44 9. Security Considerations.........................................44
9.1. General.......................................................44 9.1. General.......................................................44
9.2. Key lifetime..................................................45 9.2. Key lifetime..................................................46
9.3. Timestamps....................................................45 9.3. Timestamps....................................................46
9.4. Identity protection...........................................46 9.4. Identity protection...........................................47
9.5. Denial of Service.............................................46 9.5. Denial of Service.............................................47
9.6. Session establishment.........................................46 9.6. Session establishment.........................................47
10. IANA considerations............................................47 10. IANA considerations............................................48
11. Conclusions....................................................49 11. Conclusions....................................................49
12. Acknowledgments................................................49 12. Acknowledgments................................................50
13. Author's Addresses.............................................49 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................................52 Appendix A. - MIKEY - SRTP relation................................53
Revision history...................................................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 fulfil with
respect to the kind of real-time applications (streaming, unicast, respect to the kind of real-time applications (streaming, unicast,
groups, multicast, etc.) and to the heterogeneous nature of the groups, multicast, etc.) and to the heterogeneous nature of the
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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 on different security related topics.
2. Basic Overview 2. Basic Overview
2.1. Scenarios 2.1. Scenarios
MIKEY is intended to be used for peer-to-peer, simple one-to-many, MIKEY is mainly intended to be used for peer-to-peer, simple one-to-
and small-size (interactive) groups. One of the main multimedia many, and small-size (interactive) groups. One of the main multimedia
scenarios is the conversational multimedia scenario, where users may scenarios considered when designing MIKEY has been the conversational
interact and communicate in real-time. In these scenarios it can be multimedia scenario, where users may interact and communicate in
expected that peers set up multimedia sessions between each other, real-time. In these scenarios it can be expected that peers set up
where a multimedia session may consist of one or more secured multimedia sessions between each other, where a multimedia session
multimedia streams (e.g. SRTP streams). may consist of one or more secured multimedia streams (e.g. SRTP
streams).
peer-to-peer/ many-to-many many-to-many peer-to-peer/ many-to-many many-to-many
simple one-to-many (distributed) (centralized) simple one-to-many (distributed) (centralized)
++++ ++++ ++++ ++++ ++++ ++++ ++++ ++++ ++++ ++++
|. | |A | |B | |A |---- ----|B | |. | |A | |B | |A |---- ----|B |
--| ++++ | |----------| | | | \ / | | --| ++++ | |----------| | | | \ / | |
++++ / ++|. | ++++ ++++ ++++ (S) ++++ ++++ / ++|. | ++++ ++++ ++++ (S) ++++
|A |---------| ++++ \ / | |A |---------| ++++ \ / |
| | \ ++|B | \ / | | | \ ++|B | \ / |
++++ \-----| | \ ++++ / ++++ ++++ \-----| | \ ++++ / ++++
skipping to change at page 7, line 13 skipping to change at page 7, line 13
for its own outgoing media. for its own outgoing media.
c) many-to-many, with a centralized control unit, e.g. for larger c) many-to-many, with a centralized control unit, e.g. for larger
groups with some kind of Group Controller that sets up the groups with some kind of Group Controller that sets up the
security. security.
d) simple one-to-many (multicast), e.g. real-time presentations, d) simple one-to-many (multicast), e.g. real-time presentations,
where the sender is in charge of setting up the security. where the sender is in charge of setting up the security.
The key management solutions may be different in the above scenarios. The key management solutions may be different in the above scenarios.
MIKEY addresses all of the above, except case c. 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
characteristics: characteristics:
* End-to-end security. Only the participants have access to the * End-to-end security. Only the participants have access to the
generated key(s). generated key(s).
* Simplicity. * Simplicity.
skipping to change at page 12, line 9 skipping to change at page 12, line 9
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 (except the MAC field). The encr_key and the auth_key is derived from
the envelope key, env_key (see Section 4.1.5). See also Section 6.2 the envelope key, env_key (see Section 4.1.5). See also Section 6.2
for payload definition. 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. It is encrypted using
the Responder's public key. If the Responder posses several public the Responder's public key. If the Responder posses several public
keys, the Initiator can use CHASH to indicate the key used. 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,
I_MESSAGE, using the Initiator's signature key. I_MESSAGE, using the Initiator's signature key.
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. It is calculated in the same way as
for the one in the pre-shared key mode (see also Section 5.2 for the 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. exact definition). See Section 6.9 for payload definition.
Note that there will be one encrypted IDr and possibly also one Note that there will be one encrypted IDi and possibly also one
unencrypted IDr. The encrypted one is needed to avoid certain man-in- unencrypted IDi. The encrypted one is needed to avoid certain man-in-
the-middle attacks, while the unencrypted is always useful for the the-middle attacks, while the unencrypted is always useful for the
Responder to immediately identify the Initiator. Responder to immediately identify the Initiator.
It is possible to cache the envelope key, so that it can be used as a It is possible to cache the envelope key, so that it can be used as a
pre-shared key. It is not recommended 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
skipping to change at page 15, line 54 skipping to change at page 15, line 54
Note that the 32-bit constant integers (i.e. 0x2AD01C64 or the one Note that the 32-bit constant integers (i.e. 0x2AD01C64 or the one
replacing it) are taken from the decimal digits of e (i.e. replacing it) are taken from the decimal digits of e (i.e.
2.7182...), and where each constant consist of nine decimals digits 2.7182...), and where each constant consist of nine decimals digits
(e.g. the first nine decimal digits 718281828 = 0x2AD01C64). The (e.g. the first nine decimal digits 718281828 = 0x2AD01C64). The
strings of nine decimal digits are not chosen at random, but as strings of nine decimal digits are not chosen at random, but as
consecutive "chunks" from the decimal digits of e. consecutive "chunks" from the decimal digits of e.
4.1.5. Generating keys from an envelope/pre-shared key 4.1.5. Generating keys from an envelope/pre-shared key
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 methods. This is also used to derive the symmetric key used for
the message authentication code in these messages (and the
corresponding verification messages). Hence, this derivation is
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
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 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 length of the authentication/encryption/salting
key. key.
skipping to change at page 19, line 18 skipping to change at page 19, line 29
MIKEY provides the means to update the CSB (e.g. transporting a new MIKEY provides the means to update the CSB (e.g. transporting a new
TGK/TEK or adding a new Crypto Session to the CSB). The updating of TGK/TEK or adding a new Crypto Session to the CSB). The updating of
the CSB is done by the Initiator and performed by executing MIKEY the CSB is done by the Initiator and performed by executing MIKEY
again e.g. before a TEK expires, or when a new Crypto Session is again e.g. before a TEK expires, or when a new Crypto Session is
added to the CSB. Note that MIKEY does not provide re-keying in the added to the CSB. Note that MIKEY does not provide re-keying in the
GKMARCH sense, only updating of the keys by normal unicast messages. GKMARCH sense, only updating of the keys by normal unicast messages.
When MIKEY is executed again to update the CSB, it is not necessary When MIKEY is executed again to update the CSB, it is not necessary
to include certificates and other information that was provided in to include certificates and other information that was provided in
the first exchange, i.e. all parameters that are static or optional the first exchange, i.e. all payloads that are static or optional to
to include may be left out. include may be left out (see Figure 4.1).
The new message exchange uses the same CSB ID as the initial The new message exchange uses the same CSB ID as the initial
exchange, but a new timestamp. A new RAND is NOT included in the exchange, but a new timestamp. A new RAND is NOT included in the
message exchange (the RAND will only have affect in the Initial message exchange (the RAND will only have affect in the Initial
exchange). New Crypto Sessions are added if desired in the update exchange). New Crypto Sessions are added if desired in the update
message. Therefore, the new MIKEY message does not need to contain message. Note that a MIKEY update message does not need to contain
keys. new keying material (i.e., new TGK). In this case the crypto session
continues to use the previously established keying material, while
updating the new information.
As explained in Section 3.2, the envelope key can be "cached" as a As explained in Section 3.2, the envelope key can be "cached" as a
pre-shared key (this is indicated by the Initiator in the first pre-shared key (this is indicated by the Initiator in the first
message sent). If so, the "update message" is a pre-shared key message sent). If so, the update message is a pre-shared key message
message (with the cached envelope key as the pre-shared key), i.e., (with the cached envelope key as the pre-shared key), i.e., it MUST
it MUST NOT be a public key message. If the public key message is NOT be a public key message. If the public key message is used, but
used, but the envelope key is not cached, the Initiator MUST provide the envelope key is not cached, the Initiator MUST provide a new
a new encrypted envelope key that can be used in the verification encrypted envelope key that can be used in the verification message.
message. However, the Initiator does not need to provide any other However, the Initiator does not need to provide any other keys.
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 differences 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).
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
skipping to change at page 22, line 27 skipping to change at page 22, line 27
: : : : : :
: : : : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! next payload ! Payload x ... ! ! next payload ! Payload x ... !
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! MAC/Signature ~ ! MAC/Signature ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5.1. MIKEY payload message example. Figure 5.1. MIKEY payload message example. Note that the payloads are
byte aligned and not 32-bit aligned.
The process of generating a MIKEY message consists of the following The process of generating a MIKEY message consists of the following
steps: steps:
* Create an initial MIKEY message starting with the Common header * Create an initial MIKEY message starting with the Common header
payload. payload.
* Concatenate necessary payloads to the MIKEY message (see the * Concatenate necessary payloads to the MIKEY message (see the
exchange definitions for payloads that may be included and exchange definitions for payloads that may be included and
recommended order). recommended order).
skipping to change at page 32, line 19 skipping to change at page 32, line 19
TS type | Value | Comments TS type | Value | Comments
------------------------------------- -------------------------------------
NTP-UTC | 0 | Mandatory (64-bits) NTP-UTC | 0 | Mandatory (64-bits)
NTP | 1 | Mandatory (64-bits) NTP | 1 | Mandatory (64-bits)
* TS-value: The timestamp value of the specified TS type. * TS-value: The timestamp value of the specified TS type.
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
completely different payloads (having different payload identifiers).
However, as they share the same payload structure they are described
in the same section.
The ID payload carries a uniquely-defined identifier. The ID payload carries a uniquely-defined identifier.
The certificate payload contains an indicator of the certificate The certificate payload contains an indicator of the certificate
provided as well as the certificate data. If a certificate chain are provided as well as the certificate data. If a certificate chain are
to be provided, each certificate in the chain should be included in a to be provided, each certificate in the chain should be included in a
separate CERT payload. separate CERT payload.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! ID/Cert Type ! ID/Cert len ! ! Next Payload ! ID/Cert Type ! ID/Cert len !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID/Certificate Data ~ ! ID/Certificate Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* next payload: identifies the payload that is added after this * next payload: identifies the payload that is added after this
payload. See Section 6.1 for values. payload. See Section 6.1 for values.
If the payload is an ID payload the following values applies for the
ID type field:
* ID Type: specifies the identifier type used. * ID Type: specifies the identifier type used.
ID Type | Value | Comments ID Type | Value | Comments
---------------------------------------------- ----------------------------------------------
NAI | 0 | Mandatory (see [NAI]) NAI | 0 | Mandatory (see [NAI])
URI | 1 | Mandatory (see [URI]) URI | 1 | Mandatory (see [URI])
If the payload is an Certificate payload the following values applies
for the Cert type field:
* Cert Type: specifies the certificate type used. * Cert Type: specifies the certificate type used.
Cert Type | Value | Comments Cert Type | Value | Comments
---------------------------------------------- ----------------------------------------------
X.509v3 | 0 | Mandatory X.509v3 | 0 | Mandatory
X.509v3 URL | 1 | plain ASCII URL to the location of the Cert X.509v3 URL | 1 | plain ASCII URL to the location of the Cert
X.509v3 Sign | 2 | Mandatory (used for signatures only) X.509v3 Sign | 2 | Mandatory (used for signatures only)
X.509v3 Encr | 3 | Mandatory (used for encryption only) X.509v3 Encr | 3 | Mandatory (used for encryption only)
* ID/Cert len: The length of the ID or Certificate field (in bytes). * ID/Cert len: The length of the ID or Certificate field (in bytes).
skipping to change at page 35, line 7 skipping to change at page 35, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Type: specifies the type of the parameter. * Type: specifies the type of the parameter.
* Length: specifies the length of the Value field (in bytes). * Length: specifies the length of the Value field (in bytes).
* Value: specifies the value of the parameter. * Value: specifies the value of the parameter.
6.10.1. SRTP policy 6.10.1. SRTP policy
This policy specifies the policy for SRTP and SRTCP. The types/values This policy specifies the parameters for SRTP and SRTCP. The
that can be negotiated are defined by the following table: types/values that can be negotiated are defined by the following
table:
Type | Meaning | Possible values Type | Meaning | Possible values
---------------------------------------------------- ----------------------------------------------------
0 | Encryption algorithm | see below 0 | Encryption algorithm | see below
1 | Session Encr. key length | depends on cipher used 1 | Session Encr. key length | depends on cipher used
2 | Authentication algorithm | see below 2 | Authentication algorithm | see below
3 | Session Auth. key length | depends on MAC used 3 | Session Auth. key length | depends on MAC used
4 | Session Salt key length | see [SRTP] for recommendations 4 | Session Salt key length | see [SRTP] for recommendations
5 | SRTP Pseudo Random Function | see below 5 | SRTP Pseudo Random Function | see below
6 | Key derivation rate | see [SRTP] for recommendations 6 | Key derivation rate | see [SRTP] for recommendations
skipping to change at page 37, line 4 skipping to change at page 37, line 16
See Section 6.1 for values. See 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 | 3 | Encryption algorithm not supported Invalid EA | 4 | Encryption algorithm not supported
Invalid HA | 3 | Hash function not supported Invalid HA | 5 | Hash function not supported
Invalid DH | 4 | DH group not supported Invalid DH | 6 | DH group not supported
Invalid ID | 5 | ID not supported Invalid ID | 7 | ID not supported
Invalid Cert | 6 | Certificate not supported Invalid Cert | 8 | Certificate not supported
Invalid SP | 7 | SP type not supported Invalid SP | 9 | SP type not supported
Invalid SPpar | 8 | SP parameters not supported Invalid SPpar | 10 | SP parameters not supported
6.13. Key data sub-payload 6.13. Key data sub-payload
The Key data payload contains TGKs. The Key data payloads are never The Key data payload contains TGKs. The Key data payloads are never
included in clear, but as an encrypted part of the Key data transport included in clear, but as an encrypted part of the Key data transport
payload. payload.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 43, line 35 skipping to change at page 43, line 48
MIKEY. In this scenario the pre-shared key or public key transport MIKEY. In this scenario the pre-shared key or public key transport
mechanism will be appropriate to use to transport the same TGK to all mechanism will be appropriate to use to transport the same TGK to all
the clients (which will result in common TEKs for the group). the clients (which will result in common TEKs for the group).
Note, if the same TGK/TEK(s) should be used by all the group members, Note, if the same TGK/TEK(s) should be used by all the group members,
the streaming server MUST specify the same CSB_ID and CS_ID(s) for the streaming server MUST specify the same CSB_ID and CS_ID(s) for
the session to all the group members. the session to all the group members.
8.2. Small-size interactive group 8.2. Small-size interactive group
As described in the overview section, for small-size interactive
groups, one may expect that each client will be in charge for setting
up the security for its outgoing streams. In these scenarios, the
pre-shared key or the public-key transport method is used.
++++ ++++ ++++ ++++
|A | -------> |B | |A | -------> |B |
| | <------- | | | | <------- | |
++++ ++++ ++++ ++++
^ | | ^ ^ | | ^
| | | | | | | |
| | ++++ | | | | ++++ | |
| --->|C |<--- | | --->|C |<--- |
------| |------ ------| |------
++++ ++++
Figure 8.2. Small-size group without centralized controller. Figure 8.2. Small-size group without centralized controller.
As described in the overview section, for small-size interactive
groups, one may expect that each client will be in charge for setting
up the security for its outgoing streams. In these scenarios, the
pre-shared key or the public-key transport method is used.
One scenario may then be that the client sets up a three-part call, One scenario may then be that the client sets up a three-part call,
using SIP. Due to the small size of the group, unicast SRTP is used using SIP. Due to the small size of the group, unicast SRTP is used
between the clients. Each client sets up the security for its between the clients. Each client sets up the security for its
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
skipping to change at page 45, line 5 skipping to change at page 45, line 22
Section 4.1). The TEK derivation method assures this by providing Section 4.1). The TEK derivation method assures this by providing
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 are implemented by a pseudo-random
function. The one used here is a simplified version of that used in function. The one used here is a simplified version of that used in
TLS [TLS]. Here, only one single hash function is used, whereas TLS TLS [TLS]. Here, only one single hash function is used, whereas TLS
uses two different functions. This choice is motivated by the high uses two different functions. This choice is motivated by the high
confidence in the SHA-1 hash function, and, by efficiency and confidence in the SHA-1 hash function, and, by efficiency and
simplicity of design (complexity does not imply security). Note that simplicity of design (complexity does not imply security). Indeed, as
the use of the RAND nonce in the key derivation is essential to shown in [DBJ], if one of the two hashes is severely broken, the TLS
protect against off-line time/memory trade-off attacks. PRF is actually less secure than if a single hash had been used on
the whole key. Thus, the construction does not meet its goals.
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 more sensitive if the a single party (Initiator). This makes MIKEY more sensitive if the
Initiator uses a bad random number generator. It should also be noted Initiator uses a bad random number generator. It should also be noted
that neither the pre-shared nor the public-key scheme provides that neither the pre-shared nor the public-key scheme provides
perfect forward secrecy. If mutual contribution or perfect forward perfect forward secrecy. If mutual contribution or perfect forward
secrecy is desired, the Diffie-Hellman method is to be used. 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 use of random nonces (RANDs) in the key derivation is of utmost
importance to counter off-line pre-computation attacks. Note however
that update messages re-use the old RAND. This means that the total
effective key entropy (relative to pre-computation attacks) for k
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
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
note 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
problematic. Consider for instance a user who, using say a fixed
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
enable access to all exchanged keys and consequently the entire
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.
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
skipping to change at page 51, line 11 skipping to change at page 51, line 46
[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.
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- Asiacrypt'01, Lecture Notes in Computer Science vol 2248, pp. 442-
459. 459.
[DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use of
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
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
skipping to change at page 52, line 47 skipping to change at page 53, line 47
* General updates of all sections (trying to address all comments * General updates of all sections (trying to address all comments
received from the list). received from the list).
* IANA considerations added * IANA considerations added
Changes from -02 draft: Changes from -02 draft:
* General editorial updates * General editorial updates
* Clarifications about replay cache added in Section 5.4 * Clarifications about replay cache added in Section 5.4
* Clarification about replay/timestamps usage vs DoS added in * Clarification about replay/timestamps usage vs DoS added in
Section 9.5 Section 9.5
This Internet-Draft expires in January 2003. 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/