GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3788

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).

Abstract

 This 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.

Loughney, et al. Standards Track [Page 1] RFC 3788 SIGTRAN Security June 2004

Table of Contents

 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

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 ISDN
    Q.921 User Adaptation Layer (IUA) [9].
 o  service provider equipment only.  This is the case for SS7 MTP2
    User Adaptation Layer (M2UA) [12], SS7 MTP2 Peer-to-Peer User
    Adaptation Layer (M2PA) [15], SS7 MTP3 User Adaptation Layer
    (M3UA) [13] and SS7 SCCP User Adaptation Layer (SUA) [16].  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.

Loughney, et al. Standards Track [Page 2] RFC 3788 SIGTRAN Security June 2004

1.2. Abbreviations

 This document uses the following abbreviations:
 ASP: Application Server Process
 CA: Certification Authority
 DOI: Domain Of Interpretation
 ESP: Encapsulating Security Payload
 FQDN: Full-Qualified Domain Names
 IPsec: IP Security Protocol
 IKE: Internet Key Exchange Protocol
 ISDN: Integrated Services Digital Network
 IUA: ISDN Q.921 User Adaptation Layer
 M2PA: SS7 MTP2 Peer-to-Peer User Adaptation Layer
 M2UA: SS7 MTP2 User Adaptation Layer
 M3UA: SS7 MTP3 User Adaptation Layer
 PKI: Public Key Infrastructure
 SA: Security Association
 SCTP: Stream Control Transmission Protocol
 SS7: Signaling System No. 7
 SUA: SS7 SCCP User Adaptation Layer
 TLS: Transport Layer Security

2. Convention

 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
 they appear in this document, are to be interpreted as described in
 [1].

Loughney, et al. Standards Track [Page 3] RFC 3788 SIGTRAN Security June 2004

3. Security in Telephony Networks

 The security in telephony networks is mainly based on the closed
 network principle.  There are two main protocols used: Access
 protocols (ISDN and others) are used for signaling in the access
 network and the SS7 protocol stack in the core network.
 As SS7 networks are often physically remote and/or inaccessible to
 the user, it is assumed that they are protected from malicious users.
 Equipment is often 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 access protocols are used for end-user signaling.  End-user
 signaling protocols are translated to SS7 based protocols by
 telephone switches run by network operators.
 Regulatory Authorities often require SS7 switches with connections to
 different SS7 switches 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, and also to multiple telephony networks being connected and
 operated by different operators.

4. Threats and Goals

 The Internet threats can be divided into one of two main types.  The
 first one is called "passive attacks".  It happens whenever the
 attacker reads packets off the network but does not write them.
 Examples of such attacks include confidentiality violations, password
 sniffing and offline cryptographic attacks amongst others.
 The second kind of threat is called "active attacks".  In this case,
 the attacker also writes data to the network.  Examples for this
 attack include replay attacks, message insertion, message deletion,
 message modification or man-in-the-middle attacks, amongst others.
 In general, Internet protocols have the following security
 objectives:

Loughney, et al. Standards Track [Page 4] RFC 3788 SIGTRAN Security June 2004

 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 [8] and [11] 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 [3] for more
 information on configuring IPsec services.

Loughney, et al. Standards Track [Page 5] RFC 3788 SIGTRAN Security June 2004

