draft-ietf-sigtran-security-03.txt   rfc3788.txt 
Network Working Group J. Loughney Network Working Group J. Loughney
Internet-Draft Nokia Research Center Request for Comments: 3788 Nokia Research Center
Expires: December 28, 2003 M. Tuexen, Ed. Category: Standards Track M. Tuexen, Ed.
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
J. Pastor-Balbas J. Pastor-Balbas
Ericsson Ericsson Espana S.A.
June 29, 2003 June 2004
Security Considerations for SIGTRAN Protocols Security Considerations for
draft-ietf-sigtran-security-03.txt Signaling Transport (SIGTRAN) Protocols
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that other and status of this protocol. Distribution of this memo is unlimited.
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 December 28, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This documents discusses how TLS and IPsec can be used to secure the This document discusses how Transport Layer Security (TLS) and IPsec
communication for SIGTRAN protocols. The support of IPsec is can be used to secure communication for SIGTRAN protocols. The main
mandatory for all nodes running SIGTRAN protocols and the support of goal is to recommend the minimum security means that a SIGTRAN node
TLS is optional. must implement in order to attain secured communication. The support
of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS
support is optional.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . 3
2. Convention . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Convention . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security in telephony networks . . . . . . . . . . . . . . . 4 3. Security in Telephony Networks . . . . . . . . . . . . . . . . 4
4. Threats and Goals . . . . . . . . . . . . . . . . . . . . . . 5 4. Threats and Goals . . . . . . . . . . . . . . . . . . . . . . 4
5. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Support of IPsec and TLS . . . . . . . . . . . . . . . . . . 9 7. Support of IPsec and TLS . . . . . . . . . . . . . . . . . . . 8
8. Peer-to-Peer Considerations . . . . . . . . . . . . . . . . . 9 8. Peer-to-Peer Considerations . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2 Informative References . . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 11
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . 14 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
1.1 Overview 1.1. Overview
The SIGTRAN protocols are designed to carry signaling messages for The SIGTRAN protocols are designed to carry signaling messages for
telephony services. These protocols will be used between telephony services. These protocols will be used between
o customer premise and service provider equipment in case of IUA 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 M2UA, M2PA, o service provider equipment only. This is the case for SS7 MTP2
M3UA and SUA. The carriers may be different and may use other User Adaptation Layer (M2UA) [12], SS7 MTP2 Peer-to-Peer User
transport network providers. 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. The security requirements for these situations may be different.
SIGTRAN protocols involve the security needs of several parties: the SIGTRAN protocols involve the security needs of several parties, the
end-users of the services; the service providers and the applications end-users of the services, the service providers and the applications
involved. Additional security requirements may come from local involved. Additional security requirements may come from local
regulation. While having some overlapping security needs, any regulation. While having some overlapping security needs, any
security solution should fulfill all of the different parties' needs. security solution should fulfill all of the different parties' needs.
The SIGTRAN protocols assume that messages are secured by using The SIGTRAN protocols assume that messages are secured by using
either IPsec or TLS. either IPsec or TLS.
1.2 Abbreviations 1.2. Abbreviations
This document uses the following abbreviations: This document uses the following abbreviations:
ASP: Application Server Process. ASP: Application Server Process
CA: Certification Authority. CA: Certification Authority
DOI: Domain Of Interpretation. DOI: Domain Of Interpretation
ESP: Encapsulating Security Payload. ESP: Encapsulating Security Payload
FQDN: Full-Qualified Domain Names. FQDN: Full-Qualified Domain Names
IPsec: IP Security Protocol. IPsec: IP Security Protocol
IKE: Internet Key Exchange Protocol. IKE: Internet Key Exchange Protocol
ISDN: Integrated Services Digital Network. ISDN: Integrated Services Digital Network
IUA: ISDN Q.921 User Adaptation Layer. IUA: ISDN Q.921 User Adaptation Layer
M2PA: SS7 MTP2 Peer-to-Peer User Adaptation Layer. M2PA: SS7 MTP2 Peer-to-Peer User Adaptation Layer
M2UA: SS7 MTP2 User Adaptation Layer. M2UA: SS7 MTP2 User Adaptation Layer
M3UA: SS7 MTP3 User Adaptation Layer. M3UA: SS7 MTP3 User Adaptation Layer
PKI: Public Key Infrastructure. PKI: Public Key Infrastructure
SA: Security Association. SA: Security Association
SCTP: Stream Control Transmission Protocol. SCTP: Stream Control Transmission Protocol
SS7: Signaling System No. 7. SS7: Signaling System No. 7
SUA: SS7 SCCP User Adaptation Layer. SUA: SS7 SCCP User Adaptation Layer
TLS: Transport Layer Security. TLS: Transport Layer Security
2. Convention 2. Convention
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
[1]. [1].
3. Security in telephony networks 3. Security in Telephony Networks
The security in telephony networks is mainly based on the closed The security in telephony networks is mainly based on the closed
network principle. There are two main protocols used: Access network principle. There are two main protocols used: Access
protocols (ISDN and others) are used for signaling in the access protocols (ISDN and others) are used for signaling in the access
network and the SS7 protocol stack in the core network. network and the SS7 protocol stack in the core network.
As SS7 networks are often physically remote and/or inaccessible to As SS7 networks are often physically remote and/or inaccessible to
the user, it is assumed that they are protected from malicious users. the user, it is assumed that they are protected from malicious users.
Often, equipment is under lock and key. At network boundaries Equipment is often under lock and key. At network boundaries between
between SS7 networks, packet filtering is sometimes used. End-users SS7 networks, packet filtering is sometimes used. End-users are not
are not directly connected to SS7 networks. directly connected to SS7 networks.
The access protocols are used for end-user signaling. End-user The access protocols are used for end-user signaling. End-user
signaling protocols are translated to SS7 based protocols by signaling protocols are translated to SS7 based protocols by
telephone switches run by network operators. telephone switches run by network operators.
Often Regulatory Authorities require SS7 switches with connections to Regulatory Authorities often require SS7 switches with connections to
different SS7 to be conformant to national and/or international test different SS7 switches to be conformant to national and/or
specifications. international test specifications.
There are no standardized ways of using encryption technologies for There are no standardized ways of using encryption technologies for
providing confidentiality or using technologies for authentication. providing confidentiality or using technologies for authentication.
This description applies to telephony networks operated by a single This description applies to telephony networks operated by a single
operator but also to multiple telephony networks being connected and operator, and also to multiple telephony networks being connected and
operated by different operators. operated by different operators.
4. Threats and Goals 4. Threats and Goals
The Internet threats can be divided into one of two main types. The The Internet threats can be divided into one of two main types. The
first one is called "passive attacks". It happens whenever the first one is called "passive attacks". It happens whenever the
attacker reads packets off the network but does not write them. attacker reads packets off the network but does not write them.
Examples of such attacks include confidentiality violations, password Examples of such attacks include confidentiality violations, password
sniffing and offline cryptographic attacks amongst others. sniffing and offline cryptographic attacks amongst others.
The second kind of threads is called "active attacks". In this case The second kind of threat is called "active attacks". In this case,
the attacker also writes data to the network. Examples for this the attacker also writes data to the network. Examples for this
attack include replay attacks, message insertion, message deletion, attack include replay attacks, message insertion, message deletion,
message modification or man-in-the-middle attacks amongst others. message modification or man-in-the-middle attacks, amongst others.
In general, Internet protocols have the following security In general, Internet protocols have the following security
objectives: objectives:
o Communication Security: o Communication Security:
* Authentication of peers. * Authentication of peers
* Integrity of user data transport. * Integrity of user data transport
* Confidentiality of user data. * Confidentiality of user data
* Replay protection. * Replay protection
o Non-repudiation. o Non-repudiation
o System Security, avoidance of: o System Security, avoidance of:
* Unauthorized use. * Unauthorized use
* Inappropiate use. * Inappropriate use
* Denial of Service. * Denial of Service
Communication security is mandatory in some network scenarios to Communication security is mandatory in some network scenarios to
prevent malicious attacks. The main goal of this document is to prevent malicious attacks. The main goal of this document is to
recommend the minimum security means that a SIGTRAN node must recommend the minimum security means that a SIGTRAN node must
implement in order to achieve a secured communication. To get this implement in order to attain secured communication. To achieve this
goal, we will explore the different security options that regarding goal, we will explore the different existing security options
communication exist. regarding communication.
All SIGTRAN protocols use the Stream Control Transmission Protocol All SIGTRAN protocols use the Stream Control Transmission Protocol
(SCTP) being defined in [9] and [12] as its transport protocol. SCTP (SCTP) defined in [8] and [11] as its transport protocol. SCTP
provides certain transport related security features, such as provides certain transport related security features, such as
resistance against: resistance against:
o Blind Denial of Service Attacks such as: o Blind Denial of Service Attacks such as:
* Flooding. * Flooding.
* Masquerade. * Masquerade.
* Improper Monopolization of Services. * Improper Monopolization of Services.
There is no quick fix, one-size-fits-all solution for security. There is no quick fix, one-size-fits-all solution for security.
When the network in which SIGTRAN protocols are used involves more When a network using SIGTRAN protocols involves more than one party,
than one party, it may not be reasonable to expect that all parties it may not be reasonable to expect that all parties have implemented
have implemented security in a sufficient manner. End-to-end security security in a sufficient manner. End-to-end security should be the
should be the goal; therefore, it is recommended that IPsec or TLS is goal; therefore, it is recommended that IPsec or TLS be used to
used to ensure confidentiality of user payload. Consult [4] for more ensure confidentiality of user payload. Consult [3] for more
information on configuring IPsec services. information on configuring IPsec services.
5. IPsec Usage 5. IPsec Usage
This section is relevant only for SIGTRAN nodes using IPsec to secure This section is only relevant for SIGTRAN nodes using IPsec to secure
communication between SIGTRAN nodes. communication between SIGTRAN nodes.
All SIGTRAN nodes using IPsec MUST implement IPsec ESP [5] in All SIGTRAN nodes using IPsec MUST implement IPsec ESP [4] in
transport mode with non-null encryption and authentication algorithms transport mode with non-null encryption and authentication algorithms
to provide per-packet authentication, integrity protection and to provide per-packet authentication, integrity protection and
confidentiality, and MUST implement the replay protection mechanisms confidentiality, and MUST implement the replay protection mechanisms
of IPsec. In those scenarios where IP layer protection is needed, ESP of IPsec. In those scenarios where IP layer protection is needed,
in tunnel mode SHOULD be used. Non-null encryption should be used ESP in tunnel mode SHOULD be used. Non-null encryption should be
when using IPSec ESP. used when using IPSec ESP.
All SIGTRAN nodes MUST support IKE for peer authentication, All SIGTRAN nodes MUST support IKE for peer authentication,
negotiation of security associations, and key management, using the negotiation of security associations, and key management, using the
IPsec DOI [6]. The IPsec implementations MUST support peer IPsec DOI [5]. The IPsec implementations MUST support peer
authentication using a pre-shared key, and MAY support authentication using a pre-shared key, and MAY support certificate-
certificate-based peer authentication using digital signatures. Peer based peer authentication using digital signatures. Peer
authentication using the public key encryption methods outlined in authentication using the public key encryption methods outlined in
IKE's sections 5.2 and 5.3 [7] SHOULD NOT be used. IKE's sections 5.2 and 5.3 [6] SHOULD NOT be used.
Conformant implementations MUST support both IKE Main Mode and Conformant implementations MUST support IKEs Main Mode and Aggressive
Aggressive Mode. For transport mode, when pre-shared keys are used Mode. For transport mode, when pre-shared keys are used for
for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode
Mode SHOULD NOT be used. When digital signatures are used for SHOULD NOT be used. When digital signatures are used for
authentication, either IKE Main Mode or IKE Aggressive Mode MAY be 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 used. When using ESP tunnel mode, IKE Main Mode MAY be used to
ISAKMP association with identity protection during Phase 1. create an ISAKMP association with identity protection during Phase 1.
When digital signatures are used to achieve authentication, an IKE When digital signatures are used to achieve authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload(s) to specify negotiator SHOULD use IKE Certificate Request Payload(s) to specify
the certification authority (or authorities) that are trusted in the certification authority (or authorities) that is trusted in
accordance with its local policy. IKE negotiators SHOULD use accordance with its local policy. IKE negotiators SHOULD use
pertinent certificate revocation checks before accepting a PKI pertinent certificate revocation checks before accepting a PKI
certificate for use in IKE's authentication procedures. See [11] for certificate for use in IKE's authentication procedures. See [10] for
certificate revocation and [8] for online-checking. certificate revocation and [7] for online-checking.
The Phase 2 Quick Mode exchanges used to negotiate protection for The Phase 2 Quick Mode exchanges used to negotiate protection for
SIGTRAN sessions MUST explicitly carry the Identity Payload fields SIGTRAN sessions MUST explicitly carry the Identity Payload fields
(IDci and IDcr). The DOI provides for several types of identification (IDci and IDcr). The DOI provides for several types of
data. However, when used in conformant implementations, each ID identification data. However, when used in conformant
Payload MUST carry a single IP address and a single non-zero port implementations, each ID Payload MUST carry a single IP address and a
number, and MUST NOT use the IP Subnet or IP Address Range formats. single non-zero port number, and MUST NOT use the IP Subnet or IP
This allows the Phase 2 security association to correspond to Address Range formats. This allows the Phase 2 security association
specific TCP and SCTP connections. to correspond to specific TCP and SCTP connections.
Since IPsec acceleration hardware may only be able to handle a Since IPsec acceleration hardware may only be able to handle a
limited number of active IKE Phase 2 SAs, Phase 2 delete messages may 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 be sent for idle SAs as a means of keeping the number of active Phase
Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message
message SHOULD NOT be interpreted as a reason for tearing down a SHOULD NOT be interpreted as a reason for tearing down a SIGTRAN
SIGTRAN session. Rather, it is preferable to leave the connection up, session. Rather, it is preferable to leave the connection up,
and if additional traffic is sent on it, to bring up another IKE whereby another IKE Phase 2 SA will be brought up to protect it if
Phase 2 SA to protect it. This avoids the potential for continually additional traffic is sent. This avoids the potential of continually
bringing connections up and down. bringing connections up and down.
It should be noted that SCTP supports multi-homed hosts and this It should be noted that SCTP supports multi-homed hosts and this
results in the need for having multiple security associations for one results in the need for having multiple security associations for one
SCTP association. This disadvantage of IPsec has been addressed by SCTP association. This disadvantage of IPsec has been addressed by
[17]. So IPsec implementations used by SIGTRAN nodes SHOULD support [17]. So IPsec implementations used by SIGTRAN nodes SHOULD support
the IPsec feature described in [17]. the IPsec feature described in [17].
6. TLS Usage 6. TLS Usage
This section is relevant only for SIGTRAN nodes using TLS to secure This section is only relevant for SIGTRAN nodes using TLS to secure
the communication between SIGTRAN nodes. the communication between SIGTRAN nodes.
A SIGTRAN node that initiates a SCTP association to another SIGTRAN A SIGTRAN node that initiates a SCTP association to another SIGTRAN
node acts as a TLS client according to [3], and a SIGTRAN node that 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 accepts a connection acts as a TLS server. SIGTRAN peers
TLS for security MUST mutually authenticate as part of TLS session implementing TLS for security MUST mutually authenticate as part of
establishment. In order to ensure mutual authentication, the SIGTRAN TLS session establishment. In order to ensure mutual authentication,
node acting as TLS server must request a certificate from the SIGTRAN the SIGTRAN node acting as TLS server must request a certificate from
node acting as TLS client, and the SIGTRAN node acting as TLS client the SIGTRAN node acting as TLS client, and the SIGTRAN node acting as
MUST be prepared to supply a certificate on request. TLS client MUST be prepared to supply a certificate on request.
[15] requires the support of the cipher suite [14] requires the support of the cipher suite
TLS_RSA_WITH_AES_128_CBC_SHA. SIGTRAN nodes MAY negotiate other TLS TLS_RSA_WITH_AES_128_CBC_SHA. SIGTRAN nodes MAY negotiate other TLS
cipher suites. cipher suites.
TLS MUST be used on all bi-directional streams and the other TLS MUST be used on all bi-directional streams. Other uni-
uni-directional streams MUST NOT be used. directional streams MUST NOT be used.
It should also be noted that a SCTP implementation used for TLS over 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 SCTP MUST support fragmentation of user data and might also need to
support the partial delivery API. This holds even if all SIGTRAN support the partial delivery API. This holds even if all SIGTRAN
messages are small. Furthermore, the 'unordered delivery' feature of messages are small. Furthermore, the 'unordered delivery' feature of
SCTP can not be used in conjunction with TLS. See [15] for more SCTP can not be used in conjunction with TLS. See [14] for more
details. details.
Because TLS only protects the payload the SCTP header and all control Because TLS only protects the payload, the SCTP header and all
chunks are not protected. This can be used for DoS attacks. This is a control chunks are not protected. This can be used for DoS attacks.
general problem with security provided at the transport layer. This is a general problem with security provided at the transport
layer.
The SIGTRAN protocols use the same SCTP port number and payload The SIGTRAN protocols use the same SCTP port number and payload
protocol identifier when run over TLS. A session upgrade procedure protocol identifier when run over TLS. A session upgrade procedure
has to be used to initiate the TLS based communication. has to be used to initiate the TLS based communication.
The session upgrade procedure should be as follows: The session upgrade procedure should be as follows:
o If an ASP has been configured to use TLS it sends a STARTTLS 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 on stream 0 and starts a timer T_TLS. This is the first
message send and the ASP sends no other adaptation layer messages message sent and the ASP sends no other adaptation layer messages
until the TLS based communication has been established. until the TLS based communication has been established.
o If the peer does not support TLS it sends back an ERROR message o If the peer does not support TLS, it sends back an ERROR message
indicating an unsupported message type. In this case the SCTP indicating an unsupported message type. In this case, the SCTP
association is terminated and it is reported to the management association is terminated and it is reported to the management
layer that the peer does not support TLS. layer that the peer does not support TLS.
o If the peer does support TLS it sends back an STARTTLS_ACK o If the peer does support TLS, it sends back a STARTTLS_ACK
message. The client then starts TLS based communication. message. The client then starts TLS based communication.
o If T_TLS expires without getting any of the above answers the o If T_TLS expires without getting any of the above answers, the
association is terminated and the failure is reported to the association is terminated and the failure is reported to the
management layer. management layer.
All SIGTRAN adaptation layers share a common message format. The All SIGTRAN adaptation layers share a common message format. The
STARTTLS message consists of a common header only using the message STARTTLS message consists of a common header only using the message
class 10 and message type 1. The STARTTLS_ACK message uses the same class 10 and message type 1. The STARTTLS_ACK message uses the same
message class 10 and the message type 2. Both messages do not contain message class 10 and the message type 2. Neither messages contain
any parameters. any parameters.
Using this procedure it is possible for a man-in-the-middle to do a 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 denial of service attack by indicating that the peer does not support
TLS. But this kind of attack is always possible for a TLS. But this kind of attack is always possible for a man-in-the-
man-in-the-middle. middle.
7. Support of IPsec and TLS 7. Support of IPsec and TLS
If content of SIGTRAN protocol messages is to be protected, either 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 IPsec ESP or TLS can be used. In both IPsec ESP Transport Mode and
TLS cases the IP header information is neither encrypted nor TLS cases, the IP header information is neither encrypted nor
protected. If IPsec ESP is chosen the SCTP control information is protected. If IPsec ESP is chosen, the SCTP control information is
encrypted and protected whereas if the TLS based solution the SCTP encrypted and protected whereas in the TLS based solution, the SCTP
control information is not encrypted and only protected by SCTP control information is not encrypted and only protected by SCTP
procedures. procedures.
In general, both IPsec and TLS have enough mechanisms to secure the In general, both IPsec and TLS have enough mechanisms to secure the
SIGTRAN communications. SIGTRAN communications.
Therefore, in order to have a secured model working as soon as Therefore, in order to have a secured model working as soon as
possible, the following recommendation is made: A SIGTRAN node MUST possible, the following recommendation is made: A SIGTRAN node MUST
support IPsec and MAY support TLS. support IPsec and MAY support TLS.
8. Peer-to-Peer Considerations 8. Peer-to-Peer Considerations
M2PA, M3UA and SUA support the peer-to-peer model as a generalization 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 to the client-server model which is supported by IUA and M2UA. A
SIGTRAN node running M2PA, M3UA or SUA and operating in the SIGTRAN node running M2PA, M3UA or SUA and operating in the peer-to-
peer-to-peer mode is called a SIGTRAN peer. peer mode is called a SIGTRAN peer.
As with any peer-to-peer protocol, proper configuration of the trust As with any peer-to-peer protocol, proper configuration of the trust
model within a peer is essential to security. When certificates are model within a peer is essential to security. When certificates are
used, it is necessary to configure the trust anchors trusted by the used, it is necessary to configure the trust anchors trusted by the
peer. These trust anchors are likely to be unique to SIGTRAN usage peer. These trust anchors are likely to be unique to SIGTRAN usage
and distinct from the trust anchors that might be trusted for other and distinct from the trust anchors that might be trusted for other
purposes such as Web browsing. In general, it is expected that those purposes such as Web browsing. In general, it is expected that those
trust anchors will be configured so as to reflect the business trust anchors will be configured so as to reflect the business
relationships between the organization hosting the peer and other relationships between the organization hosting the peer and other
organizations. As a result, a peer will typically not be configured organizations. As a result, a peer will not typically be configured
to allow connectivity with any arbitrary peer. When certificate to allow connectivity with any arbitrary peer. When certificate
authentication peers may not be known beforehand, and therefore peer authentication peers may not be known beforehand, peer discovery may
discovery may be required. be required.
Note that IPsec is considerably less flexible than TLS when it comes Note that IPsec is considerably less flexible than TLS when it comes
to configuring trust anchors. Since use of Port identifiers is to configuring trust anchors. Since use of Port identifiers is
prohibited within IKE Phase 1, within IPsec it is not possible to prohibited within IKE Phase 1, it is not possible to uniquely
uniquely configure trusted trust anchors for each application configure trusted trust anchors for each application individually
individually; the same policy must be used for all applications. This within IPsec; the same policy must be used for all applications.
implies, for example, that a trust anchor trusted for use with a This implies, for example, that a trust anchor trusted for use with a
SIGTRAN protocol must also be trusted to protect other protocols (for SIGTRAN protocol must also be trusted to protect other protocols (for
example SNMP). These restrictions can be awkward at best. example SNMP). These restrictions are awkward at best.
When pre-shared key authentication is used with IPsec to protect When pre-shared key authentication is used with IPsec to protect
SIGTRAN based communication, unique pre-shared keys are configured SIGTRAN based communication, unique pre-shared keys are configured
with peers, who are identified by their IP address (Main Mode), or with peers that are identified by their IP address (Main Mode), or
possibly their FQDN (AggressivenMode). As a result, it is necessary possibly their FQDN (AggressivenMode). As a result, it is necessary
for the set of peers to be known beforehand. Therefore, peer for the set of peers to be known beforehand. Therefore, peer
discovery is typically not necessary. discovery is typically not necessary.
The following is intended to provide some guidance on the issue. The following is intended to provide some guidance on the issue.
It is recommended that SIGTRAN peers use the same security mechanism It is recommended that SIGTRAN peers use the same security mechanism
(IPsec or TLS) across all its sessions with other SIGTRAN peers. (IPsec or TLS) across all its sessions with other SIGTRAN peers.
Inconsistent use of security mechanisms can result in redundant Inconsistent use of security mechanisms can result in redundant
security mechanisms being used (e.g. TLS over IPsec) or worse, security mechanisms being used (e.g., TLS over IPsec) or worse,
potential security vulnerabilities. When IPsec is used with a SIGTRAN potential security vulnerabilities. When IPsec is used with a
protocol, a typical security policy for outbound traffic is "Initiate SIGTRAN protocol, a typical security policy for outbound traffic is
IPsec, from me to any, destination port P"; for inbound traffic, the "Initiate IPsec, from me to any, destination port P"; for inbound
policy would be "Require IPsec, from any to me, destination port P". traffic, the policy would be "Require IPsec, from any to me,
Here P denotes one of the registered port numbers for a SIGTRAN destination port P". Here, P denotes one of the registered port
protocol. numbers for a SIGTRAN protocol.
This policy causes IPsec to be used whenever a SIGTRAN peer initiates This policy causes IPsec to be used whenever a SIGTRAN peer initiates
a session to another SIGTRAN peer, and to be required whenever an a session to another SIGTRAN peer, and to be required whenever an
inbound SIGTRAN session occurs. This policy is attractive, since it inbound SIGTRAN session occurs. This policy is attractive, since it
does not require policy to be set for each peer or dynamically 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 modified each time a new SIGTRAN session is created; an IPsec SA is
automatically created based on a simple static policy. Since IPsec automatically created based on a simple static policy. Since IPsec
extensions are typically not available to the sockets API on most extensions are typically not available to the sockets API on most
platforms, and IPsec policy functionality is implementation platforms, and IPsec policy functionality is implementation
dependent, use of a simple static policy is the often the simplest dependent, use of a simple static policy is the often the simplest
route to IPsec-enabling a SIGTRAN peer. route to IPsec-enabling a SIGTRAN peer.
If IPsec is used to secure SIGTRAN peer-to-peer session, IPsec policy If IPsec is used to secure a SIGTRAN peer-to-peer session, IPsec
SHOULD be set so as to require IPsec protection for inbound policy SHOULD be set so as to require IPsec protection for inbound
connections, and to initiate IPsec protection for outbound connections, and to initiate IPsec protection for outbound
connections. This can be accomplished via use of inbound and outbound connections. This can be accomplished via use of inbound and
filter policy. outbound filter policy.
9. Security Considerations 9. Security Considerations
This documents discusses the usage of IPsec and TLS for securing This document discusses the usage of IPsec and TLS for securing
SIGTRAN traffic. SIGTRAN traffic.
10. IANA Considerations 10. IANA Considerations
The message class 10 has to be reserved for STARTTLS messages for all The message class 12 has been reserved in the Signaling User Adaption
SIGTRAN adaptation layers. For this message class, message type 1 has Layer Assignments Registry. For this message class, message type 1
to be reserved for the STARTTLS message, message type 2 for the has been reserved for the STARTTLS message, and message type 2 for
STARTTLS_ACK message. the STARTTLS_ACK message.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank B. Aboba, K. Morneault and many The authors would like to thank B. Aboba, K. Morneault and many
others for their invaluable comments and suggestions. others for their invaluable comments and suggestions.
12. References 12. References
12.1 Normative References 12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 12.2. Informative References
9, RFC 2026, October 1996.
12.2 Informative References
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2246, January 1999.
1999.
[4] Kent, S. and R. Atkinson, "Security Architecture for the [3] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998. (ESP)", RFC 2406, November 1998.
[6] Piper, D., "The Internet IP Security Domain of Interpretation [5] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998. for ISAKMP", RFC 2407, November 1998.
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[8] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, [7] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams,
"X.509 Internet Public Key Infrastructure Online Certificate "X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", RFC 2560, June 1999. Status Protocol - OCSP", RFC 2560, June 1999.
[9] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[10] Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom, [9] Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom,
"ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001. "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.
[11] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 [10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
[12] Stone, J., Stewart, R. and D. Otis, "Stream Control [11] Stone, J., Stewart, R. and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309, Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002. September 2002.
[13] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J. [12] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J.
Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)
- User Adaptation Layer", RFC 3331, September 2002. - User Adaptation Layer", RFC 3331, September 2002.
[14] Sidebottom, G., Morneault, K. and J. Pastor-Balbas, "Signaling [13] Sidebottom, G., Ed., Morneault, K., Ed. and J. Pastor-Balbas,
System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Ed., "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -
Layer (M3UA)", RFC 3332, September 2002. User Adaptation Layer (M3UA)", RFC 3332, September 2002.
[15] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer [14] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436, Security over Stream Control Transmission Protocol", RFC 3436,
December 2002. December 2002.
[16] George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", [15] George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer", Work
draft-ietf-sigtran-m2pa-08 (work in progress), April 2003. in Progress, February 2004.
[17] Bellovin, S., "On the Use of SCTP with IPsec", [16] Loughney, J., "Signalling Connection Control Part User
draft-ietf-ipsec-sctp-06 (work in progress), April 2003. 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 13. Authors' Addresses
John Loughney John Loughney
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
EMail: john.loughney@nokia.com EMail: john.loughney@nokia.com
Michael Tuexen Michael Tuexen (editor)
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
EMail: tuexen@fh-muenster.de EMail: tuexen@fh-muenster.de
Javier Pastor-Balbas Javier Pastor-Balbas
Ericsson Ericsson Espana S.A.
Via de los Poblados, 13 Via de los Poblados, 13
28033 Madrid 28033 Madrid
Spain Spain
EMail: j.javier.pastor@ericsson.com EMail: j.javier.pastor@ericsson.com
Intellectual Property Statement 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 The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at ietf-
Director. ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assignees.
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.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/