draft-ietf-sigtran-security-01.txt   draft-ietf-sigtran-security-02.txt 
Network Working Group J. Loughney Network Working Group J. Loughney
Internet-Draft Nokia Research Center Internet-Draft Nokia Research Center
Expires: August 1, 2003 M. Tuexen Expires: July 2, 2003 M. Tuexen
Siemens AG Univ. of Applied Sciences Muenster
J. Pastor-Balbas J. Pastor-Balbas
Ericsson Ericsson
January 31, 2003 January 2003
Security Considerations for SIGTRAN Protocols Security Considerations for SIGTRAN Protocols
draft-ietf-sigtran-security-01.txt draft-ietf-sigtran-security-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as groups may also distribute working documents as Internet-Drafts.
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 1, 2003. This Internet-Draft will expire on July 2, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This documents discusses how TLS and IPSec can be used to secure the This documents discusses how TLS and IPSec can be used to secure the
communication for SIGTRAN protocols. The support of IPSec is communication for SIGTRAN protocols. The support of IPSec is
mandatory for all nodes running SIGTRAN protocols and the support of mandatory for all nodes running SIGTRAN protocols and the support of
TLS is optional. TLS is optional.
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
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 IUA
o service provider equipment only. This is the case for M2UA, M2PA, o service provider equipment only. This is the case for M2UA, M2PA,
skipping to change at page 4, line 36 skipping to change at page 5, line 39
* Integrity of user data transport. * Integrity of user data transport.
* Confidentiality of user data. * Confidentiality of user data.
o Non-repudation. o Non-repudation.
o System Security, avoidance of: o System Security, avoidance of:
* Unauthorized use. * Unauthorized use.
* Unappropiate use. * Inappropiate 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 achieve a secured communication. To get this
goal, we will explore the different security options that regarding goal, we will explore the different security options that regarding
communication exist. communication exist.
skipping to change at page 5, line 17 skipping to change at page 6, line 18
* 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 the network in which SIGTRAN protocols are used involves more
than one party, it may not be reasonable to expect that all parties than one party, it may not be reasonable to expect that all parties
have implemented security in a sufficient manner. End-to-end have implemented security in a sufficient manner. End-to-end security
security should be the goal; therefore, it is recommended that IPSec should be the goal; therefore, it is recommended that IPSec or TLS is
or TLS is used to ensure confidentiality of user payload. Consult used to ensure confidentiality of user payload. Consult [4] for more
[4] 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 relevant only for SIGTRAN nodes using IPSec to secure
communication between SIGTRAN nodes. communication between SIGTRAN nodes.
All SIGTRAN nodes using IPSec MUST support IPSec ESP [5] in transport All SIGTRAN nodes using IPSec MUST support IPSec ESP [5] in transport
mode with non-null encryption and authentication algorithms to mode with non-null encryption and authentication algorithms to
provide per-packet authentication, integrity protection and provide per-packet authentication, integrity protection and
confidentiality, and MUST support the replay protection mechanisms of confidentiality, and MUST support the replay protection mechanisms of
IPSec. In those scenarios where IP layer protection is needed, ESP IPSec. In those scenarios where IP layer protection is needed, ESP in
in tunnel mode SHOULD be used. tunnel mode SHOULD be used.
These nodes MUST support IKE for peer authentication, negotiation of These nodes MUST support IKE for peer authentication, negotiation of
security associations, and key management, using the IPSec DOI [6]. security associations, and key management, using the IPSec DOI [6].
The IPSec implementations MUST support peer authentication using a The IPSec implementations MUST support peer authentication using a
pre-shared key, and MAY support certificate-based peer authentication pre-shared key, and MAY support certificate-based peer authentication
using digital signatures. Peer authentication using the public key using digital signatures. Peer authentication using the public key
encryption methods outlined in IKE's sections 5.2 and 5.3 [7] SHOULD encryption methods outlined in IKE's sections 5.2 and 5.3 [7] SHOULD
NOT be used. NOT be used.
Conformant implementations MUST support both IKE Main Mode and Conformant implementations MUST support both IKE Main Mode and
Aggressive Mode. For transport mode, when pre-shared keys are used Aggressive Mode. For transport mode, when pre-shared keys are used
for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main
Mode SHOULD NOT be used. When digital signatures are used for Mode 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 used. When using ESP tunnel mode, IKE Main Mode MAY be used to create
create ISAKMP association with identity protection during Phase 1. 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 certificate authority (or authorities) that are trusted in the certificate authority (or authorities) that are 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. certificate for use in IKE's authentication procedures.
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 (IDci and IDcr). The DOI provides for several types of identification
identification data. However, when used in conformant data. However, when used in conformant implementations, each ID
implementations, each ID Payload MUST carry a single IP address and a Payload MUST carry a single IP address and a single non-zero port
single non-zero port number, and MUST NOT use the IP Subnet or IP number, and MUST NOT use the IP Subnet or IP Address Range formats.
Address Range formats. This allows the Phase 2 security association This allows the Phase 2 security association to correspond to
to correspond to specific TCP and SCTP connections. 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 2 SAs to a minimum. The receipt of an IKE Phase 2 delete 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 message SHOULD NOT be interpreted as a reason for tearing down a
SIGTRAN session. Rather, it is preferable to leave the connection SIGTRAN session. Rather, it is preferable to leave the connection up,
up, and if additional traffic is sent on it, to bring up another IKE 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 Phase 2 SA to protect it. This avoids the potential for 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
[15]. So IPSec implementations used by SIGTRAN nodes SHOULD support [15]. So IPSec implementations used by SIGTRAN nodes SHOULD support
the IPSec feature described in [15]. the IPSec feature described in [15].
6. TLS Usage 6. TLS Usage
This section is relevant only for SIGTRAN nodes using TLS to secure This section is relevant only 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 [3], and a SIGTRAN node that
accepts a connection acts as a TLS server. SIGTRAN peers accepts a connection acts as a TLS server. SIGTRAN peers implementing
implementing TLS for security MUST mutually authenticate as part of TLS for security MUST mutually authenticate as part of TLS session
TLS session establishment. In order to ensure mutual authentication, establishment. In order to ensure mutual authentication, the SIGTRAN
the SIGTRAN node acting as TLS server must request a certificate from node acting as TLS server must request a certificate from the SIGTRAN
the SIGTRAN node acting as TLS client, and the SIGTRAN node acting as node acting as TLS client, and the SIGTRAN node acting as TLS client
TLS client MUST be prepared to supply a certificate on request. MUST be prepared to supply a certificate on request.
[13] requires the support of the cipher suite [13] 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 and the other
uni-directional streams MUST NOT be used. uni-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. See [13] for more details. messages are small. See [13] for more details.
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 used to initiate the TLS based communication. has to be used to initiate the TLS based communication.
Because TLS only protects the payload the SCTP header and all control 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 chunks are not protected. This can be used for DoS attacks. This is a
a general problem with security provided at the transport layer. general problem with security provided at the transport layer.
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 in transport mode or TLS can be used. In both cases the IP IPSec ESP or TLS can be used. In both IPsec ESP Transport Mode and
header information is neither encrypted nor protected. If IPSec ESP TLS cases the IP header information is neither encrypted nor
is chosen the SCTP control information is encrypted and protected protected. If IPSec ESP is chosen the SCTP control information is
whereas if the TLS based solution the SCTP control information is not encrypted and protected whereas if the TLS based solution the SCTP
encrypted and only protected by SCTP procedures. control information is not encrypted and only protected by SCTP
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. Nevertheless, due to the wider deployment of SIGTRAN communications.
IPSec, it is foreseen a faster development and market support for
this protocol.
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
skipping to change at page 8, line 15 skipping to change at page 9, line 15
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, and therefore peer
discovery may be required. discovery may 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 root CAs. Since use of Port identifiers is prohibited to configuring root CAs. Since use of Port identifiers is prohibited
within IKE Phase 1, within IPSec it is not possible to uniquely within IKE Phase 1, within IPSec it is not possible to uniquely
configure trusted root CAs for each application individually; the configure trusted root CAs for each application individually; the
same policy must be used for all applications. This implies, for same policy must be used for all applications. This implies, for
example, that a root CA trusted for use with a SIGTRAN protocol must example, that a root CA trusted for use with a SIGTRAN protocol must
also be trusted to protect SNMP. These restrictions can be awkward also be trusted to protect SNMP. These restrictions can be awkward at
at best. Since TLS supports application-level granularity in best.
certificate policy, TLS SHOULD be used to protect SIGTRAN sessions
between administrative domains. IPSec is most appropriate for
intra-domain usage when pre-shared keys are used as a security
mechanism.
When pre-shared key authentication is used with IPSec to protect 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, who 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 potential security vulnerabilities. When IPSec is used with a SIGTRAN
SIGTRAN protocol, a typical security policy for outbound traffic is protocol, a typical security policy for outbound traffic is "Initiate
"Initiate IPSec, from me to any, destination port P"; for inbound IPSec, from me to any, destination port P"; for inbound traffic, the
traffic, the policy would be "Require IPSec, from any to me, policy would be "Require IPSec, from any to me, destination port P".
destination port P". Here P denotes one of the registered port Here P denotes one of the registered port numbers for a SIGTRAN
numbers for a SIGTRAN protocol. 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 SIGTRAN peer-to-peer session, IPSec policy
SHOULD be set so as to require IPSec protection for inbound 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 connections. This can be accomplished via use of inbound and outbound
outbound filter policy. filter policy.
9. Security Considerations 9. Security Considerations
This documents discusses the usage of IPSec and TLS for securing This documents discusses the usage of IPSec and TLS for securing
SIGTRAN traffic. SIGTRAN traffic.
10. IANA Considerations 10. IANA Considerations
No actions have to be taken by IANA. No actions have to be taken by IANA.
skipping to change at page 10, line 42 skipping to change at page 11, line 39
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
Siemens AG Univ. of Applied Sciences Muenster
Hofmannstr. 51 Stegerwaldstr. 39
81359 Munich 48565 Steinfurt
Germany Germany
EMail: Michael.Tuexen@siemens.com EMail: tuexen@fh-muenster.de
Javier Pastor-Balbas Javier Pastor-Balbas
Ericsson Ericsson
Avenida de los Poblados, 13 Avenida de los Poblados, 13
28033 Madrid 28033 Madrid
Spain Spain
EMail: javier.pastor-balbas@ece.ericsson.se EMail: javier.pastor-balbas@ece.ericsson.se
Intellectual Property Statement Intellectual Property Statement
 End of changes. 

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