5. IPsec Usage

 This section is only relevant for SIGTRAN nodes using IPsec to secure
 communication between SIGTRAN nodes.
 All SIGTRAN nodes using IPsec MUST implement IPsec ESP [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 [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 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 [10] for
 certificate revocation and [7] 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.

Loughney, et al. Standards Track [Page 6] RFC 3788 SIGTRAN Security June 2004

 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
 [17]. So IPsec implementations used by SIGTRAN nodes SHOULD support
 the IPsec feature described in [17].

6. TLS Usage

 This section is only relevant 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.
 [14] 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 [14] 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.

Loughney, et al. Standards Track [Page 7] RFC 3788 SIGTRAN Security June 2004

 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.

7. Support of IPsec and TLS

 If content of SIGTRAN protocol messages is to be protected, either
 IPsec ESP or TLS can be used.  In both IPsec ESP Transport Mode and
 TLS cases, the IP header information is neither encrypted nor
 protected.  If IPsec ESP is chosen, the SCTP control information is
 encrypted and protected whereas in the TLS based solution, the SCTP
 control information is not encrypted and only protected by SCTP
 procedures.
 In general, both IPsec and TLS have enough mechanisms to secure the
 SIGTRAN communications.

Loughney, et al. Standards Track [Page 8] RFC 3788 SIGTRAN Security June 2004

 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.

8. 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 trust anchors trusted by the
 peer.  These trust anchors are likely to be unique to SIGTRAN usage
 and distinct from the trust anchors that might be trusted for other
 purposes such as Web browsing.  In general, it is expected that those
 trust anchors 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 not typically be configured
 to allow connectivity with any arbitrary peer.  When certificate
 authentication peers may not be known beforehand, peer discovery may
 be required.
 Note that IPsec is considerably less flexible than TLS when it comes
 to configuring trust anchors.  Since use of Port identifiers is
 prohibited within IKE Phase 1, it is not possible to uniquely
 configure trusted trust anchors for each application individually
 within IPsec; the same policy must be used for all applications.
 This implies, for example, that a trust anchor trusted for use with a
 SIGTRAN protocol must also be trusted to protect other protocols (for
 example SNMP).  These restrictions are awkward at best.
 When pre-shared key authentication is used with IPsec to protect
 SIGTRAN based communication, unique pre-shared keys are configured
 with peers that 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

Loughney, et al. Standards Track [Page 9] RFC 3788 SIGTRAN Security June 2004

 "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.

9. Security Considerations

 This document discusses the usage of IPsec and TLS for securing
 SIGTRAN traffic.

10. IANA Considerations

 The message class 12 has been reserved in the Signaling User Adaption
 Layer Assignments Registry.  For this message class, message type 1
 has been reserved for the STARTTLS message, and message type 2 for
 the STARTTLS_ACK message.

11. Acknowledgements

 The authors would like to thank B. Aboba, K. Morneault and many
 others for their invaluable comments and suggestions.

Loughney, et al. Standards Track [Page 10] RFC 3788 SIGTRAN Security June 2004

12. References

12.1. Normative References

 [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

12.2. Informative References

 [2]   Dierks, T. and C. Allen, "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]   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.
 [8]   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.
 [9]   Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom,
       "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.
 [10]  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.
 [11]  Stone, J., Stewart, R. and D. Otis, "Stream Control
       Transmission Protocol (SCTP) Checksum Change", RFC 3309,
       September 2002.
 [12]  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.

Loughney, et al. Standards Track [Page 11] RFC 3788 SIGTRAN Security June 2004

 [13]  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.
 [14]  Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer
       Security over Stream Control Transmission Protocol", RFC 3436,
       December 2002.
 [15]  George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", Work
       in Progress, February 2004.
 [16]  Loughney, J., "Signalling Connection Control Part User
       Adaptation  Layer (SUA)", Work in Progress, December 2003.
 [17]  Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On
       the Use of Stream Control Transmission Protocol (SCTP) with
       IPsec", RFC 3554, July 2003.

13. Authors' Addresses

 John Loughney
 Nokia Research Center
 PO Box 407
 FIN-00045 Nokia Group
 Finland
 EMail: john.loughney@nokia.com
 Michael Tuexen (editor)
 Univ. of Applied Sciences Muenster
 Stegerwaldstr. 39
 48565 Steinfurt
 Germany
 EMail: tuexen@fh-muenster.de
 Javier Pastor-Balbas
 Ericsson Espana S.A.
 Via de los Poblados, 13
 28033 Madrid
 Spain
 EMail: j.javier.pastor@ericsson.com

Loughney, et al. Standards Track [Page 12] RFC 3788 SIGTRAN Security June 2004

14. Full Copyright Statement

 Copyright (C) The Internet Society (2004).  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.

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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Loughney, et al. Standards Track [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3788.txt · Last modified: 2004/06/15 22:35 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki