draft-ietf-msec-mikey-05.txt   draft-ietf-msec-mikey-06.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: April 2003 M. Naslund Expires: August 2003 M. Naslund
K. Norrman K. Norrman
Ericsson Ericsson
October 29, 2002 February, 2003
MIKEY: Multimedia Internet KEYing MIKEY: Multimedia Internet KEYing
<draft-ietf-msec-mikey-05.txt> <draft-ietf-msec-mikey-06.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 18 skipping to change at page 3, line 18
6.9. Ver msg payload (V)...........................................33 6.9. Ver msg payload (V)...........................................33
6.10. Security Policy payload (SP).................................34 6.10. Security Policy payload (SP).................................34
6.10.1. SRTP policy................................................35 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..............................................41
7.3. MIKEY with RTSP...............................................41 7.3. MIKEY with RTSP...............................................42
7.4. MIKEY Interface...............................................42 7.4. MIKEY Interface...............................................42
8. Groups..........................................................43 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..................................44
9. Security Considerations.........................................44 9. Security Considerations.........................................44
9.1. General.......................................................44 9.1. General.......................................................44
9.2. Key lifetime..................................................46 9.2. Key lifetime..................................................46
9.3. Timestamps....................................................46 9.3. Timestamps....................................................46
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.........................................48
10. IANA considerations............................................48 10. IANA considerations............................................48
11. Conclusions....................................................49 11. Conclusions....................................................50
12. Acknowledgments................................................50 12. Acknowledgments................................................50
13. Author's Addresses.............................................50 13. Author's Addresses.............................................50
14. References.....................................................50 14. References.....................................................51
14.1. Normative References.........................................50 14.1. Normative References.........................................51
14.2. Informative References.......................................51 14.2. Informative References.......................................52
Appendix A. - MIKEY - SRTP relation................................52 Appendix A. - MIKEY - SRTP relation................................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 fulfill 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
skipping to change at page 39, line 48 skipping to change at page 39, line 48
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
The General extensions payload is included to allow possible The General extensions payload is included to allow possible
extensions to MIKEY without the need to define a complete new payload extensions to MIKEY without the need to define a complete new payload
each time. This payload can be used in any MIKEY message. Currently each time. This payload can be used in any MIKEY message and is part
the only use defined, is to transport Vendor Id. Support of the of the authenticated/signed data part.
Vendor ID is OPTIONAL.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next payload ! Type ! Length ! ! Next payload ! Type ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Data ~ ! Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next payload: identifies the payload that is added after this * Next payload: identifies the payload that is added after this
payload. payload.
* Type: identifies the type of the general payload. * Type: identifies the type of the general payload.
Type | Value | Comments Type | Value | Comments
--------------------------------------- ---------------------------------------
Vendor ID | 0 | Vendor specific byte string Vendor ID | 0 | Vendor specific byte string
SDP IDs | 1 | List of SDP key mgmt IDs (see also Section 7.1)
* 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 and RTSP. It is based on [KMASDP], which describes extensions to
SIP/SDP and RTSP 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 SHALL use the name
"mikey" as a protocol name in SDP and RTSP. The key management data "mikey" as a protocol identifier in SDP and RTSP. The key management
that is placed in SDP or RTSP MUST be base64 encoded. data that is placed in SDP or RTSP MUST be base64 encoded.
Following the requirements in [KMASDP] (to avoid certain types of
bidding down attacks when more than one key management protocol is
offered within SDP), MIKEY SHALL specify how to authenticate the list
of identifiers in SDP. In MIKEY, the list of protocol identifiers
MUST be input to MIKEY by SDP with ";" separated identifiers. All the
offered protocol identifiers MUST be included, in the same order as
they appear in the corresponding SDP description; if only MIKEY is
offered, the only protocol identifier to be included SHALL be
"mikey". MIKEY MUST place this list in a General Extension Payload
(of type "SDP IDs") which then automatically will be integrity
protected/signed. The receiver can then match the list in the General
Extension Payload with the list included in SDP and SHOULD (according
to policy) if they differ, or if integrity/signature verification
fails, reject the offer. Further description can be found in
[KMASDP].
7.2. MIKEY within SIP 7.2. MIKEY within SIP
In e.g., a basic SIP call (see Figure 7.1.), SIP (Session Initiation In e.g., a basic SIP call (see Figure 7.1.), SIP (Session Initiation
Protocol, [SIP]) is used as a session establishment protocol between Protocol, [SIP]) is used as a session establishment protocol between
two or more parties. In general an offer is made, whereby it is two or more parties. In general an offer is made, whereby it is
either accepted or rejected by the answerer. SIP complies to the either accepted or rejected by the answerer. SIP complies to the
offer/answer model [OFFANS], to which MIKEY over SIP MUST be offer/answer model [OFFANS], to which MIKEY over SIP MUST be
compliant with as well. compliant with as well.
skipping to change at page 44, line 46 skipping to change at page 45, line 15
overall security below 64-bits. On the other hand, protecting a 64- overall security below 64-bits. On the other hand, protecting a 64-
bit symmetric key by a 2048-bit RSA key appears to be an "overkill", bit symmetric key by a 2048-bit RSA key appears to be an "overkill",
leading to unnecessary time delays. Therefore, key size for the key- leading to unnecessary time delays. Therefore, key size for the key-
exchange mechanism SHOULD be weighed against the size of the exchange mechanism SHOULD be weighed against the size of the
exchanged key. We refer to [LV] for concrete key size exchanged key. We refer to [LV] for concrete key size
recommendations. recommendations.
Moreover, if the TGKs are not random, a brute force search may be Moreover, if the TGKs are not random, a brute force search may be
facilitated, again lowering the effective key size. Therefore, care facilitated, again lowering the effective key size. Therefore, care
MUST be taken when designing the (pseudo) random generators for TGK MUST be taken when designing the (pseudo) random generators for TGK
generation. generation, see [FIPS][RAND].
For the selection of the hash function, SHA-1 with 160-bit output is For the selection of the hash function, SHA-1 with 160-bit output is
the default one. In general, hash sizes should be twice the "security the default one. In general, hash sizes should be twice the "security
level", indicating that SHA1-256, [SHA256], should be used for the level", indicating that SHA1-256, [SHA256], should be used for the
default 128-bit level. However, due to the real-time aspects in the default 128-bit level. However, due to the real-time aspects in the
scenarios we are treating, hash size slightly below 256 are scenarios we are treating, hash size slightly below 256 are
acceptable as the normal "existential" collision probabilities would acceptable as the normal "existential" collision probabilities would
be of secondary importance. be of secondary importance. In general, all pre-defined MIKEY
transforms are state-of-the-art with no known weaknesses.
In a Crypto Session Bundle, the Crypto Sessions can share the same In a Crypto Session Bundle, the Crypto Sessions can share the same
TGK as discussed earlier. From a security point of view, the TGK as discussed earlier. From a security point of view, the
criterion to be satisfied is that the encryption of the individual criterion to be satisfied is that the encryption of the individual
Crypto Sessions are performed "independently". In MIKEY this is Crypto Sessions are performed "independently". In MIKEY this is
accomplished by having unique Crypto Session identifiers (see also accomplished by having unique Crypto Session identifiers (see also
Section 4.1). The TEK derivation method assures this by providing Section 4.1) and a TEK derivation method that provides
cryptographically independent TEKs to distinct Crypto Sessions cryptographically independent TEKs to distinct Crypto Sessions
(within the Crypto Session Bundle), regardless of the security (within the Crypto Session Bundle), regardless of the security
protocol used. protocol used.
Specifically, the key derivations are implemented by a pseudo-random Specifically, the key derivations 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). Indeed, as simplicity of design (complexity does not imply security). Indeed, as
shown in [DBJ], if one of the two hashes is severely broken, the TLS shown in [DBJ], if one of the two hashes is severely broken, the TLS
PRF is actually less secure than if a single hash had been used on 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. the whole key, as is done in MIKEY.
In the pre-shared key and public-key schemes, the TGK is generated by In the pre-shared key and public-key schemes, the TGK is generated by
a single party (Initiator). This makes MIKEY more sensitive if the a single party (Initiator). This makes MIKEY somewhat more sensitive
Initiator uses a bad random number generator. It should also be noted if the Initiator uses a bad random number generator. It should also
that neither the pre-shared nor the public-key scheme provides be noted that neither the pre-shared nor the public-key scheme
perfect forward secrecy. If mutual contribution or perfect forward provides perfect forward secrecy. If mutual contribution or perfect
secrecy is desired, the Diffie-Hellman method is to be used. forward secrecy is desired, the Diffie-Hellman method is to be used.
Forward/backward security: if the TGK is exposed, all TEKs generated Forward/backward security: if the TGK is exposed, all TEKs generated
from it are compromised. However, under the assumption that the from it are compromised. However, under the assumption that the
derivation function is a pseudo-random function, disclosure of an derivation function is a pseudo-random function, disclosure of an
individual TEK does not compromise other (previous or later) TEKs individual TEK does not compromise other (previous or later) TEKs
derived from the same TGK. derived from the same TGK.
The use of random nonces (RANDs) in the key derivation is of utmost The use of random nonces (RANDs) in the key derivation is of utmost
importance to counter off-line pre-computation attacks. Note however importance to counter off-line pre-computation attacks. Note however
that update messages re-use the old RAND. This means that the total that update messages re-use the old RAND. This means that the total
skipping to change at page 52, line 8 skipping to change at page 52, line 31
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 [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.
[FIPS] "Security Requirements for Cryptographic Modules", Federal
Information Processing Standard Publications (FIPS PUBS) 140-2,
December 2002.
[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 32 skipping to change at page 53, line 8
[LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for [LV] Lenstra, A. K., and Verheul, E. R., "Suggesting Key Sizes for
Cryptosystems", http://www.cryptosavvy.com/suggestions.htm Cryptosystems", http://www.cryptosavvy.com/suggestions.htm
[NTP] Mills, D., "Network Time Protocol (Version 3) specification, [NTP] Mills, D., "Network Time Protocol (Version 3) specification,
implementation and analysis", RFC 1305, March 1992. implementation and analysis", RFC 1305, March 1992.
[PKCS1] PKCS #1 - RSA Cryptography Standard, [PKCS1] PKCS #1 - RSA Cryptography Standard,
http://www.rsalabs.com/pkcs/pkcs-1/ http://www.rsalabs.com/pkcs/pkcs-1/
[RAND] Eastlake, D., Schiller, J., and Crocker, S., "Randomness
Requirements for Security", Internet Draft, Work in Progress.
[RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining [RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining
Digital Signatures and Public-Key Cryptosystems". Communications of Digital Signatures and Public-Key Cryptosystems". Communications of
the ACM. Vol.21. No.2. pp.120-126. 1978. the ACM. Vol.21. No.2. pp.120-126. 1978.
[SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512", [SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512",
http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf
[TLS] Dierks, T. and Allen, C., "The TLS Protocol - Version 1.0", [TLS] Dierks, T. and Allen, C., "The TLS Protocol - Version 1.0",
IETF, RFC 2246. IETF, RFC 2246.
skipping to change at page 53, line 4 skipping to change at page 53, line 33
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.
This Internet-Draft expires in April 2003. This Internet-Draft expires in August 2003.
 End of changes. 

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