[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

Internet Engineering Task Force                                I. Brown
INTERNET-DRAFT                                University College London
Expiration Date: 30 November 2002                              May 2002


                 Securing prioritised emergency traffic
                  <draft-ietf-ieprep-security-00.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 supporting 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 November 2002                [Page 1]


Internet-Draft               IEPS security                      May 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                                       8
   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


Brown                   Expires 30 November 2002                [Page 2]


Internet-Draft               IEPS security                      May 2002


   support across these composite networks [Carlberg02].

   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, IEPS 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) 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 in IPv4. The specifications
      provide an algorithm-independent framework into which specific
      cryptographic methods can be inserted [Thayer98].



Brown                   Expires 30 November 2002                [Page 3]


Internet-Draft               IEPS security                      May 2002


      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
      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


Brown                   Expires 30 November 2002                [Page 4]


Internet-Draft               IEPS security                      May 2002


      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
      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 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.

      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 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


Brown                   Expires 30 November 2002                [Page 5]


Internet-Draft               IEPS security                      May 2002


      [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
      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 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.


Brown                   Expires 30 November 2002                [Page 6]


Internet-Draft               IEPS security                      May 2002



      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
      used a GETS-type access number to dial-up, and 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.

      Users could 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. 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.


Brown                   Expires 30 November 2002                [Page 7]


Internet-Draft               IEPS security                      May 2002



   4.4 Roaming Access

      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


Brown                   Expires 30 November 2002                [Page 8]


Internet-Draft               IEPS security                      May 2002


   mechanism for simple telephony devices in the short-to-to medium
   term. 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! 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 use of a standardised marking is more
      important here, as the traffic is likely to flow across several IP


Brown                   Expires 30 November 2002                [Page 9]


Internet-Draft               IEPS security                      May 2002


      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 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 a protocol such as SRTP
      or 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


Brown                   Expires 30 November 2002               [Page 10]


Internet-Draft               IEPS security                      May 2002


      using a protocol such as TLS or 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
      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 a protocol such as TLS or 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 layer.

      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


Brown                   Expires 30 November 2002               [Page 11]


Internet-Draft               IEPS security                      May 2002


   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.

   * 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.

   * 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 November 2002               [Page 12]


Internet-Draft               IEPS security                      May 2002


9. Acknowledgements

   Many thanks to Ken Carlberg, Martin Euchner, Hal Folts, Stu Goldman,
   Jack Garrity, Kimberly King, James Polk 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

   [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.

   [Handley99] Handley, M. et al, "SIP: Session Initiation Protocol",
   RFC 2543, March 1999.

   [Harkins98] Harkins, D. and D. Carrel, "The Internet Key Exchange",


Brown                   Expires 30 November 2002               [Page 13]


Internet-Draft               IEPS security                      May 2002


   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

   [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 3-5, 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.

   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


Brown                   Expires 30 November 2002               [Page 14]


Internet-Draft               IEPS security                      May 2002


   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 November 2002               [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/