| draft-ietf-sigtran-security-02Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-security-02.txt.
Network Working Group J. Loughney
Internet-Draft Nokia Research Center
Expires: July 2, 2003 M. Tuexen
Univ. of Applied Sciences Muenster
J. Pastor-Balbas
Ericsson
January 2003
Security Considerations for SIGTRAN Protocols
draft-ietf-sigtran-security-02.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 July 2, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This documents discusses how TLS and IPSec can be used to secure the
communication for SIGTRAN protocols. The support of IPSec is
mandatory for all nodes running SIGTRAN protocols and the support of
TLS is optional.
Loughney, et al. Expires July 2, 2003 [Page 1]
Internet-Draft SIGTRAN Security January 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Convention . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security in telephony networks . . . . . . . . . . . . . . . . 4
4. Threats and Goals . . . . . . . . . . . . . . . . . . . . . . 5
5. IPSec Usage . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Support of IPSec and TLS . . . . . . . . . . . . . . . . . . . 8
8. Peer-to-Peer Considerations . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . . 10
Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 13
Loughney, et al. Expires July 2, 2003 [Page 2]
Internet-Draft SIGTRAN Security January 2003
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 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.
ISDN: Integrated Services Digital Network.
IUA: ISDN Q.921 User Adaptation Layer.
M2PA: SS7 MTP2 Peer-to-Peer User Adaptation Layer.
Loughney, et al. Expires July 2, 2003 [Page 3]
Internet-Draft SIGTRAN Security January 2003
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].
3. Security in telephony networks
The security in telephony networks is mainly based on the trusted
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.
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 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.
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.
Loughney, et al. Expires July 2, 2003 [Page 4]
Internet-Draft SIGTRAN Security January 2003
This description applies to telephony networks operated by a single
operator but 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 threads 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:
o Communication Security:
* Authentication of peers.
* Integrity of user data transport.
* Confidentiality of user data.
o Non-repudation.
o System Security, avoidance of:
* Unauthorized use.
* Inappropiate 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 achieve a secured communication. To get this
goal, we will explore the different security options that regarding
communication exist.
All SIGTRAN protocols use the Stream Control Transmission Protocol
(SCTP) being defined in [8] and [10] as its transport protocol. SCTP
provides certain transport related security features, such as
Loughney, et al. Expires July 2, 2003 [Page 5]
Internet-Draft SIGTRAN Security January 2003
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 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 [4] for more
information on configuring IPSec services.
5. IPSec Usage
This section is relevant only for SIGTRAN nodes using IPSec to secure
communication between SIGTRAN nodes.
All SIGTRAN nodes using IPSec MUST support IPSec ESP [5] 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. In those scenarios where IP layer protection is needed, ESP in
tunnel mode SHOULD be used.
These nodes MUST support IKE for peer authentication, negotiation of
security associations, and key management, using the IPSec DOI [6].
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 [7] SHOULD
NOT be used.
Conformant implementations MUST support both IKE 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
ISAKMP association with identity protection during Phase 1.
When digital signatures are used to achieve authentication, an IKE
Loughney, et al. Expires July 2, 2003 [Page 6]
Internet-Draft SIGTRAN Security January 2003
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
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
[15]. So IPSec implementations used by SIGTRAN nodes SHOULD support
the IPSec feature described in [15].
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 [3], 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.
Loughney, et al. Expires July 2, 2003 [Page 7]
Internet-Draft SIGTRAN Security January 2003
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 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.
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.
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 if 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.
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 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
Loughney, et al. Expires July 2, 2003 [Page 8]
Internet-Draft SIGTRAN Security January 2003
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.
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 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
Loughney, et al. Expires July 2, 2003 [Page 9]
Internet-Draft SIGTRAN Security January 2003
connections. This can be accomplished via use of inbound and outbound
filter policy.
9. Security Considerations
This documents discusses the usage of IPSec and TLS for securing
SIGTRAN traffic.
10. IANA Considerations
No actions have to be taken by IANA.
11. Acknowledgements
The authors would like to thank B. Aboba, K. Morneault and many
others for their invaluable comments and suggestions.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
Informative References
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[4] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[6] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[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,
Loughney, et al. Expires July 2, 2003 [Page 10]
Internet-Draft SIGTRAN Security January 2003
"ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.
[10] Stone, J., Stewart, R. and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
[11] 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.
[12] 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.
[13] Tuexen, M., Jungmaier, A. and E. Rescorla, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436,
December 2002.
[14] George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer",
draft-ietf-sigtran-m2pa-07 (work in progress), January 2003.
[15] Bellovin, S., "On the Use of SCTP with IPsec",
draft-ietf-ipsec-sctp-04 (work in progress), October 2002.
Authors' Addresses
John Loughney
Nokia Research Center
PO Box 407
FIN-00045 Nokia Group
Finland
EMail: [email protected]
Michael Tuexen
Univ. of Applied Sciences Muenster
Stegerwaldstr. 39
48565 Steinfurt
Germany
EMail: [email protected]
Loughney, et al. Expires July 2, 2003 [Page 11]
Internet-Draft SIGTRAN Security January 2003
Javier Pastor-Balbas
Ericsson
Avenida de los Poblados, 13
28033 Madrid
Spain
EMail: [email protected]
Loughney, et al. Expires July 2, 2003 [Page 12]
Internet-Draft SIGTRAN Security January 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
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
Loughney, et al. Expires July 2, 2003 [Page 13]
Internet-Draft SIGTRAN Security January 2003
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 July 2, 2003 [Page 14]
| ||||||||||||||||
| Last modified: Thu, 28 Nov 2024 10:24:08 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||