draft-ietf-msec-mikey-02.txt   draft-ietf-msec-mikey-03.txt 
Internet Engineering Task Force J. Arkko Internet Engineering Task Force J. Arkko
MSEC Working Group E. Carrara MSEC Working Group E. Carrara
INTERNET-DRAFT F. Lindholm INTERNET-DRAFT F. Lindholm
Expires: December 2002 M. Naslund Expires: January 2003 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
June, 2002 July, 2002
MIKEY: Multimedia Internet KEYing MIKEY: Multimedia Internet KEYing
<draft-ietf-msec-mikey-02.txt> <draft-ietf-msec-mikey-03.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 52 skipping to change at page 2, line 52
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
5.5. Reliability...................................................25 5.5. Reliability...................................................25
6. Payload Encoding................................................25 6. Payload Encoding................................................25
6.1. Common header payload (HDR)...................................25 6.1. Common header payload (HDR)...................................25
6.1.1. SRTP ID.....................................................27 6.1.1. SRTP ID.....................................................28
6.2. Key data transport payload (KEMAC)............................28 6.2. Key data transport payload (KEMAC)............................28
6.3. Envelope data payload (PKE)...................................29 6.3. Envelope data payload (PKE)...................................30
6.4. DH data payload (DH)..........................................30 6.4. DH data payload (DH)..........................................30
6.5. Signature payload (SIGN)......................................31 6.5. Signature payload (SIGN)......................................31
6.6. Timestamp payload (T).........................................31 6.6. Timestamp payload (T).........................................31
6.7. ID payload (ID) / Certificate payload (CERT)..................32 6.7. ID payload (ID) / Certificate payload (CERT)..................32
6.8. Cert hash payload (CHASH).....................................32 6.8. Cert hash payload (CHASH).....................................33
6.9. Ver msg payload (V)...........................................33 6.9. Ver msg payload (V)...........................................33
6.10. Security Policy payload (SP).................................33 6.10. Security Policy payload (SP).................................34
6.10.1. SRTP policy................................................34 6.10.1. SRTP policy................................................35
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
skipping to change at page 3, line 38 skipping to change at page 3, line 38
9.3. Timestamps....................................................45 9.3. Timestamps....................................................45
9.4. Identity protection...........................................46 9.4. Identity protection...........................................46
9.5. Denial of Service.............................................46 9.5. Denial of Service.............................................46
9.6. Session establishment.........................................46 9.6. Session establishment.........................................46
10. IANA considerations............................................47 10. IANA considerations............................................47
11. Conclusions....................................................49 11. Conclusions....................................................49
12. Acknowledgments................................................49 12. Acknowledgments................................................49
13. Author's Addresses.............................................49 13. Author's Addresses.............................................49
14. References.....................................................50 14. References.....................................................50
14.1. Normative References.........................................50 14.1. Normative References.........................................50
14.2. Informative References.......................................50 14.2. Informative References.......................................51
Appendix A. - MIKEY - SRTP relation................................52 Appendix A. - MIKEY - SRTP relation................................52
Revision history...................................................52 Revision history...................................................52
1. Introduction 1. Introduction
There has recently been work to define a security protocol for the There has recently been work to define a security protocol for the
protection of real-time applications running over RTP, [SRTP]. protection of real-time applications running over RTP, [SRTP].
However, a security protocol needs a key management solution to However, a security protocol needs a key management solution to
exchange keys, security parameters, etc. There are some fundamental exchange keys, security parameters, etc. There are some fundamental
properties that such a key management scheme has to fulfil with properties that such a key management scheme has to fulfil with
skipping to change at page 17, line 26 skipping to change at page 17, line 26
with the NULL encryption algorithm (but is not mandatory to with the NULL encryption algorithm (but is not mandatory to
implement). Note that this MUST NOT be used unless the underlying implement). Note that this MUST NOT be used unless the underlying
protocols can guarantee the security. The main reason for including protocols can guarantee the security. The main reason for including
this is for certain specific SIP scenarios, where SDP is protected this is for certain specific SIP scenarios, where SDP is protected
end-to-end. For this scenario, MIKEY MAY be used with the pre-shared end-to-end. For this scenario, MIKEY MAY be used with the pre-shared
key method and the NULL encryption and authentication algorithm while key method and the NULL encryption and authentication algorithm while
relying on the security of SIP. Use this option with caution! relying on the security of SIP. Use this option with caution!
4.2.5 Envelope Key encryption 4.2.5 Envelope Key encryption
The public key encryption algorithm applied is defined in, and The public key encryption algorithm applied is defined by, and
dependent on the certificate used. dependent on the certificate used.
4.2.6 Digital Signatures 4.2.6 Digital Signatures
The signature algorithm applied is defined in, and dependent on the The signature algorithm applied is defined by, and dependent on the
certificate used. certificate used.
4.2.7 Diffie-Hellman Groups 4.2.7 Diffie-Hellman Groups
The Diffie-Hellman key exchange uses OAKLEY 5 [OAKLEY] as mandatory The Diffie-Hellman key exchange uses OAKLEY 5 [OAKLEY] as mandatory
to implement. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are to implement. Both OAKLEY 1 and OAKLEY 2 MAY be used (but these are
not mandatory to implement). not mandatory to implement).
4.2.8. Timestamps 4.2.8. Timestamps
skipping to change at page 19, line 43 skipping to change at page 19, line 43
used, but the envelope key is not cached, the Initiator MUST provide used, but the envelope key is not cached, the Initiator MUST provide
a new encrypted envelope key that can be used in the verification a new encrypted envelope key that can be used in the verification
message. However, the Initiator does not need to provide any other message. However, the Initiator does not need to provide any other
keys. keys.
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
Sessions. A problem that then might occur is to synchronize the TGK
re-keying if an SPI (or similar functionality, e.g., MKI) is not
used. It is therefore recommended that an SPI or MKI is used, if more
than one Crypto Session is used.
Initiator Responder Initiator Responder
Pre-shared key method: Pre-shared key method:
I_MESSAGE = I_MESSAGE =
HDR, T, [IDi], {SP}, KEMAC ---> HDR, T, [IDi], {SP}, KEMAC --->
R_MESSAGE = R_MESSAGE =
[<---] HDR, T, [IDr], V [<---] HDR, T, [IDr], V
Public key method: Public key method:
I_MESSAGE = I_MESSAGE =
HDR, T, [IDi|CERTi], {SP}, {CHASH}, HDR, T, [IDi|CERTi], {SP}, [CHASH],
[KEMAC], PKE, SIGNi ---> [KEMAC], PKE, SIGNi --->
R_MESSAGE = R_MESSAGE =
[<---] HDR, T, [IDr], V [<---] HDR, T, [IDr], V
DH method: DH method:
I_MESSAGE = I_MESSAGE =
HDR, T, [IDi|CERTi], {SP}, HDR, T, [IDi|CERTi], {SP},
[DHi], SIGNi ---> [DHi], SIGNi --->
R_MESSAGE = R_MESSAGE =
<--- HDR, T, [IDr|CERTr], IDi, <--- HDR, T, [IDr|CERTr], IDi,
[DHr, DHi], SIGNr [DHr, DHi], SIGNr
Figure 4.1: Update messages. Figure 4.1: Update messages.
By definition, a Crypto Session Bundle can contain several Crypto
Sessions. A problem that then might occur is to synchronize the TGK
re-keying if an SPI (or similar functionality, e.g., MKI) is not
used. It is therefore recommended that an SPI or MKI is used, if more
than one Crypto Session is used.
5. Behavior and message handling 5. Behavior and message handling
Each message that is sent by the Initiator or the Responder, is built Each message that is sent by the Initiator or the Responder, is built
by a set of payloads. This section describes how messages are created by a set of payloads. This section describes how messages are created
and also when they can be used. and also when they can be used.
5.1. General 5.1. General
5.1.1. Capability Discovery 5.1.1. Capability Discovery
skipping to change at page 25, line 10 skipping to change at page 25, line 16
approximately 20 minutes. approximately 20 minutes.
In a more extreme case, where the maximum number of incoming messages In a more extreme case, where the maximum number of incoming messages
are assumed to be on the order of 120 messages per minute, and a are assumed to be on the order of 120 messages per minute, and a
requirement that the clock skew is on the order of 10 minutes, a 48kB requirement that the clock skew is on the order of 10 minutes, a 48kB
replay cache would be required. replay cache would be required.
One recommendation is to fix a size for the replay cache, and let the One recommendation is to fix a size for the replay cache, and let the
allowable clock skew be large. As the replay cache grows, the clock allowable clock skew be large. As the replay cache grows, the clock
skew is decreased depending on how many percent of the replay cache skew is decreased depending on how many percent of the replay cache
that are used. that are used. Note that this is locally handled, which will not
require interaction with the peer (even though it may indirectly
affect the peer). Exactly how to implement such functionality is
however out of the scope of this document and considered
implementation specific.
In case of a DoS attack, the client will in most cases be able to In case of a DoS attack, the client will in most cases be able to
handle the replay cache. A bigger problem will probably be to process handle the replay cache. A bigger problem will probably be to process
the messages (verify signatures/MACs), due to the computational the messages (verify signatures/MACs), due to the computational
workload this implies. workload this implies.
5.5. Reliability 5.5. Reliability
If MIKEY is sent on an unreliable transport, the basic processing If MIKEY is sent on an unreliable transport, the basic processing
applied to ensure protocol reliability is the following. applied to ensure protocol reliability is the following.
skipping to change at page 32, line 10 skipping to change at page 32, line 22
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)
The ID payload carries a uniquely-defined identifier. The ID payload carries a uniquely-defined identifier.
The certificate payload contains an indicator of the certificate The certificate payload contains an indicator of the certificate
provided as well as the certificate data. provided as well as the certificate data. If a certificate chain are
to be provided, each certificate in the chain should be included in a
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
skipping to change at page 46, line 39 skipping to change at page 46, line 39
This protocol is resistant to Denial of Service attacks in the sense This protocol is resistant to Denial of Service attacks in the sense
that a Responder does not construct any state (at the key management that a Responder does not construct any state (at the key management
protocol level) before it has authenticated the Initiator. However, protocol level) before it has authenticated the Initiator. However,
this protocol, like many others, is open to attacks that use spoofed this protocol, like many others, is open to attacks that use spoofed
IP addresses to create a large number of fake requests. This may IP addresses to create a large number of fake requests. This may
e.g., be solved by letting the protocol transporting MIKEY do an IP e.g., be solved by letting the protocol transporting MIKEY do an IP
address validity test. For example, the SIP protocol can provide this address validity test. For example, the SIP protocol can provide this
using the anonymous authentication challenge mechanism (specified in using the anonymous authentication challenge mechanism (specified in
Section 22.1 of [SIP]). Section 22.1 of [SIP]).
As also discussed in Section 5.4, the tradeoff between time
synchronization and the size of the replay cache, may be affected in
case of e.g., a flooding type of DoS attack. However, if the
recommendations of using a dynamic size of the replay cache are
followed, it is believed that the client will in most cases be able
to handle the replay cache. Of course, as the replay cache decreases
in size, the required time synchronization is more restricted.
However, a bigger problem during such attack would probably be to
process the messages (e.g., verify signatures/MACs), due to the
computational workload this implies.
9.6. Session establishment 9.6. Session establishment
It should be noted that if the session establishment protocol is It should be noted that if the session establishment protocol is
insecure there may be attacks on this that will have indirect insecure there may be attacks on this that will have indirect
security implications on the secured media streams. This however only security implications on the secured media streams. This however only
applies to groups (and is not specific to MIKEY). The threat is that applies to groups (and is not specific to MIKEY). The threat is that
one group member may re-direct a stream from one group member to one group member may re-direct a stream from one group member to
another. This will have the same implication as when a member tries another. This will have the same implication as when a member tries
to impersonate another member, e.g. by changing its IP address. If to impersonate another member, e.g. by changing its IP address. If
this is seen as a problem, it is RECOMMENDED that a Source Origin this is seen as a problem, it is RECOMMENDED that a Source Origin
skipping to change at page 52, line 41 skipping to change at page 52, line 41
- Multimedia Crypto Session (MCS) --> Crypto Session Bundle (CSB) - Multimedia Crypto Session (MCS) --> Crypto Session Bundle (CSB)
- Some payloads have also had their name changed. - Some payloads have also had their name changed.
- Seed (in the PRF definition) --> Label - Seed (in the PRF definition) --> Label
* General extensions payload added. * General extensions payload added.
* Possibility to send a TEK only (instead of a TGK) is provided for * Possibility to send a TEK only (instead of a TGK) is provided for
pre-encryption purposes. pre-encryption purposes.
* 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
This Internet-Draft expires in December 2002. 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 January 2003.
 End of changes. 

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