Network Working Group J. Loughney Request for Comments: 3788 Nokia Research Center Category: Standards Track M. Tuexen, Ed. Univ. of Applied Sciences Muenster J. Pastor-Balbas Ericsson Espana S.A. June 2004 Security Considerations for Signaling Transport (SIGTRAN) Protocols Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004).
AbstractThis document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols. The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. The support of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS support is optional.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . 3 2. Convention . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Security in Telephony Networks . . . . . . . . . . . . . . . . 4 4. Threats and Goals . . . . . . . . . . . . . . . . . . . . . . 4 5. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Support of IPsec and TLS . . . . . . . . . . . . . . . . . . . 8 8. Peer-to-Peer Considerations . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 11 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 9]. o service provider equipment only. This is the case for SS7 MTP2 User Adaptation Layer (M2UA) , SS7 MTP2 Peer-to-Peer User Adaptation Layer (M2PA) , SS7 MTP3 User Adaptation Layer (M3UA)  and SS7 SCCP User Adaptation Layer (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.
o Communication Security: * Authentication of peers * Integrity of user data transport * Confidentiality of user data * Replay protection o Non-repudiation o System Security, avoidance of: * Unauthorized use * Inappropriate use * Denial of Service Communication security is mandatory in some network scenarios to prevent malicious attacks. The main goal of this document is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. To achieve this goal, we will explore the different existing security options regarding communication. All SIGTRAN protocols use the Stream Control Transmission Protocol (SCTP) defined in  and  as its transport protocol. SCTP provides certain transport related security features, such as resistance against: o Blind Denial of Service Attacks such as: * Flooding. * Masquerade. * Improper Monopolization of Services. There is no quick fix, one-size-fits-all solution for security. When a network using SIGTRAN protocols 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 be used to ensure confidentiality of user payload. Consult  for more information on configuring IPsec services.
4] in transport mode with non-null encryption and authentication algorithms to provide per-packet authentication, integrity protection and confidentiality, and MUST implement the replay protection mechanisms of IPsec. In those scenarios where IP layer protection is needed, ESP in tunnel mode SHOULD be used. Non-null encryption should be used when using IPSec ESP. All SIGTRAN nodes MUST support IKE for peer authentication, negotiation of security associations, and key management, using the IPsec DOI . 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  SHOULD NOT be used. Conformant implementations MUST support IKEs Main Mode and Aggressive Mode. For transport 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 using ESP tunnel mode, IKE Main Mode MAY be used to create an ISAKMP association with identity protection during Phase 1. When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certification authority (or authorities) that is 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. See  for certificate revocation and  for online-checking. 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, whereby another IKE Phase 2 SA will be brought up to protect it if additional traffic is sent. This avoids the potential of 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 . So IPsec implementations used by SIGTRAN nodes SHOULD support the IPsec feature described in . 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.  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. 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. Furthermore, the 'unordered delivery' feature of SCTP can not be used in conjunction with TLS. See  for more details. Because TLS only protects the payload, the SCTP header and all control chunks are not protected. This can be used for DoS attacks. This is a general problem with security provided at the transport layer.
The SIGTRAN protocols use the same SCTP port number and payload protocol identifier when run over TLS. A session upgrade procedure has to be used to initiate the TLS based communication. The session upgrade procedure should be as follows: o If an ASP has been configured to use TLS, it sends a STARTTLS message on stream 0 and starts a timer T_TLS. This is the first message sent and the ASP sends no other adaptation layer messages until the TLS based communication has been established. o If the peer does not support TLS, it sends back an ERROR message indicating an unsupported message type. In this case, the SCTP association is terminated and it is reported to the management layer that the peer does not support TLS. o If the peer does support TLS, it sends back a STARTTLS_ACK message. The client then starts TLS based communication. o If T_TLS expires without getting any of the above answers, the association is terminated and the failure is reported to the management layer. All SIGTRAN adaptation layers share a common message format. The STARTTLS message consists of a common header only using the message class 10 and message type 1. The STARTTLS_ACK message uses the same message class 10 and the message type 2. Neither messages contain any parameters. Using this procedure, it is possible for a man-in-the-middle to do a denial of service attack by indicating that the peer does not support TLS. But this kind of attack is always possible for a man-in-the- middle.
Therefore, in order to have a secured model working as soon as possible, the following recommendation is made: A SIGTRAN node MUST support IPsec and MAY support TLS.
"Initiate IPsec, from me to any, destination port P"; for inbound 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 a 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.
 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.  Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.  Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.  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.  Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.  Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.  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.
 Sidebottom, G., Ed., Morneault, K., Ed. and J. Pastor-Balbas, Ed., "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)", RFC 3332, September 2002.  Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.  George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", Work in Progress, February 2004.  Loughney, J., "Signalling Connection Control Part User Adaptation Layer (SUA)", Work in Progress, December 2003.  Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003.
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. 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- firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.