Network Working Group J. Loughney Internet-Draft Nokia Research Center Expires: April 28, 2003 M. Tuexen Siemens AG J. Pastor-Balbas Ericsson October 28, 2002 Security Considerations for SIGTRAN Protocols draft-ietf-sigtran-security-00.txt 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 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. This Internet-Draft will expire on April 28, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This documents discusses how TLS and IPSec can be used to secure the communication which is based on SIGTRAN protocols. Loughney, et al. Expires April 28, 2003 [Page 1] Internet-Draft SIGTRAN Security October 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security in telephony networks . . . . . . . . . . . . . . . . 5 3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Protecting Confidentiality . . . . . . . . . . . . . . . . . . 7 5. IPSec Usage . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Peer-to-Peer Considerations . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 Loughney, et al. Expires April 28, 2003 [Page 2] Internet-Draft SIGTRAN Security October 2002 1. Introduction 1.1 Overview The SIGTRAN protocols are designed to carry signaling messages for telephony services. These protocols will be used between o customer premise and service provider equipment in case of IUA o service provider equipment only. This is the case for M2UA, M2PA, M3UA and SUA. The carriers may be different and may use other transport network providers. The security requirements for these situations may be different. SIGTRAN protocols involve the security needs of several parties: the end-users of the services; the service providers and the applications involved. Additional security requirements may come from local regulation. While having some overlapping security needs, any security solution should fulfill all of the different parties' needs. The SIGTRAN protocols assume that messages are secured by using either IPSec or TLS. 1.2 Terminology This document uses the following terms: TBD: TDB. 1.3 Abbreviations This document uses the following abbreviations: CA: Certificate Authority. DOI: Domain Of Interpretation. ESP: Encapsulating Security Payload. FQDN: Full-Qualified Domain Names. IPSec: IP Security Protocol. IKE: Internet Key Exchange Protocol. IUA: ISDN Q.921 User Adaptation Layer. Loughney, et al. Expires April 28, 2003 [Page 3] Internet-Draft SIGTRAN Security October 2002 M2PA: SS7 MTP2 Peer-to-Peer User Adaptation Layer. M2UA: SS7 MTP2 User Adaptation Layer. M3UA: SS7 MTP3 User Adaptation Layer. SA: Security Association. SCTP: Stream Control Transmission Protocol. SS7: Signaling System No. 7. SUA: SS7 SCCP User Adaptation Layer. TLS: Transport Layer Security. Loughney, et al. Expires April 28, 2003 [Page 4] Internet-Draft SIGTRAN Security October 2002 2. Security in telephony networks The security in telephony networks is mainly based on the trusted network principle. There are two totally different protocol used: The ISDN access protocol is used for signaling in the access network and the SS7 protocol stack in the core network. As SS7 networks are often physically remoter and/or inacessable, it is assumed that they are protected from malicious users. Often, equipment is under lock and key. At network boundaries between SS7 networks, packet filtering is sometimes used. End-users are not directly connected to SS7 networks. The ISDN access protocol is the separate protocol stack for end-user signaling. End-user signaling protocols are translated to SS7 based protocols by telephone switches run by network operators. Often Regulatory Authorities require SS7 switches with connections to different SS7 to be conformant to national and/or international test specifications. There are no standardized ways of using encryption technologies for providing confidentiality or using technologies for authentication. This description applies to telephony networks operated by a single operator but also to multiple telephony networks being connected and operated by different operators. Loughney, et al. Expires April 28, 2003 [Page 5] Internet-Draft SIGTRAN Security October 2002 3. Threats There is no quick fix, one-size-fits-all solution for security. All SIGTRAN protocols have the following security objectives: o Availability of reliable and timely user data transport. o Authentication of peers. o Integrity of user data transport. o Confidentiality of user data. All SIGTRAN protocols use the Stream Control Transmission Protocol (SCTP) being defined in [7] and [9] as its transport protocol. SCTP provides certain transport related security features, such as: o Blind Denial of Service Attacks o Flooding o Masquerade o Improper Monopolization of Services When SIGTRAN protocols are running in professionally managed corporate or service provider network, it is reasonable to expect that this network include an appropriate security policy framework. The "Site Security Handbook" [1] should be consulted for guidance. When the network in which SIGTRAN protocols are used involves more than one party, it may not be reasonable to expect that all parties have implemented security in a sufficient manner. End-to-end security should be the goal; therefore, it is recommended that IPSec or TLS is used to ensure confidentiality of user payload. Consult [3] for more information on configuring IPSec services. Loughney, et al. Expires April 28, 2003 [Page 6] Internet-Draft SIGTRAN Security October 2002 4. Protecting Confidentiality If SIGTRAN information has to be protected either IPSec ESP in transport mode or TLS can be used. In both cases the IP header information is neither encrypted nor protected. If IPSec ESP is chosen the SCTP control information is encrypted and protected whereas if the TLS based solution the SCTP control information is not encrypted and only protected by SCTP procedures. Loughney, et al. Expires April 28, 2003 [Page 7] Internet-Draft SIGTRAN Security October 2002 5. IPSec Usage This section is relevant only for SIGTRAN nodes using IPSec to secure communication between SIGTRAN node. All SIGTRAN nodes using IPSec MUST support IPsec ESP [4] in transport mode with non-null encryption and authentication algorithms to provide per-packet authentication, integrity protection and confidentiality, and MUST support the replay protection mechanisms of IPSec. These nodes MUST support IKE for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [5]. The IPSec implementations MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKE's sections 5.2 and 5.3 [6] SHOULD NOT be used. Conformant implementations MUST support both IKE Main Mode and Aggressive Mode. When pre-shared keys are used for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used. When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD use pertinent certificate revocation checks before accepting a PKI certificate for use in IKE's authentication procedures. The Phase 2 Quick Mode exchanges used to negotiate protection for SIGTRAN sessions MUST explicitly carry the Identity Payload fields (IDci and IDcr). The DOI provides for several types of identification data. However, when used in conformant implementations, each ID Payload MUST carry a single IP address and a single non-zero port number, and MUST NOT use the IP Subnet or IP Address Range formats. This allows the Phase 2 security association to correspond to specific TCP and SCTP connections. Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down a SIGTRAN session. Rather, it is preferable to leave the connection up, and if additional traffic is sent on it, to bring up another IKE Loughney, et al. Expires April 28, 2003 [Page 8] Internet-Draft SIGTRAN Security October 2002 Phase 2 SA to protect it. This avoids the potential for continually bringing connections up and down. It should be noted that SCTP supports multi-homed hosts and this results in the need for having multiple security associations for one SCTP association. This disadvantage of IPSec has been addressed by [14]. So IPSec implementations used by SIGTRAN nodes SHOULD support the IPSec feature described in [14]. Loughney, et al. Expires April 28, 2003 [Page 9] Internet-Draft SIGTRAN Security October 2002 6. TLS Usage This section is relevant only for SIGTRAN nodes using TLS to secure the communication between SIGTRAN nodes. A SIGTRAN node that initiates a SCTP association to another SIGTRAN node acts as a TLS client according to [2], and a SIGTRAN node that accepts a connection acts as a TLS server. SIGTRAN peers implementing TLS for security MUST mutually authenticate as part of TLS session establishment. In order to ensure mutual authentication, the SIGTRAN node acting as TLS server must request a certificate from the SIGTRAN node acting as TLS client, and the SIGTRAN node acting as TLS client MUST be prepared to supply a certificate on request. [13] requires the support of the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. SIGTRAN nodes MAY negotiate other TLS cipher suites. TLS MUST be used on all bi-directional streams and the other uni- directional streams MUST NOT be used. It should also be noted that a SCTP implementation used for TLS over SCTP MUST support fragmentation of user data and might also need to support the partial delivery API. This holds even if all SIGTRAN messages are small. See [13] for more details. The SIGTRAN protocols use separate SCTP port numbers and payload protocol identifiers when run over TLS. These numbers are given in Section 9. A SIGTRAN session MUST be aborted if the port number or payload protocol identifier indicates the use of TLS and it is not used. As an alternative to a separate port number, a session upgrade procedure can be used. This needs an extension for all adaptation layers allowing the SIGTRAN protocols to use the same port number in the case where TLS is used or not. This needs further discussions. Loughney, et al. Expires April 28, 2003 [Page 10] Internet-Draft SIGTRAN Security October 2002 7. Peer-to-Peer Considerations M2PA, M3UA and SUA support the peer-to-peer model as a generalization to the client-server model which is supported by IUA and M2UA. A SIGTRAN node running M2PA, M3UA or SUA and operating in the peer-to- peer mode is called a SIGTRAN peer. As with any peer-to-peer protocol, proper configuration of the trust model within a peer is essential to security. When certificates are used, it is necessary to configure the root certificate authorities trusted by the peer. These root CAs are likely to be unique to SIGTRAN usage and distinct from the root CAs that might be trusted for other purposes such as Web browsing. In general, it is expected that those root CAs will be configured so as to reflect the business relationships between the organization hosting the peer and other organizations. As a result, a peer will typically not be configured to allow connectivity with any arbitrary peer. When certificate authentication peers may not be known beforehand, and therefore peer discovery may be required. Note that IPsec is considerably less flexible than TLS when it comes to configuring root CAs. Since use of Port identifiers is prohibited within IKE Phase 1, within IPsec it is not possible to uniquely configure trusted root CAs for each application individually; the same policy must be used for all applications. This implies, for example, that a root CA trusted for use with a SIGTRAN protocol must also be trusted to protect SNMP. These restrictions can be awkward at best. Since TLS supports application-level granularity in certificate policy, TLS SHOULD be used to protect SIGTRAN sessions between administrative domains. IPsec is most appropriate for intra- domain usage when pre-shared keys are used as a security mechanism. When pre-shared key authentication is used with IPSec to protect SIGTRAN based communication, unique pre-shared keys are configured with peers, who are identified by their IP address (Main Mode), or possibly their FQDN (AggressivenMode). As a result, it is necessary for the set of peers to be known beforehand. Therefore, peer discovery is typically not necessary. The following is intended to provide some guidance on the issue. It is recommended that SIGTRAN peers use the same security mechanism (IPSec or TLS) across all its sessions with other SIGTRAN peers. Inconsistent use of security mechanisms can result in redundant security mechanisms being used (e.g. TLS over IPsec) or worse, potential security vulnerabilities. When IPsec is used with a SIGTRAN protocol, a typical security policy for outbound traffic is "Initiate IPsec, from me to any, destination port P"; for inbound Loughney, et al. Expires April 28, 2003 [Page 11] Internet-Draft SIGTRAN Security October 2002 traffic, the policy would be "Require IPsec, from any to me, destination port P". Here P denotes one of the registered port numbers for a SIGTRAN protocol. This policy causes IPSec to be used whenever a SIGTRAN peer initiates a session to another SIGTRAN peer, and to be required whenever an inbound SIGTRAN session occurs. This policy is attractive, since it does not require policy to be set for each peer or dynamically modified each time a new SIGTRAN session is created; an IPSec SA is automatically created based on a simple static policy. Since IPSec extensions are typically not available to the sockets API on most platforms, and IPsec policy functionality is implementation dependent, use of a simple static policy is the often the simplest route to IPSec-enabling a SIGTRAN peer. If IPSec is used to secure SIGTRAN peer-to-peer session, IPSec policy SHOULD be set so as to require IPsec protection for inbound connections, and to initiate IPsec protection for outbound connections. This can be accomplished via use of inbound and outbound filter policy. Loughney, et al. Expires April 28, 2003 [Page 12] Internet-Draft SIGTRAN Security October 2002 8. Security Considerations This documents discusses the usage of IPSec and TLS for securing SIGTRAN traffic. Loughney, et al. Expires April 28, 2003 [Page 13] Internet-Draft SIGTRAN Security October 2002 9. IANA Considerations SCTP port numbers and SCTP payload protocol identifiers have to be registered for: o IUA over TLS o M2UA over TLS o M2PA over TLS o M3UA over TLS o SUA over TLS Loughney, et al. Expires April 28, 2003 [Page 14] Internet-Draft SIGTRAN Security October 2002 10. Acknowledgements The authors would like to thank K. Morneau and many others for their invaluable comments and suggestions. Loughney, et al. Expires April 28, 2003 [Page 15] Internet-Draft SIGTRAN Security October 2002 References [1] Fraser, B., "Site Security Handbook", RFC 2196, September 1997. [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [5] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [8] Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001. [9] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002. [10] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J. Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer", RFC 3331, September 2002. [11] Sidebottom, G., Morneault, K. and J. Pastor-Balbas, "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", RFC 3332, September 2002. [12] George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", draft-ietf-sigtran-m2pa-06 (work in progress), August 2002. [13] Rescorla, E., Tuexen, M. and A. Jungmaier, "TLS over SCTP", draft-ietf-tsvwg-tls-over-sctp-00 (work in progress), November 2001. [14] Bellovin, S., "On the Use of SCTP with IPsec", draft-ietf- ipsec-sctp-04 (work in progress), October 2002. Loughney, et al. Expires April 28, 2003 [Page 16] Internet-Draft SIGTRAN Security October 2002 Authors' Addresses John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland EMail: john.loughney@nokia.com Michael Tuexen Siemens AG Hofmannstr. 51 81359 Munich Germany EMail: Michael.Tuexen@siemens.com Javier Pastor-Balbas Ericsson ? Madrid Spain EMail: javier.pastor-balbas@ece.ericsson.se Loughney, et al. Expires April 28, 2003 [Page 17] Internet-Draft SIGTRAN Security October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Loughney, et al. Expires April 28, 2003 [Page 18]