MMUSIC Working Group Internet Draft M. Saito draft-saito-mmusic-ipsec-negotiation-req-00 NTT Communications Expires: January 2006 S. Fujimoto Fujitsu Labs July 2005 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 It is effective to connect the networked home appliances securely using IPsec [1]. Generally, such devices cannot have the rich calculation resources, and may use the dedicated transport protocol for the media session. The advantages of IPsec are that it doesn't require the rich resources, and is independent of the upper layer protocol. In other words, it is applicable to the various applications. On the other hand, same as the typical usage of IPsec, these network devices should be connected to each other only when they need. Therefore it is desired they can generate the IPsec connections dynamically. Considering above, it makes sense to take advantage of SIP [2] mechanism to build such framework. Saito & Fujimoto Expires - January 2006 [Page 1] Requirements for IPsec Negotiation in SIP July 2005 This document describes the issues in applying IPsec dynamically to the media session of the SIP application, and defines the necessary requirements in order to solve 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............................2 2. Application Scenarios.........................................3 2.1. Remote Control...........................................4 2.2. Visual Communication.....................................5 3. System Requirements...........................................6 3.1. Security.................................................6 3.2. Impact on Implementation and Users.......................7 3.3. Connectivity.............................................7 3.4. Generic Use..............................................8 4. Protocol Requirements.........................................8 4.1. Security.................................................8 4.2. Impact on Implementation and Users.......................9 4.3. Connectivity.............................................9 4.4. IPsec for Generic Use...................................10 5. Possible Solutions...........................................10 5.1. Security................................................10 5.2. Impact on Implementation and Users, and Connectivity....12 5.3. Generic Use.............................................12 6. Conclusions..................................................12 7. Security Considerations......................................12 1. Introduction and Problem Statement 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. Based on this situation, we are proposing the concept of M2M: Machine-to-Machine Communication. It is the method that networked home appliances can access to each other using SIP through the network easily. But M2M Communication requires the security function against the risk of tapping and so on. 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 Saito & Fujimoto Expires - January 2006 [Page 2] Requirements for IPsec Negotiation in SIP July 2005 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. Networked home appliances may use the dedicated protocol, which may include the concept of DRM: Digital Rights Management. And when they try to initiate M2M communication with each other, SRTP cannot be used for the security protocol because it is strongly combined with VoIP applications. On the other hand, there is a 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. However there are the following issues on applying IPsec to the general M2M Communications. o Lack of Synchronization with Application IPsec is a per-host basis security protocol. And its SP (Security Policy) has no concern with the term of the session in the application level. In other words, it lacks the mechanism of setting SP and IPsec SAs (Security Associations) before the media session begins and deleting them immediately after the media session finishes. Without this mechanism, the media session can be attacked depending on the timing. o Negotiation of IPsec SA Parameters Appropriate to the Media There are various options in IPsec. Therefore the negotiation of them is necessary in order to establish the IPsec SAs. In addition, these parameters must be selected properly so that the IPsec SAs can protect the media session. In fact there is no standard negotiation method being aware of the media, and it is one of the obstacles in taking advantage of IPsec. By the way, in the case the device invokes M2M Communication with its peer, it is reasonable to make use of SIP and the offer/answer model of SDP [7] in order to resolve the name of the peer or decide the media. From the above point of view, we think it difficult to solve the above IPsec issues independently of SIP and SDP frameworks. 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 following conditions on our model scenarios. Saito & Fujimoto Expires - January 2006 [Page 3] Requirements for IPsec Negotiation in SIP July 2005 o Trusted 3rd Party (CM: Communication Manager) To simplify the mutual authentication between devices, we have the special SIP proxy server, which we call "CM (Communication Manager)". It works as both REGISTRAR and Trusted 3rd Party. The signaling channel between CM and the device is protected by IPsec. And they are authenticated by each other using Pre-Shared Key and so on. Therefore, all the contents of all the SIP messages are protected in that communication path. And as the trusted 3rd party, CM assures the authentication between devices instead of them. o Mutual Trust between DOMAIN CMs Each CM has the DOMAINs, which is the group of users who can be authenticated by that CM. All CMs have the strong mutual trust based on the contract, and the communication path between them is sufficiently secure. o Key Exchange through the Signaling Channel Each device will not have any pre-shared secrets to establish the end-to-end secure communication in advance. These secrets should be retrieved using the in-direct secure signaling channel provided by CM. By the way, SIP messages are transmitted only via CMs which have the relationships of trust as described above. Under the above conditions, we built two model scenarios for examples. 2.1. Remote Control Let us think about the automated home security system. The user wants to communicate with the devices in his house, such as a door lock, the monitor cameras, and so on over the Internet. In this scenario, the user can control these security devices, using the control terminal, from outside of his house. Both the control terminal and the security devices REGISTER to the CM with which the user has the contract, therefore they can call each other with the SIP message. However, there is no limitation in the choice of the media between them. In other words, the arbitrary protocols could be used for the media session. In fact, they totally depend on the application. By the way, although the control terminal and the security devices are authenticated by the CM using pre-shared key, each peer (a pair of the terminal and the device) cannot authenticate each other directly. Figure 1 shows the network structure in this scenario. Saito & Fujimoto Expires - January 2006 [Page 4] Requirements for IPsec Negotiation in SIP July 2005 +----------+ REGISTER | | REGISTER +---------->| CM |<-------------+ | +------->| |-----------+ | | |INVITE +----------+ INVITE | | | | +-------|--|------+ | | | Home | | | +----------+ | Net. V | | | User A's | | +-----------+ | | Terminal |=========================| User A's | | | | Session over IPsec | | Security | | +----------+ | | Device | | | +-----------+ | +-----------------+ Figure 1: Network Structure in Remote Control Scenario 2.2. Visual Communication The next scenario is the visual communication a.k.a. the video chat, between the users who are friends. In this scenario, two users may be inside their houses respectively with their terminals, and each terminal is connected to the Internet directly, or via the home router. Each terminal REGISTERs to the "domain CM" which each user belongs to. Each terminal can be mutually called through the secure path for the SIP communication. The media exchanged by them may be mainly voice and video, but there is no limitation in the choice. Therefore the arbitrary protocols could be used for the media session although it is mainly RTP (they totally depend on the application.) Each terminal can authenticate its domain CM mutually, but each peer (a pair of terminals) does not share any secrets in advance. Note that all the domain CMs are connected to each other securely. Their relationships are guaranteed out-of-bounds, i.e. by the agreement between ISPs. Figure 2 shows the network structure in this scenario. Saito & Fujimoto Expires - January 2006 [Page 5] Requirements for IPsec Negotiation in SIP July 2005 Mutual Trust +============+ | | V V REGISTER +-------+ +-------+ REGISTER +------------>| CM | | CM |<---------+ | +--------->| +--->+ |--------+ | | | INVITE +-------+ +-------+ INVITE | | +----|--|-------+ +-----V-|-------+ | +----------+ | | +----------+ | | | User A's | | | | User B's | | | | Terminal |================================| Terminal | | | +----------+ | Session over IPsec | +----------+ | | User A's | | User B's | | Home Network | | Home Network | +---------------+ +---------------+ Figure 2: Network Structure in Visual Communication Scenario 3. System Requirements In the above scenarios, we can point the several factors necessary for the system. Particularly, we focus on the following factors in this document. 3.1. Security It is important to assure the security both in the remote control and in the visual communication. As for the security, we think the following requirements. o Authentication of the Peer All the SIP nodes MUST be authenticated by each other before they start the end-to-end session. They have to eliminate the attackers who pretend to be the legitimate node. o Integrity of the Data The integrity of all the session data MUST be assured. It prevents the malicious person from tampering the media data directly exchanged between the legitimate nodes. o Confidentiality of the Data The contents of the session data SHOULD be hidden from the un- trusted nodes. Therefore, the encryption of the session data will be required. Saito & Fujimoto Expires - January 2006 [Page 6] Requirements for IPsec Negotiation in SIP July 2005 o Access Control The access from the un-desired person such as a spammer SHOULD be blocked. The function of access control mainly means the simple packet filtering here. But in addition, we also think it effective to hide the existence of the own node from the un- desired people. Even the disclosure of SIP-URI or IP address of the own node may raise the potential risk of DoS attacks. However, we decided this problem is out of scope, since we should solve it within the whole framework of SIP including location services. 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. Impact on Implementation and Users o Reduction of Resources The implementation cost SHOULD be reduced while keeping the system security high. As shown in the scenario of the remote control, some devices used for M2M access do not have the rich resources. We think it is important reducing the functions to implement. In addition, the calculation load of each function should be low. o Actions of Users or Implementers From the user's point of view, the input from the user is RECOMMENDED to be minimum. And from the implementer's point of view, the protocol based on the readable text is RECOMMENDED because it is easy to debug. 3.3. Connectivity o Connectivity Issues Caused by the Network Environment All the above scenarios have the connectivity issues that depend on the network environment. In particular, NATs and Firewalls often block the end-to-end communication. In order to get those Saito & Fujimoto Expires - January 2006 [Page 7] Requirements for IPsec Negotiation in SIP July 2005 over, each node may need to negotiate the various parameters related to the environment or use the other services such as STUN [8] and TURN [9]. o Interoperability of the Protocol The interoperability of the protocol used for the end-to-end session is also the important factor. o Scalability It may be necessary to think the scalability of CM, for example, the sustainable number of signaling channels between the terminals and CM. But we assume the SIP signaling channel is stably established between the nodes and CMs because it has been already discussed a lot about the scalability in the existing SIP framework. 3.4. Generic Use The choice of the transport protocols used for the end-to-end 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 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 Considering the above requirements, we thought it proper to use IPsec, which does not require the rich 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. Security 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 M2M media sessions. For example, the following SA parameters MUST be shared between the nodes. Saito & Fujimoto Expires - January 2006 [Page 8] Requirements for IPsec Negotiation in SIP July 2005 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 between the nodes. This is one of the system requirements described in 3.1. To achieve it, the following parameters will be necessary. o Secret Data: Given to PRF o PRF (Pseudo-Random Function): Session keys will be derived from "Master" secret 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. Impact on Implementation and Users For saving the bandwidth and the user interaction, the mechanism that makes the IPsec-SA negotiation settled easily SHOULD be introduced, and the roundtrip for the negotiation SHOULD be minimum (hopefully one roundtrip). It SHOULD fit the offer-answer model of SDP negotiation [7], which will reduce the interaction between the nodes. 4.3. Connectivity o Connectivity Issues Caused by the Network Environment The network environment such as NAT/FW influences the IPsec communication as well as other protocols. However since this issue is not specific to IPsec, we decided that this issue is outside of the scope, although recognizing the issue. o Interoperability of the Protocol Saito & Fujimoto Expires - January 2006 [Page 9] Requirements for IPsec Negotiation in SIP July 2005 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. o Scalability We assumed the scalability of CM is kept as described in 3.3. However, if we choose the solution that the CM manages all the state of IPsec connections and secret keys for the media sessions, we must consider the processing load and the data capacity of the CM to host the reasonable number of nodes. 4.4. IPsec for Generic Use From the viewpoint of network management, 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 multiple media, IPsec parameters MUST be defined independently of the media. 5. Possible Solutions In this section, we describe the possible solutions for our application models including the existing specifications. 5.1. Security There are the following existing specifications which can be used for negotiating the IPsec SA parameters. o IKE 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 Saito & Fujimoto Expires - January 2006 [Page 10] Requirements for IPsec Negotiation in SIP July 2005 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] are offered. In these mechanisms, the key information MUST be encrypted in the SDP. Therefore it is necessary for the nodes to do the cipher calculation based on the public-key method or pre-shared key method for the key-exchange. In other words, the key-exchange protocol itself is tunneled over SDP. This condition makes the implementation large, and it is difficult to distribute the certificates to all the nodes or to make them share the full-mesh pre-shared keys. o Key-Exchange Using Secure SDP There is also the framework such as SDP Security Descriptions [6], which is designed on the assumption that SDP is securely protected. We think it possible to manage the key-exchange of IPsec by using this mechanism and binding the media sessions and SAs properly. However, 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 "RTP 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 secret keys, we think there are following possible methods. 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. Saito & Fujimoto Expires - January 2006 [Page 11] Requirements for IPsec Negotiation in SIP July 2005 5.2. Impact on Implementation and Users, and Connectivity We think there are following possible approaches which reduce the implementation and raise the interoperability. o IPsec key exchange in a round-trip by using the offer/answer model of SDP. o Defining the "parameter suites". The parameter suites are the pre-defined sets of the SA parameters, which are frequently chosen. This concept will help to settle the negotiation compared with the negotiations on individual parameters. And it may be effective to choose the light-weight cipher algorithm. 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 one was the SDP Security Descriptions I-D, although it requires the 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 enhancing the idea of the SDP Security Descriptions 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 view point of security, the following features must be considered, too. o Trusted 3rd Party There remains the issue how a user can make sure of trusted 3rd party in order to simplify the process of end-to-end security. At least the disclosure of data by way of the CM must be avoided. Saito & Fujimoto Expires - January 2006 [Page 12] Requirements for IPsec Negotiation in SIP July 2005 Generally, it is supposed that a trustworthy organization such as ISP would manage the CM. However it would be necessary to make a contract which legally prohibits the disclosure of the confidential information. Because the CM can be a man-in-the- middle potentially, it is an essential factor to have a relationship of trust between the user and the CM. o Hiding the Existence of Node By hiding the existence of the own node from the un-desired people, the risk of DoS attacks can be reduced. Such a mechanism may be realized using a trusted 3rd party, but it requires more discussions including the framework of SIP and location service. 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. 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 SDP and RTSP", work in progress, March 2005. 6 Andreasen, F., Baugher, M., Wing, D., "Session Description Protocol Security Descriptions for Media Streams", work in progress, February 2005. Saito & Fujimoto Expires - January 2006 [Page 13] Requirements for IPsec Negotiation in SIP July 2005 7 Rosenberg, J., and Schulzrinne, H., "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. 8 Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. 9 Rosenberg, J., R. Mahy, and C. Huitema, "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-07, work in progress, February 2005. 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 M. Thomas and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", draft-ietf-kink-kink-06, work in progress, December 2003. Saito & Fujimoto Expires - January 2006 [Page 14] Requirements for IPsec Negotiation in SIP July 2005 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@ntt.com 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 - January 2006 [Page 15] Requirements for IPsec Negotiation in SIP July 2005 Copyright Notice Copyright (C) The Internet Society (2005). 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 - January 2006 [Page 16]