MMUSIC Working Group Internet Draft M. Saito draft-saito-mmusic-ipsec-negotiation-req-02 NTT Communications Expires: September 2006 S. Fujimoto Fujitsu Labs March 2006 Requirements for IPsec Negotiation in the SIP Framework Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract As the Internet grows, it becomes inevitable even for the general users to take measures against the security risks such as tapping, unauthorized access, and so on. For example, we can consider the use case of networked home appliances which cannot have the rich calculation resources and may use the dedicated transport protocol for the media session. In such a case, it is effective to connect such devices securely using IPsec [1] because it does not require the rich resources, and is independent of the upper layer protocol. Also from the viewpoint of implementation, IPsec is not only widespread in IPv4, but also mandatory in IPv6 which is expected in the networked home appliances region(this use case is just the one of examples, and this document does not focus only on home appliances but also on the general applications which use the dedicated media protocols, where IPsec is suitable as the security protocol). Saito & Fujimoto Expires - September 2006 [Page 1] Requirements for IPsec Negotiation in SIP March 2006 However, it is necessary to set up a lot of option parameters properly in order to establish the IPsec connection. And it requires the technical knowledge even if using IKE, which does it automatically. At least, IKE is not so simple that the general users who do not know the security well can handle. By the way, SIP [2] mechanism, which has a function of flexible negotiation, enables the different applications to connect to each other easily by negotiating the codec, frame rate, and so on. On the other hand, we found out the similarity between IPsec configuration and parameter configuration for media session, and we thought to negotiate the parameters for IPsec easily with using SIP. Particularly, if the application itself supports SIP by nature, there should be more merits. In this document, we provide some use cases of IPsec communication systems. Then we explain what kind of IPsec parameters should be negotiated on SIP. Note that we assumed that the system users are end-users who are not familiar with IPsec. This document also offers the candidate methods to realize it, including the existing specs, and which one we should take among them. Conventions used in this document 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 [3]. Table of Contents 1. Introduction and Problem Statement............................3 2. Application Scenarios.........................................4 3. Requirements for Security Method..............................5 3.1. Requirements for Security Protocol.......................6 3.2. Reduction of Implementation..............................6 3.3. Interoperability of Security Protocol....................7 3.4. Generalized Security Protocol............................7 4. Protocol Requirements for IPsec...............................7 4.1. Requirements for Key-Exchange............................7 4.2. Synchronization of Key-Exchange and Media Negotiation....8 4.3. Interoperability.........................................8 4.4. Shared Security Policy between Media Sessions............8 5. Possible Solutions............................................9 5.1. Evaluation of Existing Specifications....................9 5.2. Idea of Solution Using SDP..............................10 5.3. Generic Use.............................................10 6. Conclusions..................................................10 7. Security Considerations......................................11 Saito & Fujimoto Expires - September 2006 [Page 2] Requirements for IPsec Negotiation in SIP March 2006 8. Changes since draft-saito-mmusic-ipsec-negotiation-req-01....11 1. Introduction and Problem Statement Various applications which use different protocols are increasing now, so that the security of them is also required more and more. On the other hand, SIP is considered as the de facto standard to invoke the application sessions. We can use it for not only VoIP applications but also general applications now. And the general users, in other words, the people who do not have sufficient knowledge about security, began to want the secure and easy communication tools. On the other hand, the sessions invoked by SIP applications also need security features, such as end-to-end authentication and/or encryption. In fact, several security methods have already been offered. For example, there are key exchange frameworks in order to encrypt the media session, such as MIKEY [4], Key Management Extensions for SDP and RTSP [5], SDP Security Descriptions [6], and so on. However so far, these frameworks mainly support the specific use such as SRTP for VoIP sessions although it may be applicable to general protocols. The usage for the other protocols hasn't been defined yet. However, considering the general applications, the dedicated protocol is often used even if it is not sufficiently protected. In such a case, SRTP cannot be used for the security protocol because it is strongly combined with VoIP applications. On the other hand, there is a quick choice to use IPsec that is independent of media and applications. IPsec is recognized as the standard security protocol of the IP layer, and has sufficient interoperability. On the other hand, as shown in IKE, IPsec has a practical issue that the configuration of its option parameters is so complicated. It often prevents the applications from making use of IPsec. But the most applications only want to use IPsec with ease, and they would not require more than the recommended sets of parameters which are believed to be sufficiently secure (Some devices can not support a lot because of the resource restriction). In fact, the combination of parameter sets which are secure and do not have a problem in interoperability are limited, therefore we thought it would be sufficient to choose one of them simply. Besides, it makes sense to make use of SIP and an offer/answer model with the SDP [7] in order to resolve the name, authenticate, and decide the media session when the devices start the communication. And more, if we negotiated even the IPsec parameters inside this mechanism, the problem could be reduced compared with negotiating them after the start of media session. Actually, if doing it after the start of media session, the first data of UDP based media would be lost. Saito & Fujimoto Expires - September 2006 [Page 3] Requirements for IPsec Negotiation in SIP March 2006 Therefore in this document, we describe the issues on applying IPsec to the application sessions invoked by SIP, and we also describe the requirements to solve them. 2. Application Scenarios We assume the end-to-end media communication invoked by SIP for the use case, particularly the following patterns which the standard protocols are not necessarily used for the media session. o Dedicated media protocol which can control or manage the home network devices from the outside (Figure 1). +----------+ REGISTRATION | SIP | REGISTRATION +---------->| Proxy |<-------------+ | +------->| |-----------+ | | |INVITE +----------+ +-------|--+------+ | | | Home | | | | | | Net. V | | +----------+ | +-----------+ | | User A's | | | User A's | | | Terminal |=========================| Device | | | | Session over IPsec | | (Sensor) | | +----------+ | +-----------+ | +-----------------+ Figure 1: Network Structure in Remote Device Control Scenario o Tunneling protocol such as L2TP which can transmit the various media such as file sharing, video stream, and so on (Figure 2). +----------+ REGISTRATION | SIP | REGISTRATION +---------->| Proxy |<-------------+ | +------->| |-----------+ | | |INVITE +----------+ | | | | | | | | V | +----------+ L2TP with IPsec +-----------+ | User A's |-------------------------| User B's | | Terminal |======Media Sessions=====| Terminal | | |-------------------------| | +----------+ +-----------+ Figure 2: Network Structure in Tunneling Protocol Scenario Saito & Fujimoto Expires - September 2006 [Page 4] Requirements for IPsec Negotiation in SIP March 2006 In addition, we assume the following conditions when we use SIP in these scenarios. o Signaling Path via the SIP Proxies Each UA retains the SIP signaling path with its own outbound proxy, and the media session between UAs is negotiated with the exchange of the SIP messages via the SIP proxies. o Root of Trust Each UA trusts the common entity. It may be the trusted 3rd party such as CA in the PKI system, or the private CA. Or SIP proxy may play such a role. The formation of Root of Trust is outside the scope of this document, but the trust between each UA and Root of Trust MUST be deployed easily to the direct trust between UAs with the exchange of SIP messages. By the way, Root of Trust is trusted by each UA in the following points. Authentication between UAs Authorization of Media Communication between UAs Integrity of the Data Exchanged between UAs Confidentiality of the Data Exchanged between UAs Following above conditions, it can be also said that each UA has some method to exchange the SIP message or SDP included in it securely between them. o Network Topology End-to-End media session is often influenced by the firewall/NAT on the direct path between UAs. It is inevitable to think of the existence of such middle boxes, but this issue has been discussed a lot in the existing SIP framework. And for the simplicity, we decide that this issue is outside the scope, although recognizing it. It is our goal to make the end-to-end media protocol secure easily under the above conditions. In order to achieve that, we also need the protocol-independent security method because the media protocol is not always the standard one. 3. Requirements for Security Method In the above scenarios, we can point the several factors necessary for the security of the media. Particularly, we focus on the following factors in this document. Saito & Fujimoto Expires - September 2006 [Page 5] Requirements for IPsec Negotiation in SIP March 2006 3.1. Requirements for Security Protocol The security protocol for the media MUST support the following functions. o Authentication of the Peer All the SIP nodes which initiate the media sessions between them MUST be able to authenticate each other with the help of Root of Trust. That is, impersonation by the malicious node will be eliminated. And, the media session itself MUST be also authenticated based on this authenticator. In other words, this is the function assuring that the peer of the media session and the peer of the SIP negotiation have the same identity. o Integrity of the Media Data The integrity of all the media data MUST be assured. It prevents the malicious person from tampering the media data between the legitimate nodes. o Confidentiality of the Media Data The contents of the media data SHOULD be hidden from the un- trusted nodes. Therefore, the encryption of the media will be required. o Access Control The access from the nodes other than legitimate one MUST be blocked. One of the approaches would be the mechanism to generate the proper security associations covering the media between the legitimate nodes, and discard the access which does not coincide with them based on the node's security policy. o Update of Secret Keys The secret keys used for authentication or encryption SHOULD be updated periodically. Even if the peers are properly authenticated and the end-to-end session between them is encrypted, there still remains the risk that the attacker may try all possible keys, that is to say, "brute force attack". This requirement also includes the generic functions supported by the generic key-exchange process, such as derivation of the key, negotiation of SAs, choice of the cipher algorithm and so on. 3.2. Reduction of Implementation Saito & Fujimoto Expires - September 2006 [Page 6] Requirements for IPsec Negotiation in SIP March 2006 Thinking of the use cases such as networked home appliances, the security method SHOULD be light-weighted (or implementation cost SHOULD be reduced) because devices do not always have the rich memory or CPU resources. Generally speaking, the process of authentication and encryption for the first time before the media session starts, that is key-exchange process, tends to be heavy. But there is an assumption that SIP or SDP messages can be transmitted securely, therefore it is expected to reduce the load of key-exchange process by synchronizing them. 3.3. Interoperability of Security Protocol The interoperability of the security protocol used for the end- to-end media session is also the important factor. Therefore, it is desirable to use the protocol which is standard and has been used practically and sufficiently, and proved to be relatively interoperable. 3.4. Generalized Security Protocol The choice of the transport protocols used for the end-to-end media session between terminals is not limited. It will depend on the upper layer applications. If we have to provide the different security protocols for each media transport protocol, it means the waste of resources. Therefore, we think it desirable to use the standard, all- purpose security protocol for the IP applications such as IPsec. 4. Protocol Requirements for IPsec Considering the above requirements, we thought it proper to use IPsec, which does not require the rich memory and CPU resources and is recognized as the standard security protocol. In this section, we describe the protocol requirements when applying IPsec to the media session invoked by SIP. 4.1. Requirements for Key-Exchange IPsec is designed to fill the most of the requirements with security functions such as, access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. The behavior of IPsec is controlled based on SAs (Security Associations). By the way, the above security functions of IPsec are controlled by pre-defined SAs: Security Associations. Therefore, it is necessary to negotiate SAs prior to starting the actual media sessions. For example, the following SA parameters MUST be shared between the nodes. Saito & Fujimoto Expires - September 2006 [Page 7] Requirements for IPsec Negotiation in SIP March 2006 o SPI (Security Parameter Index: ID for SA) o IPsec Mode (tunnel mode or transport mode) o Lifetime of SA o Encryption Algorithm (in case of ESP) o Authentication Algorithm o Compression Algorithm in IPComp o A Pair of IP Addresses That IPsec Applied In addition, it is necessary to share and update the secret key for encryption between the nodes. This is one of the requirements for security protocol described in 3.1. To achieve it, the following parameters will be necessary. o Master Key Data: Given to PRF o PRF (Pseudo-Random Function): Session keys will be derived from Master Key with PRF o Key Rounds State of PRF According to the specification of IPsec [10][11], Sequence Number field (32 bits) is used for cryptographic calculation. Therefore, the secret key SHOULD be updated before 2^32 packets are sent. 4.2. Synchronization of Key-Exchange and Media Negotiation For saving the bandwidth and the implementation, the IPsec-SA SHOULD be negotiated in the minimum roundtrips (hopefully one roundtrip synchronized with the offer-answer model of SDP negotiation [7]). 4.3. Interoperability In order to gain the interoperability of IPsec, The parameter sets (such as the mode of security, the set of supporting cipher algorithms, and so on) SHOULD be pre-defined, and at least one SHOULD be chosen as mandatory to implement. 4.4. Shared Security Policy between Media Sessions For the simplicity, it is preferable to be able to share IPsec SAs between media sessions invoked by the single INVITE request. In order to share the SA information across the plural media, IPsec parameters MUST be defined independently of the media. In other words, it is the mechanism that makes a pair of SAs protect the plural media sessions. Saito & Fujimoto Expires - September 2006 [Page 8] Requirements for IPsec Negotiation in SIP March 2006 5. Possible Solutions In this section, we describe the possible solutions for our application models including the existing specifications. 5.1. Evaluation of Existing Specifications There are the following existing specifications which can be used for negotiating the IPsec SA parameters. o IKE (v1/v2) IKE [12] is one of the widespread standard specifications of IPsec key-exchange. However, since it includes a lot of available functions, the implementation is not light and the interoperability is not always fine. On the other hand, it is efficient to exchange the key for the media session in the SDP simultaneously with the media negotiation. o Key-Exchange Using Kerberos (KINK) There is a light-weighted key exchange mechanism, KINK [13]. In this mechanism, the traffic and the calculation cost can be reduced with using the secure key-distribution server. On the other hand, it is too large a task to build and operate the Kerberos system in addition to the SIP platform. And it is difficult to make the new framework of assuring the end-to-end connectivity of KINK, and binding KINK and the media sessions of SDP. o Key-Exchange Using SDP The frameworks such as MIKEY [4] and Key Management Extensions [5], or SDP Security Descriptions [6] are offered. If there is the assumption that SDP is securely protected (particularly Security Descriptions is designed on this case), the key exchange can be fairly simple. On the other hand, the present specification of Security Descriptions only defines the profiles for SRTP. Therefore it is necessary to modify the specification or add the profiles in order to express the SA information such as "Media-Protocol over IPsec" and so on. In addition, there may be a case that the port number of SA becomes different from that of the media transport by applying the tunneling, i.e. UDP encapsulation of IPsec, etc. Therefore it will be necessary to think the mechanism to support such a situation. By the way, as for the update of the encryption keys, we think there are following possible methods. Saito & Fujimoto Expires - September 2006 [Page 9] Requirements for IPsec Negotiation in SIP March 2006 o Method-1: re-INVITE o Method-2: Key Derivation at the Pre-defined Timing If the update of the secret key seldom occurs since the most sessions finish before it, it may be suitable to use Method-1. However, it generally costs to use SIP signaling channel, and the nodes must take care of synchronization with the media sessions. In contrast, Method-2 is useful if the key-update is frequently occurred. The SPI and "session" key will be updated when certain amount of IP packets are sent. But Sequence Number is usually managed by IP layer, and it might be difficult to check its value from application layer. 5.2. Idea of Solution Using SDP It is thought that the approach using SDP is most effective in the use case of this document. In addition, we think there are following possible approaches which reduce the implementation cost and increase the interoperability. o Defining the sets of SA parameter suites which are frequently chosen in order to increase the simplicity. o Binding IPsec parameters not only with the media (media level of SDP) but also with the session (session level of SDP) in order to share a pair of IPsec SAs between plural media sessions. In addition, like the use case of this document, the tunneling protocol such as L2TP can be also thought as a kind of media. Therefore, the mechanism to negotiate the concept of VPN in the offer-answer model of SDP negotiation is also convenient. 5.3. Generic Use At the same time, in order to share the single IPsec SA between multiple media which invoked by single INVITE request, it SHOULD be possible to bind IPsec parameters with the session (session level of SDP), not only with the media (media level of SDP). 6. Conclusions We evaluated the existing protocols, but there was no protocol which met our requirements completely. The closest candidates were key-mgt and the SDP Security Descriptions I-D. However the former needs the new format for IPsec key exchange, and the latter requires the Saito & Fujimoto Expires - September 2006 [Page 10] Requirements for IPsec Negotiation in SIP March 2006 additional definition of transport specific parameters and the standard format to express the IPsec SA information. Therefore we want to build a new specification to negotiate IPsec-SA parameters based on offer-answer model of SDP with reflecting the feedbacks from IETF community. That will specify the call-sequences of IPsec-SA negotiation and define the required data formats including IPsec-SA suites. 7. Security Considerations This document focuses on the key-exchange process of IPsec, but from the viewpoint of security, the following features must be considered, too. o Formation of Root of Trust There is another issue how a trusted entity assumed in this document can be retained in order to ease the end-to-end security. At least the disclosure of data by way of Root of Trust must be avoided. CA in PKI architecture is one of the candidates, but thinking of the use case of home appliances, it may not be necessarily the best way to distribute the certificates to all the devices in the home network from the outside. On the other hand, the trust relationship between the device and SIP proxy may be used as Root of Trust, or the private CA which is valid only within the home network may be introduced. In anyway, it is necessary to build up the model of Root of Trust adapted to the use cases. Because Root of Trust can be a man-in-the-middle potentially, it is an essential factor in the total security architecture. o SA Management Related to Applications IPsec is a per-host basis security protocol. Therefore we need the mechanism that the application can invoke IPsec SAs, and that manages all IPsec SAs not to conflict with each other. For example, when plural applications generate the IPsec SAs which have the different security levels respectively, the application data must be transmitted by the IPsec SAs which are generated by the same application. Therefore it will require the SA management mechanism related to applications. 8. Changes since draft-saito-mmusic-ipsec-negotiation-req-01 o Application scenarios section was revised so that IPsec was applied to more general use cases including L2TP. Saito & Fujimoto Expires - September 2006 [Page 11] Requirements for IPsec Negotiation in SIP March 2006 o Clarified the concept of Root of Trust, and made the model of it outside the scope. o Requirements sections were revised from the viewpoint of security methods and IPsec itself. o Minor grammatical edits. References 1 Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 2 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 4 J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. 5 J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", work in progress, June 2005. 6 Andreasen, F., Baugher, M., Wing, D., "Session Description Protocol Security Descriptions for Media Streams", work in progress, September 2005. 7 Rosenberg, J., and Schulzrinne, H., "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. 10 Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. 11 Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. 12 Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. 13 Sakane, S., Kamada, K., M. Thomas and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", draft-ietf-kink-kink-11, work in progress, December 2005. Saito & Fujimoto Expires - September 2006 [Page 12] Requirements for IPsec Negotiation in SIP March 2006 Acknowledgements The concepts of this document were discussed in the UOPF: Ubiquitous Open Platform Forum (http://www.uopf.org/en/), which is participated by many ISPs and information appliances makers and so on. The authors would like to thank the UOPF members and those who contributed to this document. Author's Addresses Makoto Saito NTT Communications 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421 Japan Phone: +81-3-6800-3262 Email: ma.saito@nttv6.jp Shingo Fujimoto Fujitsu Laboratories LTD. 64 Nishiwaki, Ohkubo-cho Akashi 674-8555 Japan Phone: +81-78-934-8248 Email: shingo_fujimoto@jp.fujitsu.com Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Saito & Fujimoto Expires - September 2006 [Page 13] Requirements for IPsec Negotiation in SIP March 2006 Copyright Notice Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Saito & Fujimoto Expires - September 2006 [Page 14]