Internet Engineering Task Force I. Brown
INTERNET-DRAFT University College London
Expiration Date: 15 August 2002 15 February 2002
Securing prioritised emergency traffic
Ian Brown
Department of Computer Science
University College London
Gower Street
London WC1E 6BT
United Kingdom
draft-brown-ieprep-sec-00.txt
I.Brown@cs.ucl.ac.uk
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.
Copyright
Copyright (C) Internet Society 2001. All rights reserved.
Reproduction or translation of the complete document, but not of
extracts, including this notice, is freely permitted.
Abstract
The International Emergency Preference Scheme and International
Emergency Multimedia Service are ITU recommendations that give
priority to emergency communications related to disaster recovery.
This memo describes the security requirements of providing equivalent
functionality in private and public IP networks.
Brown UCL [Page 1]
Internet-Draft IEPS security 5 July 2001
Table of Contents
1 Introduction 2
2 Objective 2
3 Background 3
3.1 IPSEC 3
3.2 TLS 4
3.3 SIP and RTP 5
4 Authentication 6
4.1 PIN-based 6
4.2 Cryptographic 6
4.3 Fraud Detection 7
5 Recommended Approach 7
6 Scenarios 7
6.1 PSTN-to-IP-to-PSTN 7
6.2 PSTN-to-IP 8
6.3 IP-to-PSTN 9
6.4 Pure IP 9
7 Recommendations 10
8 Security Considerations 10
9 References 10
10 Full Copyright Statement 11
1. Introduction
The International Emergency Preference Scheme is a set of mechanisms
specified for use in the Public Switched Telephone Network to
increase the probability of completion for certain telephone calls
during emergencies such as hurricanes or earthquakes. Calls are given
a higher probability of completion by exchanges waiting for resources
to become available rather than rejecting the call attempt when
congestion is encountered, and attempting to use alternate carrier
routing if network congestion is encountered. IEPS calls are also
exempted from restrictive network management controls [ITU00a]. The
Government Emergency Telecommunications System (GETS) already
operating in the United States includes these mechanisms.
As telecommunications providers start using the Internet Protocol
across their backbone networks, IEPS support is a feature they may
wish to extend to the new transport layers to continue their ability
to provide this service to support emergency recovery operations
through service level agreements. The end-points of telephone calls
may also start migrating to public or private IP networks. An effort
is underway in the IETF to standardise mechanisms to provide IEPS
support across these composite networks [Carlberg00].
A companion ITU effort has also developed an International Emergency
Multimedia Service that will provide similar functionality across a
much wider range of applications in packet-switched networks [ITU01].
This document considers the security requirements implicit in such
support in more detail. We begin by outlining our security objectives
Brown UCL [Page 2]
Internet-Draft IEPS security 5 July 2001
and considering the background of existing IP security protocols that
can be used to meet these objectives. We then describe our
recommended approach and show how secure IEPS/IEMS support can be
provided in different configurations of PSTN and IP networks. We
conclude with recommendations to implementers of IEPS/IEMS-enabled IP
networks.
2. Objective
There are two primary security requirements for IEPS/IEMS: preventing
theft and denial of service by unauthorised users and ensuring the
integrity of calls using the system.
As far as possible, we wish to build on the security mechanisms
within existing IEPS systems and existing Internet standards.
Ideally, IEPS users should not require separate authorisation
mechanisms for the PSTN and IP networks. We also aim to minimise
complexity of the system in order to reduce cost and maximise
security. Finally, we want to provide a flexible framework within
which telecommunications providers may use the methods best suited to
their networks.
3. Background
Several security protocols are already in use by IP telephony
applications. IPSEC and TLS are general-purpose network and transport
layer protocols that ensure the confidentiality and integrity of
communications. SIP and RTP are application-layer protocols that
define call signalling and content formats, and use application-
specific security extensions. This background section describes these
protocols in more detail. Further background information is available
in a report from Telcordia [Telcordia00].
3.1 IPSEC
The Internet Protocol Security (IPSEC) working group of the
Internet Engineering Task Force is completing standardisation of
security mechanisms for IP packets. Their work is a mandatory part
of IPv6 and can also be supported using option fields in IPv4. The
specifications provide an algorithm-independent framework into
which specific cryptographic methods can be inserted [Thayer98].
Two mechanisms are used to protect packet data. The Authentication
Header (AH) allows data to be signed, assuring its authenticity
and integrity but not secrecy. The Encapsulating Security Payload
(ESP) provides confidentiality. Both mechanisms can be used in
tunnel mode (an entire IP packet is encapsulated within another
before applying the security services) or transport mode (only
higher-layer data is secured). ESP mode can also incorporate
authentication procedures, but AH allows the protection of
immutable and predictable IP headers, which ESP cannot provide in
transport mode.
Brown UCL [Page 3]
Internet-Draft IEPS security 5 July 2001
The Authentication Header goes between the IP and higher layer
headers of a packet, and contains information that the recipient
can use to authenticate the sender and contents of the rest of the
packet. This is more efficient than applying transformations to
the entire packet. An anti-replay service can prevent old traffic
being resent to a host, using sequence numbers in the
authentication header.
ESP is used to encrypt data before it leaves the sender, hiding
its contents until it reaches the receiver, who decrypts it using
the secret key they share with the sender. In tunnel mode, the
source and destination of the encapsulated packet can be hidden,
so preventing some traffic analysis attacks. The padding used to
ensure the data being encrypted is the correct length for use with
a specific cipher can also be extended to conceal the true length
of that data, providing further traffic flow confidentiality.
Transport mode is simpler, and normally used between end systems.
If a security gateway is at either end of a connection, tunnel
mode must be used. Tunnel mode is also less disruptive to the
current Internet infrastructure, as packets look entirely normal
to routers. Only at the end of their journey are the encrypted and
authenticated contents of a packet revealed. Security gateways can
forward such packets to hosts without IPSEC support.
AH and ESP both require communicating hosts to share secret keys
to authenticate and encrypt transmitted data. It is relatively
simple to manually configure hosts with fixed keys, but this is
completely unscalable. Hosts also need to agree on the
cryptographic systems they both understand.
The Internet Key Exchange (IKE) allows two hosts to agree on these
parameters [Harkins98]. After setting up a secure ISAKMP (Internet
Security Association and Key Management Protocol) link
[Maughan98], IKE hosts generate keys for, and negotiate, IPSEC
Security Associations. Each association is used by network code to
select the transformations it will apply to each packet. The
exchange is finally authenticated to prevent a man-in-the-middle
attack, and optionally identify each host. Various types of
certificate can be used at this stage to increase the security of
the authentication.
ITU Recommendations H.323 and H.248, IETF Megaco, and AT&T
PacketCable use IPSEC to protect signalling messages. H.323's call
control messages and PacketCable's call content can also be
secured using IPSEC.
3.2 TLS
Secure Sockets Layer (SSL) is probably the most widely used
security standard on the Internet. It is a transport-level
protocol designed by Netscape to enable secure communication
Brown UCL [Page 4]
Internet-Draft IEPS security 5 July 2001
between a Web browser and server. Almost all secure Web access
takes place over a SSL connection.
TLS (Transport Layer Security) is the standardised successor to
SSL [Dierks99]. Its goal is to provide privacy and data integrity
between two communicating applications. TLS is composed of two
protocols: the record protocol, which provides a private and
reliable connection, and the handshake protocol, used to
authenticate client and server and negotiate cryptographic
algorithms and keys.
The record protocol fragments data into blocks of 214 bytes or
less. Each block can be compressed, encrypted, and authenticated
using a MAC (Message Authentication Code). A key calculation
algorithm is used to generate keys, Initialisation Vectors for the
encryption and MAC secrets from secret parameters supplied by the
handshake protocol.
The handshake protocol negotiates each session: a session
identifier, compression method, cipher specification (encryption
and MAC algorithms), 48-byte master secret, a resumable flag and
optional certificates for either party. A resumable session can be
used to set up several connections. A session can be renegotiated
at any time during a connection. Alert messages of varying levels
may be sent; "fatal" alerts cause the connection to be terminated
and session invalidated for future connections.
H.323 can use TLS to protect call signalling and control messages.
3.3 SIP and RTP
The Session Initiation Protocol allows participants to be invited
to multimedia videoconferencing sessions using a simple ASCII-
based protocol. Extensions have been defined to allow
authenticated and private invitations using the secure e-mail
S/MIME and PGP formats [Handley99]. These invitations can also
contain keys used to encrypt the conference material itself using
the Real-time Transport Protocol [Schulzrinne96]. The now-
discredited Data Encryption Standard is the standardised cipher
used for this encryption. RTP does not provide authentication
services, and originally expected all of its security capabilities
to be superseded by services provided by IPSEC once that becomes
widespread. A Secure RTP standard is now being defined that allows
RTP packets to be encrypted and authenticated whilst still
allowing header compression, which is useful for low-capacity
wireless links [Blom01].
PacketCable can also use the RC4 encryption algorithm with RTP to
protect call content.
4. Authentication
Brown UCL [Page 5]
Internet-Draft IEPS security 5 July 2001
IEPS/IEMS users must demonstrate they are authorised to use the
service before placing a call, in a similar way to calling card
owners. GETS users are authenticated by a twelve-digit personal
identification number (PIN); fraud detection techniques are also used
to watch for suspicious usage patterns.
IP devices could use cryptographic methods to authenticate their
users to the network. It would also be possible to reuse the
authentication framework from the next generation mobile phone
protocol 3GPP [ETSI00].
4.1 PIN-based
GETS users are currently authenticated by an interexchange carrier
contracted to provide the service using a PIN entered through the
originating telephone. GETS users dial a toll-free number
beginning with the non-geographic area code 710, then enter a PIN
and the number they wish to call. Databases of authorised PINs are
regularly distributed to the interexchange carriers by the
responsible government agency, the National Communications System.
This system relies on physical line security to protect PINs and
the carrier's infrastructure security to prevent call hijacking.
This system can be used virtually unchanged with IEPS over IP. It
could even be extended for use as a password with dial-up Internet
connections. Carriers just need to ensure their networks recognise
an equivalent of the 710 area code, verify such calls with an
authentication centre, and use the resulting approval or non-
approval to decide whether to give the call priority.
Users could also be provided with one-time PIN devices such as
RSA's SecurID card. This calculates a new PIN every 60 seconds
using a secret shared between the card and the authorisation
centre along with a user-entered PIN.
4.2 Cryptographic
More secure authentication of IP devices is possible using
cryptographic mechanisms. Authorised IEPS/IEMS users would be
provided with a shared secret key or digital certificate to
authenticate themselves to IEPS-capable networks. To protect these
secret keys and allow them to be used from a wide variety of
locations, they would almost certainly be stored on a smartcard.
This would require that communications devices contain smartcard
readers.
One way to achieve widespread interoperable authentication with
PSTN and IP devices would be to use 3GPP Subscriber Identification
Modules. The user's home network would provide priority service to
authorised users locally, and signal to remote networks that a
given roaming user was authorised for emergency preference
service.
Brown UCL [Page 6]
Internet-Draft IEPS security 5 July 2001
4.3 Fraud detection
The IEPS/IEMS threat model is mostly concerned with theft of
service. Because network operators can limit total prioritised
calls to a small percentage of their total capacity, prevention of
all unauthorised usage is not an absolute priority. Fraud
detection techniques can be used later to identify and update
compromised PINs and systems, and to attempt to trace the
perpetrators.
Techniques used by GETS operators include detection of
simultaneous use of a given PIN, use of one PIN from distant
locations within a short time period, and other more sophisticated
usage pattern analysis. While fraudulent use can often be
recognised in real-time, carriers do not terminate such calls
immediately but instead log details for later investigation.
The impact of denial of service attacks can be reduced by
authorising users with the minimum resources required. Devices
originating such attacks may be temporarily ignored by an
authentication service.
5. Recommended Approach
We believe that the following protocols best meet our objectives:
IPSEC should be used to protect the confidentiality and integrity of
call signalling and content. This protocol has gone through nearly 10
years of development and analysis. Its long development period and
potential widespread use have led to far more detailed scrutiny than
application-specific protocols from large numbers of independent
security engineers, who have discovered and corrected several flaws.
And unlike TLS, IPSEC support is mandatory in all IPv6 devices. This
reduces the complexity and potential security problems of adding
security libraries and code to individual applications. IPSEC is
widely supported by existing IP telephony protocols. Whilst Secure
RTP offers some advantages for audio, the far wider requirements of
IEMS make it an unsuitable general solution here.
Standardizing on this protocol also removes the potential PKI
duplication necessary in supporting other protocols. Although IPSEC,
TLS and SIP can all theoretically use X.509 certificates [ITU00b],
getting them to inter-work correctly in practice might cause
difficulties in initial implementations.
PIN-based authorization should remain the primary access control
mechanism. This removes the need for users to remember how different
mechanisms and secrets work in placing calls using PSTN or IP
telephones รป and from needing to work out which is which! Where
possible, IEPS/IEMS authorization should be integrated with existing
authentication protocols to reduce unnecessary overhead. Fraud
Brown UCL [Page 7]
Internet-Draft IEPS security 5 July 2001
detection should continue to be used to detect unauthorized use of
the system. In the longer term, smartcard/SIM-based authentication
may become more feasible.
6. Scenarios
This section examines in more detail how our recommended approach
would be applied in the primary scenarios identified for IEPS use
[Carlberg00].
6.1 PSTN-to-IP-to-PSTN
The most imminent scenario for IEPS-over-IP use is where a
carrier's backbone network uses IP to transport calls between two
PSTN domains. Authorisation of the call originator occurs as
before using a PIN entered through the telephone. The carrier then
uses traffic engineering to give enhanced priority to that data as
it enters and flows across the IP backbone network. It uses the
IEPS telephony methods to increase the likelihood of successful
call set-up at its gateway back into the PSTN. The carrier uses
its standard infrastructure security to prevent unauthorised use
of the facility and protect the integrity of calls.
If the carrier has IP peering arrangements with other networks
that are closer to a call's end-point, the prioritised traffic can
flow directly onto their networks rather than first travelling
back into the PSTN. Peering agreements must describe the level of
prioritised traffic that may travel between the two networks, and
a method of signalling that traffic priority. DiffServ codepoints
[Blake98] are a convenient way to do so. The ingress points will
perform traffic policing to ensure compliance with the agreement
and limit the theft of service possible given compromise of the
originating network.
For added confidentiality and integrity protection, the carrier
may choose to tunnel the traffic between the backbone ingress and
egress points using IPSEC.
6.2 PSTN-to-IP
An even simpler scenario is where the end-point of the call is an
IP device. Again, the caller is authorised using a PIN, and the
resulting voice traffic marked as prioritised by the carrier's
PSTN-IP gateway. The use of a standardised marking is more
important here, as the traffic is likely to flow across several IP
networks to its destination. At each gateway, the ingress point
performs traffic policing.
If a network in the path to the final traffic destination does not
support IEPS Quality of Service prioritisation, the call will lose
its priority on that network. Unless that network performs traffic
policing, other networks later in the route will be unwilling to
Brown UCL [Page 8]
Internet-Draft IEPS security 5 July 2001
accept marked traffic. They would otherwise be open to a massive
theft of service threat. If traffic policing is performed and IEPS
packets are accepted, the call will regain priority as it moves
back onto IEPS-capable networks.
To protect the confidentiality and integrity of the call traffic
as it travels across diverse networks, the PSTN-IP gateway should
tunnel it directly to the endpoint using IPSEC. The outer packet
must be marked to allow recognition by intermediate routers.
6.3 IP-to-PSTN
An IP device placing a call to a PSTN telephone must first
discover an appropriate PSTN gateway. While the details of that
discovery procedure are outside the scope of this document, the
simplest method is to connect to a known address within the user's
ISP network, which then carries out the appropriate forwarding.
The device's first-hop network must recognise that its user is
allowed IEPS/IEMS service. This can be integrated into the
network's login procedure: only certain users will be so
authorised. Alternatively the user may authenticate themselves to
the network using the same procedure as on the PSTN: by dialling a
known number and PIN.
In the first case, the user requires a mechanism to start the IP
device marking outgoing packets as prioritised. In the second, the
network may signal to the device that it should do so, or mark the
packets itself at its ingress point.
An IEPS-compliant gateway back into the PSTN recognises the
prioritised IP traffic and uses IEPS telephony methods to increase
the likelihood of successful call setup. These methods can also be
used to prioritise the first-hop telephone call connecting an IP
device using a dial-up connection to an ISP. If the signalling and
content gateways are not co-located, the former must securely
instruct the latter to route the call traffic onto the circuit set
up by the signalling gateway.
To protect the confidentiality and integrity of the call traffic,
it should be tunnelled by the originating IP device using IPSEC to
the IP-PSTN gateway. This will also allow devices on non-IEPS
compatible networks to authorise themselves to an IEPS-supporting
IP-PSTN gateway using any of the standard IPSEC authentication
mechanisms. Their traffic on the PSTN side of the connection will
then be prioritised.
6.4 Pure IP
The simplest scenario is that both end-points of an IEPS/IEMS call
are IP devices linked by public or private internets. Again, the
call originator must mark call traffic packets as prioritised. The
Brown UCL [Page 9]
Internet-Draft IEPS security 5 July 2001
ingress point of their first-hop network must recognise that the
originator is authorised for this service, and allow the marked
packets to flow across its network. As before, packet
prioritisation will be lost if the packets must flow across a non-
IEPS-compliant network. For this reason, IEPS-compatible networks
may attempt to use policy-based routing to keep such traffic on
IEPS-capable networks.
For maximum assurance of call integrity and confidentiality, there
should be an end-to-end IPSEC link between the originator and
recipient of a call.
7. Recommendations
We recommend that IEPS/IEMS-compliant networks should meet the
following requirements:
* IEPS/IEMS users should be authorised using a PIN or as part of
their network sign-on procedure.
* Authorised users may send packets marked as IEPS/IEMS traffic.
Their ingress network may alternatively mark packets. Networks must
either discard IEPS-marked packets sent by unauthorised users or
relabel those packets with a standard priority marking.
* Inter-domain IP gateways must police prioritised traffic according
to the service-level agreement between the domains. Gateways must not
accept IEPS-marked packets from networks that do not police IEPS
traffic; such packets may be dropped or re-marked.
* Gateways between domains using different QoS mechanisms (such as
DiffServ and Weighted Fair Queuing) must be able to translate IEPS
markings appropriately.
* IP-to-PSTN gateways should use IEPS telephony mechanisms to provide
priority for calls set up by IEPS/IEMS traffic.
* PSTN-to-IP gateways should mark packets resulting from an IEPS
telephony call as IEPS/IEMS-authorised.
* IP traffic should be protected using IPSEC to the maximum possible
extent.
8. Security Considerations
This entire document is about security.
9. Acknowledgements
Many thanks to Ken Carlberg, Hal Folts, Stu Goldman, Jack Garrity,
James Polk and Gary Thom for their comments on this draft.
Brown UCL [Page 10]
Internet-Draft IEPS security 5 July 2001
10. Author's Address
Ian Brown
Department of Computer Science
University College London
Gower Street
London WC1E 6BT
United Kingdom
Phone: +44 20 7679 3704
Fax: +44 20 7387 1397
E-mail: I.Brown@cs.ucl.ac.uk
11. References
[Blake98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W.
Weiss, An Architecture for Differentiated Services, RFC 2475,
December 1998.
[Blom01] R. Blom, E. Carrara, D. McGrew, M. Naslund, K. Norrman, and
D. Oran, The Secure Real Time Transport Protocol, IETF work-in-
progress, February 2001.
[Carlberg00] K. Carlberg and I. Brown, Framework for Supporting IEPS
in IP Telephony, IETF work-in-progress, November 2000.
[Dierks99] T. Dierks and C. Allen, The TLS Protocol Version 1.0, RFC
2246, January 1999.
[ETSI00] ETSI TR 33.102, 3GPP security architecture, December 2000.
[Handley99] M. Handley et al, SIP: Session Initiation Protocol, RFC
2453, March 1999.
[Harkins98] D. Harkins and D. Carrel, The Internet Key Exchange, RFC
2409, November 1998.
[ITU00a] ITU-T Recommendation E.106, Description of an International
Emergency Preference Scheme (IEPS), draft-itu-t-ieprep-description-
00.txt, March 2000
[ITU00b] ITU-T Recommendation X.509, The Directory: Public-key and
attribute certificate frameworks, March 2000
[ITU01] ITU-T Draft Recommendation F.706, International Emergency
Multimedia Service, 2001
[Maughan98] D. Maughhan et al, Internet Security Association and Key
Management Protocol, RFC 2408, November 1998.
[Schulzrinne96] H. Schulzrinne, S. Casner, R. Frederick, and V.
Brown UCL [Page 11]
Internet-Draft IEPS security 5 July 2001
Jacobson, RTP: A Transport Protocol for Real-time Applications, RFC
1889, January 1996.
[Telcordia00] Telcordia Technologies, Next Generation, Voice over
Packet, and Hybrid Networks Security Issues, Report to National
Communications System, September 2000.
[Thayer98] R. Thayer, N. Doraswamy, and R. Glenn, IP Security
Document Roadmap, RFC 2411, November 1998.
12. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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 assigns.
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.
Brown UCL [Page 12]
