Network Working Group R. Blom INTERNET-DRAFT E. Carrara Expires: December 2001 F. Lindholm J. Arkko Ericsson July, 2001 Design Criteria for Multimedia Session Key Management in Heterogeneous Networks Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract For conversational multimedia to take off, many important aspects have still to be fully investigated. The security framework is one of them. While some proposals on how to secure the media traffic have appeared, a key management solution has still to be developed. It should take into account the conversational multimedia type of scenario and an heterogeneous communication environment, in which thin clients are used. Such a scenario will result in a number of challenging requirements. The purpose of this document is to describe the scenario and to list constraints and requirements on a key management scheme for media traffic in conversational multimedia. Blom, et al. [Page 1] INTERNET-DRAFT mm-kmgt July 2001 TABLE OF CONTENTS 1. Introduction....................................................2 1.1. Outline.......................................................3 1.2. Notational Conventions........................................3 2. Network Architecture............................................3 3. Call control Security...........................................4 4. Security of the Media Session...................................5 5. Basic Requirements..............................................5 5.1. General.......................................................5 5.2. Authentication................................................6 5.3. Key Derivation, Refresh and Re-keying.........................6 5.4. Negotiation and Efficiency....................................7 5.5. Groups .......................................................7 5.6. Denial of Service.............................................8 6. Service Requirements in heterogeneous environment...............9 7. Security Considerations........................................10 8. Conclusions....................................................11 9. Acknowledgments................................................11 10. Authors' addresses............................................11 11. References....................................................12 1. Introduction Conversational multimedia is expected to become big business in the near future. Solutions are on the way, but still, pieces are missing. In particular, security is of concern; no security framework has yet been clearly developed. Some work has been initiated with a security scheme for RTP traffic [SRTP], but many aspects still need to be investigated. One of them is how to make an initial agreement on the security parameters (keys included) needed by the security scheme employed, that is key management. It is of interest here to focus on key management schemes addressing the specific requirements for protection of media traffic. The expected environment is of heterogeneous nature and therefore it is of great importance to consider also wireless aspects. This document contains a discussion about requirements that a key management scheme for secure conversational multimedia has to fulfil. There are indeed existing candidates for a key management solution; however, the conversational multimedia applications and the heterogeneous communications scenario, where thin clients are common, put some special requirements on the solution. These requirements have to be taken into account in the design of an efficient scheme, which should work in a general scenario. Blom, et al. [Page 2] INTERNET-DRAFT mm-kmgt July 2001 1.1. Outline Section 2 describes a simple case, which we use as a reference, and it also lists some possible trust models. Section 3 briefly discusses the security of the call control protocol. Section 4 lists some general requirements, while Section 5 lists more specific requirements for the applications and scenarios that we are dealing with. In Section 6 service requirements are derived and Section 7 describes when and how to run the key management protocol. 1.2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 2. Network Architecture The scenarios we are considering are conversational multimedia sessions. A typical example may be two or more users involved in a "phone call" with both audio and video sessions between them. Here real-time is a must. Moreover, it is necessary to investigate an heterogeneous environment, due to the expected convergence of the cellular networks and the Internet. We emphasize that a solution, which works in a very constrained environment, as e.g. the cellular environment, in general also works in a more relaxed environment. Hence, cellular aspects will be considered from the very beginning in order to end up with a general solution. |A's SIP| <.......> |B's SIP| |Server | SIP |Server | --------- --------- ^ ^ . . ++++ SIP . . SIP ++++ |A | <............. .............> |B | | | | | ++++ <-------------------------------------------> ++++ SRTP Fig 1: SIP-based call example. The two parties uses SIP to setup SRTP streams between A and B. Blom, et al. [Page 3] INTERNET-DRAFT mm-kmgt July 2001 We base our discussion for simplicity on a SIP-based call between two users, where SIP [SIP] is the call control protocol, and the media is protected by SRTP. The basic architecture is shown in Fig 1. Another example may be a streaming application. The SIP proxies may belong to the transport network or may be e.g. standalone ASPs. The security of the media streams may in general be independent of the security used to protect the call control itself. The users are likely to desire end-to-end protection for their media traffic. 3. Call Control Security For simplicity, let us consider the very simple but essential scenario showed in Fig 1. The discussion can easily be extended to other situations. Hence, the example we use has SIP [SIP] as call control protocol. Integrity protection and authentication of SIP messages are regarded as essential functions, while confidentiality is recommended when possible. In general, network or transport security protocols are applicable on a hop-by-hop basis between the involved entities (e.g., IPsec [IPSEC], TLS [TLS]). Pre-existing secure tunnels may be in place between the SIP proxies, hence leading to a transitive chain of trust. The most distinguishing feature shown by a call control protocol like SIP with respect to security is the fact that entities in the path between the endpoints (e.g., SIP proxies) need access to the SIP message to read/modify/add some of its fields. End-to-end (e2e) security (e.g., PGP [PGP]) may therefore be applicable only to limited parts of the SIP messages, e.g. some headers which are not changed by intermediate proxies and possibly the SDP part [SDP], if no nodes in the path need access to them (e.g., Network Address Translators [NAT]). If parts of the call control protocol are e2e protected, it may be possible for them to carry the sensible parameters (e.g., keys) needed by the media traffic security protocol. In this way, untrusted proxies will have no access to such parameters. There are basically two trust models that are applicable: - only the endpoints of the media are trusted. The key management has then a true 'end-to-end' nature. Blom, et al. [Page 4] INTERNET-DRAFT mm-kmgt July 2001 - a third party is trusted, e.g. the KDC in Kerberos [KBRS], or an AAA infrastructure. The end-to-end protection of the media traffic is by necessity broken in case, for example, a transcoder is needed. In this case, the transcoder becomes a legitimate endpoint for the encrypted traffic. The third-party trust model offers more lightweight solutions for the key management, with the obvious drawback of placing trust in a third party. In the following we concentrate on the first trust model. 4. Security of the Media Session It is of interest here how to protect the media session (e.g., RTP traffic [RTP]) following the call set-up phase. Unless by necessity (e.g., the existence of transcoders), only the media endpoints should be recipients of the encrypting/authenticating keys. >> Req 4.1: the key management protocol MUST support e2e protection. Multimedia applications often use broadcast or multicast (e.g., net radio/TV, videoconferences, etc). Therefore, it is also necessary to support multi-party and multicast sessions: >> Req 4.2: the key management solution MUST support multi-party and multicast sessions. 5. Basic Requirements Typically, existing key management protocols handle authentication (including relationships to a trust infrastructure), negotiation of the security protocol and algorithms to be used, generation of session keys, and periodic refresh of the keys. In this section, we list the basic requirements for the key management scheme. 5.1. General The main task of the key management protocol is to securely exchange master keys from which to derive session keys (see Section 5.3.). It should be possible for just one party to generate the session key since adding components from two parties would result in additional round trips. Another case when this is desirable is when an additional user/receiver joins an on-going multicast session. >> Req 5.1: It SHOULD be possible for a single party to generate the master key and transmit it securely to the other party (parties). Blom, et al. [Page 5] INTERNET-DRAFT mm-kmgt July 2001 The scenario we are describing here is intended for very large networks, of the order of today's Public Switched Telephone Network (PSTN) at least. Hence, scalability is a necessity. Scalability also brings the necessity to manage the system and the user's keys in different parts of the world, still enabling connectivity. This will typically mean the need of a PKI infrastructure. >> Req 5.2: the key management scheme MUST be at least scalable to a size close to current PSTN. >> Req 5.3: it MUST be possible to manage the users of the key management scheme under different administrative domains. >> Req 5.4: the key management scheme MUST allow users from different administrative domains to communicate securely. It can be assumed that different security protocols will be used depending on situation. The key management protocol should therefore be able to set up Security Associations (SAs) on behalf of several different security protocols. The alternative is, of course, to implement several key management schemes, if several security protocols are to be used. >> Req 5.5: The key management protocol SHOULD be adaptable to support different security protocols. Terminal mobility must be supported, as well as multi-homed terminals. >> Req 5.6: SAs SHOULD NOT be associated/indexed with IP addresses. 5.2. Authentication Authentication is an important aspect for key management. It is important that the authentication is as efficient as the key exchange. Experiences from web security show that not just mutual authentication, but also unidirectional authentication is useful in certain situations. >> Req 5.7: Both unidirectional and mutual authentication SHOULD be possible. 5.3. Key Derivation, Refresh and Re-keying Typically, a key exchange protocol allows the involved parties to exchange and then share a "master key", or seed, from which "session keys" are derived. Blom, et al. [Page 6] INTERNET-DRAFT mm-kmgt July 2001 Key refresh (deriving a new key from the previous one or from a "seed" in the same session, mainly for security reasons) and re- keying (creating a new master key, commonly used for access control) are fundamental aspects of the key management. Therefore, it must be clearly specified how this must be done. >> Req 5.8: the key management scheme MUST specify how to derive session keys from the master key. >> Req 5.9: the key management scheme MUST specify re-keying mechanisms and policies. >> Req 5.10: the key management scheme MUST specify key refresh mechanisms and policies. 5.4. Negotiation and Efficiency The key management scheme will be used in conjunction with protection of media traffic. The media traffic typically shows strict real-time features and requirements. Hence, various kinds of efficient and tailored protocols/algorithms have to be supported in the Security Association (SA) definition, e.g., SRTP [SRTP]. >> Req 5.11: the key management scheme MUST support a selection of efficient security protocols, algorithms, and parameters. To avoid complexity in the key management protocol, only one single key-exchange algorithm should be mandatory to implement. Thus, this needs to be a widely available algorithm with high confidence in its security, while at the same time, offering acceptable performance also on relatively thin clients. >> Req 5.12: The key management protocol SHOULD have one mandatory- to-implement mode of operation and authentication. Efficient default settings of algorithms and parameters SHOULD be assumed. In case relatively computationally expensive key management schemes are used, optimizations should be performed, e.g., using a key and security parameters that have been used in a previous communications session (key resuming). This has to be done in a way not to leak information. >> Req 5.13: key caching SHOULD be supported, according to specific security policies. 5.5. Groups The way new entities (servers, other callees) join an already existing session has to be as convenient as possible. When a member Blom, et al. [Page 7] INTERNET-DRAFT mm-kmgt July 2001 joins or leaves the group, problems of forward/backward security have to be solved. A natural consequence of the conversational multimedia setting is that the sizes of the groups considered are limited. >> Req 5.14: convenient keying and re-keying mechanisms suitable for small groups MUST be provided. Large scale groups might need additional requirement in order to be able to handle key management in a convenient way (e.g. by centralized key distribution servers). Therefore, large scale groups are not considered here. There is current work in the MSEC WG [MSEC]. 5.6. Denial of Service Denial-of-Service (DoS) resistance is one of the features that a key management scheme has to provide in the type of scenario we are considering. There are various grades of DoS resistance, and their performance implications should be carefully studied. >> Req 5.15: the key management scheme SHOULD NOT create any state (at the key management protocol level) at the responder side until a positive authentication has been performed. Statelessness is typically relatively easy to achieve. However, while it is a necessary condition to prevent DoS attacks, it is not sufficient. Typically, public-key based signature verification is an expensive operation, and attackers may use this to send a flood of fake connection requests. The victim has to verify all signatures, which most likely exhausts available resources and prevents legitimate requests from getting through. There is little that can be done about this. However, the problem becomes worse if any host in the Internet can easily perform such attacks without fear of getting caught. Today, IP source address verification is not generally applied on the Internet, and as a result hosts can often use faked source addresses as to prevent tracing the attack to the correct place. For this reason good protocols typically employ strategies to ensure that the source address of the peer is routable before they devote substantial resources to connection establishment, for instance through requiring the peer to reply to a message containing cookies. >> Req 5.16: the key management scheme SHOULD NOT devote substantial computation resources to peers whose claimed source address has not been verified to be operational. Fulfilling this requirement requires additional roundtrips in the protocol. Since this may not be acceptable in all environments, the above requirement is only a SHOULD NOT. We also note that it may Blom, et al. [Page 8] INTERNET-DRAFT mm-kmgt July 2001 be possible to separate the DoS protection and the key management protocol from each other, or to make the DoS protection a configurable option (as is the case between IKE Main and Aggressive modes). 6. Service Requirements in heterogeneous environment Conversational multimedia is a very strict real-time scenario. The call set-up itself poses quite narrow time constraints for service behavior reasons. Simply said, the user will not use the service if placing a call takes too long. All of this becomes extremely sensitive in cellular environments, where bandwidth, speed and use of thin clients are preeminent factors. >> Req 6.1: the key management scheme MUST fit the time constraints posed by the service behavior requirements Call control protocols, e.g., SIP, are often quite talkative and rich, therefore they require time; moreover, QoS reservation is likely to be used, which adds time consumption. Key management has also to be performed before the media starts: this will add even more time to the complete call set-up. A protocol featured by several round trips is particularly painful in time-constrained scenarios. Hence, it is a necessity to clarify the functions needed by the system and then establish them with as few exchanges as possible. >> Req 6.2: the protocol design MUST strive to reduce the number of round trips as much as possible. In wireless networks, packet size often translates into delays. It is also necessary to minimize excessive use of long messages. This is however not as critical as the number of round trips. >> Req 6.3: the protocol design SHOULD reduce the size of the messages as much as possible. This also means that negotiation of parameters should be minimized, and default setting should be used as much as possible as already stated (Req 5.12). In addition, security operations, and especially public-key operations, require much processing time. This is particularly true in case of thin clients. Therefore, processing time and load should be taken into account when designing a scheme. >> Req 6.4: the protocol SHOULD reduce the number of expensive cryptographic operations as much as possible. Blom, et al. [Page 9] INTERNET-DRAFT mm-kmgt July 2001 Schemes involving Diffie-Hellman are in general the most "secure", however they are also computationally expensive. Lighter schemes may be designed, e.g. when the session key is generated as a random number by one of the parties. A high number of round trips and expensive cryptographic operations in a key management protocol are generally motivated by the requirements of achieving a very high level of security and providing several functions in one protocol. An example is IKE, which can achieve Perfect Forward Secrecy (PFS) at the expense of a second (heavy) Diffie-Hellman exchange. However, providing certain functions may not be necessary in every situation. PFS is an example of function to be provided only in case it is necessary. Hence, an analysis of the necessary security functions required by the context should be performed to avoid unnecessary load to the key management. >> Req 6.5: in the protocol, only the minimal set of necessary functions SHOULD be mandatory to implement. Typically, security protocols become complex through the introduction of various alternative schemes with varying properties. In an environment with lightweight end-user equipment, it becomes necessary to find a basic scheme due to complexity and interoperability reasons. 7. Security Considerations Though perhaps needless to say, we stress that the key management scheme to be employed MUST be designed according to protocol and cryptographic strong security criteria. >> Req 7.1: the key management protocol MUST be secure. No chain is stronger than its weakest link. For instance, with current state of the art [LV], protecting a 128-bit AES key by a 512- bit RSA [RSA] key offers an overall security well below 64-bits. On the other hand, protecting a 64-bit symmetric key by a 2048-bit RSA key appears to be an overkill, leading to unnecessary time delays. Therefore, key size for the key-exchange mechanism MUST be weighed against the size of the exchanged key. >> Req 7.2: The cryptographic functions protecting keys during exchange and transport MUST be configurable to offer a security at least corresponding to the (symmetric) keys they protect. Moreover, if the session keys are not random, a brute force search may be facilitated, again lowering the effective key size. Therefore, care MUST be taken when designing the (pseudo) random generators for master key generation. The same applies to re-keying and key-refresh mechanisms. Policies for key-refresh rates MUST be set so as to avoid Blom, et al. [Page 10] INTERNET-DRAFT mm-kmgt July 2001 keystream re-use (for stream-ciphers) and to avoid "non-random" behavior (e.g. for block-ciphers in feedback-type mode). >> Req 7.3: good (pseudo) random generators MUST be employed. DoS is of particular concern. The requirements stated in Section 5.6. are highly recommended. However, there may be for example a tradeoff between time saving and better DoS protection. In those cases, if efficiency is the choice, there must be awareness that a way to possible DoS attacks may be opened. 8. Conclusions Key management is a crucial part in a security solution. The present document has showed that the conversational multimedia scenario, especially in heterogeneous environment, poses strict requirements to be fulfilled. Among them, service behavior time restrictions seem to be a prioritized requirement. 9. Acknowledgments The authors would like to thank Mats Naslund, Magnus Westerlund, Karl Norrman, Pasi Ahonen, and Ilkka Uusitalo for their reviews and comments. 10. Author's Addresses Rolf Blom Ericsson Research SE-16480 Stockholm Phone: +46 8 58531707 Sweden EMail: rolf.blom@era.ericsson.se Elisabetta Carrara Ericsson Research SE-16480 Stockholm Phone: +46 8 50877040 Sweden EMail: elisabetta.carrara@era.ericsson.se Fredrik Lindholm Ericsson Research SE-16480 Stockholm Phone: +46 8 58531705 Sweden EMail: fredrik.lindholm@era.ericsson.se Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Phone: +358 40 5079256 Finland Email: jari.arkko@ericsson.com Blom, et al. [Page 11] INTERNET-DRAFT mm-kmgt July 2001 11. References [AES] Advanced Encryption Standard, www.nist.gov/aes [HAC] Menezes, van Oorshot, and Vanstone, "Handbook of Applied Cryptograhpy", CRC press 1997. [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", IETF, RFC 2409. [IPSEC] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406,and "IP Authentication Header", RFC 2402, November 1998. [KBRS] Kohl, J., and Neuman, C., "The Kerberos Network Authentication Service (V5)", IETF, RFC 1510. [LV] Lenstra, A. K. and Verheul, E. R., "Suggesting Key Sizes for Cryptosystems", http://www.cryptosavvy.com/suggestions.htm [MSEC] Baugher, M., Hardjono, T., Harney, H., Weis, B., "The Group Domain of Interpretation", Internet Draft, February 2001, and Harney, H., Colegrove, A., Harder, E., Meth, U., Fleischer, R., "Group Secure Association Key Management Protocol", Internet Draft, March 2001. [NAT] Srisuresh, P. and Egevang, K., "Traditional IP Network Address Translator (Traditional NAT)", IETF, RFC 3022, January 2001. [PGP] Atkins, D., Stallings, W., and Zimmermann, P., "PGP message exchange format", IETF, RFC 1991, August 1996. [RSA] Rivest, R., Shamir, A., and Adleman, L. "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems". Communications of the ACM. Vol.21. No.2. pp.120-126. 1978. [RTP] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", IETF, RFC 1889. [SDP] Handley, M. and Jacobson, V., "Session Description Protocol (SDP)", IETF, RFC 2327. [SIP] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., "SIP: Session Initiation Protocol", IETF, RFC2543. [SRTP] Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K., and Oran, D., "The Secure Real Time Transport Protocol (SRTP), Internet Draft, February 2001. Blom, et al. [Page 12] INTERNET-DRAFT mm-kmgt July 2001 [TLS] Dierks, T. and Allen, C., "The TLS Protocol Version 1.0", IETF, RFC 2246. This Internet-Draft expires in December 2001. Blom, et al. [Page 13]