MMUSIC Working Group Internet Draft M. Saito Intended status: Standards Track NTT Communications Expires: August 2007 D. Wing Cisco Systems February 2007 Media Description for IKE in the Session Description Protocol (SDP) draft-saito-mmusic-sdp-ike-00 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 This document extends the protocol identifier of SDP so that it could negotiate the use of IKE for media session in SDP offer/answer model. And it also specifies the method to generate VPN based on tunnel mode IPsec using self-signed certificate under the mechanism of comedia- tls. This document extends RFC 4572. In addition, it defines a new attribute "udp-setup", which is similar to "setup" attribute defined in RFC 4145, to enable endpoints to negotiate their roles in the IKE session. 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 [RFC2119]. Saito & Wing Expires - August 2007 [Page 1] Media Description for IKE in the SDP February 2007 Table of Contents 1. Introduction..................................................2 1.1. Problem Statement........................................2 1.2. Approach to Solution.....................................3 2. Protocol Overview.............................................3 3. Protocol Identifiers..........................................5 4. Example of SDP Offer and Answer Exchange......................6 5. Application to IKE............................................6 6. Security Consideration........................................7 7. IANA Considerations...........................................7 8. References....................................................8 8.1. Normative References.....................................8 8.2. Informative References...................................8 1. Introduction In this section, the background of the problem in accessing home network which this document tries to solve, and the approach to the solution are described. 1.1. Problem Statement When a device outside the home network connects to another device inside the home network, it often becomes a problem to traverse a NAT (Network Address Translation) device between them. One of the effective solutions for this problem is VPN remote access to the NAT device, usually a home router. With this approach, once the external device participates in the home network securely, it will be easy to establish connections with all the devices inside the home. However, because a global IP address of the home router is not always fixed, it is necessary to make use of an effective name resolution mechanism. On the other hand, there is also a problem how a remote client and a home router authenticate each other over IKE [RFC4306] which establishes VPN. It wouldn't be always possible that both parties exchange a pre-shared key securely in advance. It would be also impractical to distribute authentication certificates signed by well- known root certification authority (CA) to all the devices because of their cost and administrative overhead, and after all, it is inefficient to publish a temporary certificate to the device which does not have a fixed IP address or hostname. Therefore, if it is possible to use a self-signed certificate for authentication securely, that will be one of the effective solutions in this case. Saito & Wing Expires - August 2007 [Page 2] Media Description for IKE in the SDP February 2007 1.2. Approach to Solution As for the name resolution mechanism noted in 1.1, SIP [RFC3261] is one of the possible protocols. Today, SIP is applied to not only VoIP but also various applications and recognized as a general protocol for session initiation. Therefore, it can be used to initiate VPN sessions, too. On the other hand, there is also a specification which uses a self- signed certificate for authentication in the SIP/SDP [RFC4566] framework. Actually, comedia-tls [RFC4572] specifies the method to exchange a fingerprint of self-signed certificate to establish a TLS [RFC4346] connection. This specification defines a mechanism that allows self-signed certificates can be used securely, provided that the integrity of the SDP description is assured. Because a certificate itself can be used for authentication not only in TLS but also in IKE which is used to launch VPN, this mechanism will be applied to the establishment of VPN based on tunnel mode IPsec by extending the protocol identifier of SDP so that it could specify IKE. Considering above background, this document defines a new media format "IKE" which can be used when the protocol identifier is "UDP" to enable the negotiation of using IKE for media session over SDP exchange on condition that the integrity of SDP description is assured. And it also specifies the method to generate VPN based on tunnel mode IPsec by exchanging fingerprints of self-signed certificates following comedia-tls, and notes the example of SDP offer/answer [RFC3264] and the points which implementation should take care. In addition, it defines an attribute "udp-setup" for UDP media sessions, similar to the "setup" attribute for TCP-based media transport defined in RFC 4145 [RFC4145]. It is used to negotiate the role of each endpoint in the IKE session. 2. Protocol Overview As shown in Figure 1, for example, there is a case of VPN remote access from a device outside the home to the home router whose IP address is not fixed. In this case, the external device, a remote client recognizes Address of Record of the home router, but does not have any information about its contact address and certificate. Generally, it is difficult to establish tunnel mode IPsec dynamically and securely in this situation. However as specified in comedia-tls, if the integrity of SDP session descriptions is assured, it is possible for the home router and the remote client to have a prior relationship with each other by exchanging certificate fingerprints, secure one-way hashes of the DER (distinguished encoding rules) form of the certificates. Saito & Wing Expires - August 2007 [Page 3] Media Description for IKE in the SDP February 2007 REGISTRATION +----------+ REGISTRATION (1) | SIP | (1) +---------->| Proxy |<------+ | +------->| |-----+ | | |INVITE +----------+ | | | | (2) | | +--------+ | | V | | Home | +----------+ IKE(Media Session) +--------+ Net. | | |<--------(3)-------->| Home | | | Remote | | Router | | | Client ==========(4)==================== | | | Tunnel Mode IPsec +--------+ | +----------+ | | +--------+ Figure 1: Remote Access to Home Network (1) Both Remote Client and Home Router generate secure signaling channels. They may REGISTER to SIP Proxy using TLS. (2) Both Remote Client (SDP offerer) and Home Router (SDP answerer) exchange the fingerprints of their self-signed certificates in SDP during an INVITE transaction. (3) After SDP exchange, Remote Client (SDP offerer) initiates IKE with the SDP answerer to establish tunnel mode IPsec. Both the offerer and the answerer validate that the certificate presented in the IKE exchange has a fingerprint that matches the fingerprint from SDP. If they match, IKE negotiation proceeds as normal. (4) Remote Client joins in the Home Network. Using this method, the self-signed certificates of both parties are used for authentication in IKE, but SDP itself is not concerned with all the negotiations related to key-exchange such as those of encryption and authentication algorithms. These negotiations are up to IKE. And in many cases that tunnel mode IPsec is used for remote access, a remote client needs to obtain a private address inside the home network dynamically while initiating the remote access, therefore IPsec security policy also needs to be set dynamically at the same time. However, such a management function of security policy is on the responsibility of the high-level VPN application. SDP is not concerned with it. The roles of SDP here are to determine the IP addresses of both parties used for IKE connection with c-line in SDP, and exchange fingerprints of certificates used for authentication in IKE with fingerprint attribute in SDP. Saito & Wing Expires - August 2007 [Page 4] Media Description for IKE in the SDP February 2007 If the high-level application thinks a VPN session as the media session, it will discard the security policy and terminate IKE when that media session is terminated by BYE request. But each party can cache the certificate of the other party as described in Security Consideration of comedia-tls. The above example is for tunnel mode IPsec used for remote access, but the actual usage of negotiated IPsec is not limited. For example, IKE can negotiate transport mode IPsec to encrypt multiple media sessions between two parties with only a pair of IPsec Security Associations. Only one thing that SDP offer/answer model is responsible for is to exchange the fingerprints of certificates used for IKE, therefore, it does not take care security policy. 3. Protocol Identifiers This document defines a new media format description "IKE", which can be used when the protocol identifier is "UDP" and indicates that the described media is IKE. Both offerer and answerer can negotiate IKE by specifying "UDP" in the "proto" field and "IKE" in the "fmt" field in SDP. In addition, this document defines a new attribute "udp-setup", which can be used when the protocol identifier is "UDP" and the "fmt" field is "IKE", in order to describe how should endpoints perform the IKE session setup procedure. The "udp-setup" attribute indicates which of the end points should initiate the IKE session establishment. The "udp-setup" attribute is charset-independent and can be a session- level or a media-level attribute. The following is the ABNF of the "udp-setup" attribute. udp-setup-attr = "a=udp-setup:" role role = "active" / "passive" / "actpass" 'active' : The endpoint will initiate an outgoing session. 'passive' : The endpoint will accept an incoming session. 'actpass' : The endpoint is willing to accept an incoming session or to initiate an outgoing session. As defined in 4.1 of RFC 4145, both endpoints negotiate the value of "udp-setup" using the offer/answer model. However, "holdconn" defined in RFC 4145 is not defined here because UDP doesn't establish a connection. Offer Answer ---------------------------- active passive passive active actpass active / passive Saito & Wing Expires - August 2007 [Page 5] Media Description for IKE in the SDP February 2007 The semantics of "active", "passive", and "actpass" in the offer/answer exchange is the same as the definition described in 4.1 of RFC 4145. The default value of the udp-setup attribute is "active" in the offer and "passive" in the answer. 4. Example of SDP Offer and Answer Exchange The example of SDP exchanged to negotiate IKE following this specification is as follows. (Note: due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content.) offer SDP ... m=application 9500 UDP IKE c=IN IP4 192.0.2.10 a=udp-setup:active a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB ... answer SDP ... m=application 500 UDP IKE c=IN IP4 192.0.2.20 a=udp-setup:passive a=fingerprint:SHA-1 \ D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:8E ... Following comedia-tls specification, the fingerprint attribute may be either a session-level or a media-level SDP attribute. If it is a session-level attribute, it applies to all IKE sessions and TLS sessions for which no media-level fingerprint attribute is defined. 5. Application to IKE After sharing fingerprints of both parties securely over the SDP exchange, SDP offerer MAY start the IKE session to the other party. To follow this specification, digital signature MUST be chosen as an authentication method in IKE phase 1. In this process, a self-signed certificate that is an original of fingerprint exchanged over SDP MUST be used. If the certificate used in IKE does not match the Saito & Wing Expires - August 2007 [Page 6] Media Description for IKE in the SDP February 2007 original fingerprint, the endpoint MUST terminate the IKE session with detecting an authentication failure. In addition, each party MUST present a certificate and be authenticated by each other. 6. Security Consideration This entire document concerns itself with security, but the security considerations applicable to SDP in general is described in SDP specification. And the security issues which should be considered in using comedia-tls are described in Section 7 in its specification. This section describes the security considerations specific in the negotiation of IKE using comedia-tls. Offering IKE in SDP (or agreeing to one in SDP offer/answer mode) does not create an obligation for an endpoint to accept any IKE session with the given fingerprint. On the other hand, the endpoint must engage in the standard IKE negotiation procedure to ensure that the IPsec Security Associations (including encryption and authentication algorithms) chosen meet the security requirements of VPN that the higher-level application needs. In this specification, each endpoint MAY assert its SIP Address of Record or IP address or FQDN as its identity in the subjectAltName field in a certificate. However, when an endpoint receives a certificate for IKE asserting an identity other than SIP Address of Record without authenticity and integrity protection of SDP descriptions, it SHOULD alert the user and ask for confirmation. In this document, the purpose of using IKE is launching the IPsec tunnel for VPN, and not for the security mechanism of RTP and RTCP packets. Actually, this mechanism cannot provide end-to-end security inside the virtual private network as long as using tunnel mode IPsec, therefore other security methods such as SRTP must be used to secure them. 7. IANA Considerations This document defines a session and media level SDP attribute, "udp- setup". This attribute should be registered by the IANA under "Session Description Protocol (SDP) Parameters" under "att-field (both session and media level)". This document defines a media format "IKE". This media format value should be registered by the IANA. A media format "IKE" is associated with a proto value "UDP". Saito & Wing Expires - August 2007 [Page 7] Media Description for IKE in the SDP February 2007 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4306] C. Kaufman, Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4566] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4572] J. Lennox, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. [RFC3264] Rosenberg, J., and Schulzrinne, H., "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. 8.2. Informative References [RFC4346] T. Dierks, and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4145] D. Yon, and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. Author's Addresses Makoto Saito NTT Communications 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421 Japan Email: ma.saito@nttv6.jp Saito & Wing Expires - August 2007 [Page 8] Media Description for IKE in the SDP February 2007 Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States Email: dwing@cisco.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. Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 & Wing Expires - August 2007 [Page 9]