Internet Engineering Task Force I. Brown
INTERNET-DRAFT University College London
Expiration Date: 30 December 2002 June 2002
A Security Framework for Emergency Communications
<draft-ietf-ieprep-security-01.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.
Copyright
Copyright (C) Internet Society 2002. All rights reserved.
Reproduction or translation of the complete document, but not of
extracts, including this notice, is freely permitted.
Abstract
The Public Switched Telephone Network includes several mechanisms
that increase the probability of completion for telephone calls made
by authorised disaster relief personnel during emergencies such as
hurricanes or terrorist attacks. This memo describes the security
requirements of providing this functionality in private and public IP
networks, and how these requirements can be met using existing
protocols. It also specifies which enhancements are necessary to
these protocols to allow enhanced functionality such as roaming
access.
Brown Expires 30 December 2002 [Page 1]
Internet-Draft ETS security June 2002
Table of Contents
1 Introduction 2
2 Objective 3
3 Background 3
3.1 IPSEC 3
3.2 TLS 5
3.3 SIP and RTP 5
3.4 H.235 6
4 Authentication 6
4.1 PIN-based 6
4.2 Cryptographic 7
4.3 Fraud Detection 7
4.4 Roaming access 7
5 Recommended Approach 8
6 Scenarios 9
6.1 PSTN-to-IP-to-PSTN 9
6.2 PSTN-to-IP 9
6.3 IP-to-PSTN 10
6.4 Pure IP 11
6.5 Roaming 11
7 Recommendations and Requirements 11
8 Security Considerations 12
9 Acknowledgements 13
10 Author's Address 13
11 Normative References 13
12 Informative References 14
13 Full Copyright Statement 14
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 terrorist attacks. 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 [Carlberg02].
Brown Expires 30 December 2002 [Page 2]
Internet-Draft ETS security June 2002
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 an
Emergency Telecommunications Service in more detail. We begin by
outlining our security objectives and describing the existing IP
security protocols that can be used to meet these objectives. We then
explain our recommended approach and show how secure ETS support can
be provided in different configurations of PSTN and IP networks. We
conclude with recommendations to implementers of ETS-enabled IP
networks and requirements for IETF protocols that would allow
enhanced functionality such as roaming ETS access.
2. Objective
There are two primary security requirements for ETS: preventing theft
and denial of service by unauthorised users and ensuring the
confidentiality and 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, ETS users should not require separate authorisation
mechanisms for the PSTN and IP networks, or should be able to use
pre-existing authorisation mechanisms. 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) extensions are a mandatory
part of IPv6 and can also be supported 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 [Kent98a]. The Encapsulating
Security Payload (ESP) provides confidentiality [Kent98b]. Both
Brown Expires 30 December 2002 [Page 3]
Internet-Draft ETS security June 2002
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.
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.
Data can be placed in an Encapsulating Security Payload 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. 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.
Brown Expires 30 December 2002 [Page 4]
Internet-Draft ETS security June 2002
3.2 TLS
TLS (Transport Layer Security) is designed to provide privacy and
data integrity between two communicating applications (most
commonly, a Web server and browser). It is composed of two
main 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 2^14 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.
Because TLS runs over TCP it is vulnerable to several Denial of
Service attacks that have been found on that protocol [eg
Bellovin89].
H.323 and SIP 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 conferencing sessions using a simple ASCII-based
protocol. Nodes can communicate securely using TLS, and
authenticated and private invitations can be sent using the secure
S/MIME format [Handley99]. S/MIME also allows invitations to be
secured end-to-end, hiding information not necessary for the
routing of the invitation from intermediate points. Further
privacy for session initiators can be obtained using the privacy
services being developed for SIP [Peterson02].
Invitations can also contain keys used to encrypt the conference
material itself using the Real-time Transport Protocol
[Schulzrinne96]. The 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
Brown Expires 30 December 2002 [Page 5]
Internet-Draft ETS security June 2002
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]. A more flexible
key exchange protocol is also being defined [Arkko02].
PacketCable can use the RC4 encryption algorithm with RTP to
protect call content.
3.4 H.235
The ITU-T's Recommendation H.235 specifies the use of security
services by H-series multimedia terminals. It focuses on providing
authentication and privacy for call signalling using its own
security protocol, TLS or IPSEC, and for call traffic using RTP
security extensions. It allows password and certificate-based
authentication of users.
4. Authentication
ETS 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 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 adapt the
authentication framework from the next-generation mobile phone
protocol 3GPP [ETSI00]. Users away from their home network can be
authenticated with protocols being developed by the Authentication,
Authorisation and Accounting (AAA) working group.
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.
4.1 PIN-based
US 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. Users would configure a specific ISP account that
Brown Expires 30 December 2002 [Page 6]
Internet-Draft ETS security June 2002
used a GETS-type access number to dial-up, and then authenticate
themselves as someone authorised for ETS service. They would then
receive priority in setting up the dial-in connection, along with
priority on the IP side of the ISP's network.
System-wide user PINs could be replaced by one-time PINs
calculated using 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. These shared secrets rather than the PINs themselves
would have to be distributed to all points that need to
authenticate users; relying on one central authentication centre
would create a central point of failure for the whole system.
4.2 Cryptographic
More secure authentication of IP devices is possible using on-line
cryptographic mechanisms. Authorised ETS users would be provided
with a shared secret key or digital certificate [ITU00b] 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 an application on 3GPP
Universal Subscriber Identity 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. Again, redundant authorisation
points must be provided so that user access is not prevented by
the unavailability of one authentication centre.
4.3 Fraud Detection
The ETS threat model is most 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.
4.4 Roaming Access
Brown Expires 30 December 2002 [Page 7]
Internet-Draft ETS security June 2002
The Diameter protocol being developed by the Authentication,
Authorisation and Accounting working group allows access networks
to authenticate roaming users with their home networks and bill
for services provided, as long as it has a roaming agreement with
their home network or a roaming consortium containing their home
network [Calhoun02]. It is an extensible protocol that allows
additional data flows between access and home networks to be
defined and used by specific applications.
Once an access network has authenticated an ETS user it will
provide basic IP service. If an extension to Diameter was defined
to allow the transport of Quality of Service information from home
to access network, ETS users could also be provided with
prioritised service at the link, network [Braun01] and application
layers. The Next Steps in Signalling working group is developing
building blocks by which such remote QoS support can be provided.
A protocol is also being developed by the Seamoby working group to
allow context such as QoS to be transferred between access points
as a roaming user moves within and between networks. This could
allow ETS priority to be maintained for an on-the-move mobile
terminal without the need to re-register for this service at each
new access point within one session.
5. Recommended Approach
The following protocols best meet the requirements we have outlined:
A security model of the type used by DiffServ [Blake98] should be the
basis for preventing theft of service. ETS-enabled networks must
authenticate end users before allowing them to send prioritised
traffic over their networks. Prioritised traffic may be passed
between two ETS-enabled networks; their interconnection agreement
should specify translation between different schemes being used to
provide that priority, and a limit on the ETS traffic as a percentage
of total capacity. An ETS-compliant network must not accept ETS-
marked traffic from users or interconnect points that are not
authorised for that service; such traffic should be given only normal
priority on the network.
Content integrity and confidentiality may be provided using any of
the standardised security protocols outlined in section two. TLS and
SRTP will be widely deployed in telephony and videoconferencing
applications supporting SIP and RTP. H.325 may be used between
multimedia terminals supporting that protocol suite. IPSEC can also
be used for other IP traffic such as e-mail transport or Web access,
and will be widely supported in IPv6 devices.
PIN-based authorisation should remain the primary access control
mechanism for simple telephony devices in the short-to-medium
term. This removes the need for users to remember how different
mechanisms and secrets work in placing calls using PSTN or IP
Brown Expires 30 December 2002 [Page 8]
Internet-Draft ETS security June 2002
telephones - and from needing to work out which is which! In more
complex devices, ETS authorisation should be integrated with existing
authentication schemes to reduce unnecessary overhead in protocols
and on users' memories. Fraud detection should continue to be used to
detect unauthorized use of the system. In the longer term,
smartcard/SIM-based authentication should become more feasible.
6. Scenarios
This section examines in more detail how our recommended approach
would be applied in the primary scenarios identified for ETS use
[Carlberg02].
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 as a percentage of total capacity 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, with pre-configured IKE Security
Associations to reduce call setup latency.
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 traffic is likely to flow across several IP
networks to its destination. At each gateway, the ingress point
performs traffic policing and priority marking translation.
If a network in the path to the final traffic destination does not
Brown Expires 30 December 2002 [Page 9]
Internet-Draft ETS security June 2002
support ETS 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
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 protocols such as SRTP
and TLS. If IPSEC is used with DiffServ, 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 rely on a trusted SIP proxy within the
user's ISP network, which then carries out the appropriate
forwarding. More advanced routing is possible using a protocol
such as Telephony Routing over IP [Rosenberg00].
The device's access network must recognise that its user is
allowed ETS service to provide network-layer priority. This can be
integrated into the network's login procedure: only certain users
will be so authorised. The user's device may mark packets as
prioritised, or the network may do so at its ingress point.
To obtain priority call setup in the PSTN, the user must prove
that they are authorised to receive this service to the PSTN
gateway. They may do this by authenticating themselves as a user
allowed this facility, either to a trusted SIP proxy in their home
network or directly to the gateway. Alternatively the user may
authenticate themselves to a remote PSTN gateway using the same
procedure as on the PSTN: by dialling a known number and PIN. This
requires either that the PSTN gateway is able to route calls to
non-geographic numbers such as the 710 area code used by the US
GETS system, or that it is able to provide the verification
service itself.
If the PSTN 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,
the originating IP device should tunnel it to the IP-PSTN gateway
using protocols such as TLS and SRTP. This will also allow devices
on non-ETS-enabled networks to authorise themselves to an ETS-
supporting IP-PSTN gateway using any of the security protocol's
authentication mechanisms. Their traffic on the PSTN side of the
Brown Expires 30 December 2002 [Page 10]
Internet-Draft ETS security June 2002
connection can then be prioritised.
6.4 Pure IP
The simplest scenario is that both end-points of an ETS call are
IP devices linked by public or private internets. Again, the call
originator must mark call traffic packets as prioritised. The
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-
ETS-enabled network. For this reason, ETS-enabled networks may
attempt to use policy-based routing to keep such traffic on ETS-
capable networks.
For maximum assurance of call integrity and confidentiality, there
should be an end-to-end secured link between the originator and
recipient of a call using protocols such as TLS and SRTP.
6.5 Roaming
A roaming ETS user must first authenticate themselves to a local
access network using a protocol such as the Extensible
Authentication Protocol [Blunk98]. That network will verify the
user's credentials with their home network using Diameter, which
also needs to signal back the enhanced QoS that should be provided
for the user. The access network can then allow the use of
priority mechanisms at the link and network layers.
As an ETS user moves between different access points in the access
network, their priority should be signalled between points using
the context transfer protocol being developed by the Seamoby
working group.
To locate a PSTN gateway suitable for a specific telephone number,
an ETS user may attempt to discover a local TRIP Location Server
[Rosenberg00] or use a location server on their home network. The
latter option has the advantage that the user can be pointed to
gateways that have a business relationship with their home network
(and hence will be able to authenticate the user and charge for
calls) and that support PSTN call prioritisation mechanisms.
7. Recommendations and Requirements
We recommend that ETS-compliant IP networks should meet the following
requirements:
* ETS users should be authorised using a PIN or as part of the user
profile stored by their network or remote PSTN gateway. This
authorisation may be verified remotely for roaming users with AAA
protocols. The authorisation of a given user must be a highly
available service.
Brown Expires 30 December 2002 [Page 11]
Internet-Draft ETS security June 2002
* Network-layer priority mechanisms such as DiffServ may be applied
to ETS traffic from authorised users. Networks must relabel ETS-
marked traffic sent by unauthorised users with a standard priority
marking. Priority mechanisms in link-layer protocols may also be
enabled on access links for authorised users.
* Inter-domain IP gateways must police prioritised traffic according
to the service-level agreement between the domains. Gateways must not
accept ETS-marked traffic from networks that do not police ETS
priority; such traffic should be re-marked to a normal priority
level.
* Gateways between domains using different QoS mechanisms (such as
DiffServ and Weighted Fair Queuing) must be able to translate ETS
markings appropriately.
* IP-to-PSTN gateways should use IEPS telephony mechanisms to provide
priority call setup for calls marked as ETS by authorised users. ETS
calls from unauthorised users must be treated with normal priority.
* PSTN-to-IP gateways should mark sessions resulting from an IEPS
telephony call as ETS-authorised and apply network-layer priority
schemes to signalling and media traffic as dictated by local policy.
* A gateway or proxy that verifies the authorisation of a given
session to receive prioritisation should allow other intermediaries
to check where possible that this verification has been done.
* The confidentiality and integrity of IP traffic should be protected
using a security protocol such as SRTP, TLS, H.235 or IPSEC to the
maximum possible extent.
In order to provide ETS support to roaming users, the following
protocol additions are required:
* The Diameter protocol must allow home networks to signal to a
remote network that a given user is authorised for ETS priority. This
may be through a specific indicator or as part of a more general
approach to signalling Quality of Service levels.
* The Seamoby protocol should allow priority to be included in the
context transferred between access points.
8. Security Considerations
This entire document is about security.
Operators of ETS-capable networks must maintain the overall security
of their network to prevent more general attacks upon ETS and other
traffic.
Brown Expires 30 December 2002 [Page 12]
Internet-Draft ETS security June 2002
9. Acknowledgements
Many thanks to Ken Carlberg, Martin Euchner, Hal Folts, Stu Goldman,
Jack Garrity, Kimberly King, James Polk, Eric Rescorla and Gary Thom
for their comments on this draft.
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 Normative References
[Arkko02] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and
K. Norrman, "MIKEY: Multimedia Internet KEYing", Internet draft,
February 2002.
[Blake98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated Services", RFC
2475, December 1998.
[Blom01] Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K.,
and D. Oran, "The Secure Real Time Transport Protocol", IETF work-in-
progress, February 2002.
[Blunk98] Blunk L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol", RFC 2284, March 1998.
[Calhoun02] Calhoun, P., Arkko, J., Guttman, E., Zorn, G. and J.
Loughney, "Diameter Base Protocol", IETF work-in-progress, April
2002.
[Carlberg02] Carlberg, K. and I. Brown, "Framework for Supporting
IEPS in IP Telephony", IETF work-in-progress, April 2002.
[Dierks99] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[Kent98a] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[Kent98b] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload", RFC 2406, November 1998.
Brown Expires 30 December 2002 [Page 13]
Internet-Draft ETS security June 2002
[Handley99] Handley, M. et al, "SIP: Session Initiation Protocol",
RFC 2543, March 1999.
[Harkins98] Harkins, D. and D. Carrel, "The Internet Key Exchange",
RFC 2409, November 1998.
[ITU00b] ITU-T Recommendation X.509, "The Directory: Public-key and
attribute certificate frameworks", March 2000.
[Maughan98] Maughhan, D. et al, "Internet Security Association and
Key Management Protocol", RFC 2408, November 1998.
[Peterson02] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", IETF work-in-progress, March 2002.
[Rosenberg00] Rosenberg, J. and H. Schulzrinne, "A Framework for
Telephony Routing over IP", RFC 2871, June 2000.
[Schulzrinne96] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-time Applications", RFC
1889, January 1996.
[Thayer98] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
12 Informative References
[Bellovin89] Bellovin, S.M., "Security Problems in the TCP/IP
Protocol Suite," Computer Communications Review 2:19, pp. 32-48,
April 1989.
[Braun01] Braun, T., Ru, L. and G. Stattenberger, "An AAA
Architecture Extension for Providing Differentiated Services to
Mobile IP Users", 6th IEEE Symposium on Computers and Communications
(ISCC 2001), Hammamet, Tunisia, July 2001.
[ETSI00] ETSI TR 33.102, "3GPP security architecture", December 2000.
[ITU00a] ITU-T Recommendation E.106, "Description of an International
Emergency Preference Scheme (IEPS)", March 2000.
[ITU01] ITU-T Draft Recommendation F.706, "International Emergency
Multimedia Service", 2001
[Telcordia00] Telcordia Technologies, "Next Generation, Voice over
Packet, and Hybrid Networks Security Issues", Report to National
Communications System, September 2000.
13 Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
Brown Expires 30 December 2002 [Page 14]
Internet-Draft ETS security June 2002
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 Expires 30 December 2002 [Page 15]
Brown Expires 30 December 2002 [Page 16]
