idnits 2.17.1 draft-ietf-ieprep-security-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 14 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7987 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Dierks99' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'Bellovin89' is defined on line 698, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Arkko02' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'Blake98') -- Possible downref: Non-RFC (?) normative reference: ref. 'Blom01' ** Obsolete normative reference: RFC 2284 (ref. 'Blunk98') (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. 'Calhoun02' -- Possible downref: Non-RFC (?) normative reference: ref. 'Carlberg02' ** Obsolete normative reference: RFC 2246 (ref. 'Dierks99') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2402 (ref. 'Kent98a') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. 'Kent98b') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2543 (ref. 'Handley99') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2409 (ref. 'Harkins98') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU00b' ** Obsolete normative reference: RFC 2408 (ref. 'Maughan98') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'Peterson02' ** Downref: Normative reference to an Informational RFC: RFC 2871 (ref. 'Rosenberg00') ** Obsolete normative reference: RFC 1889 (ref. 'Schulzrinne96') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2411 (ref. 'Thayer98') (Obsoleted by RFC 6071) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force I. Brown 2 INTERNET-DRAFT University College London 3 Expiration Date: 30 December 2002 June 2002 5 A Security Framework for Emergency Communications 6 8 Status of This Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright 32 Copyright (C) Internet Society 2002. All rights reserved. 33 Reproduction or translation of the complete document, but not of 34 extracts, including this notice, is freely permitted. 36 Abstract 38 The Public Switched Telephone Network includes several mechanisms 39 that increase the probability of completion for telephone calls made 40 by authorised disaster relief personnel during emergencies such as 41 hurricanes or terrorist attacks. This memo describes the security 42 requirements of providing this functionality in private and public IP 43 networks, and how these requirements can be met using existing 44 protocols. It also specifies which enhancements are necessary to 45 these protocols to allow enhanced functionality such as roaming 46 access. 48 Table of Contents 50 1 Introduction 2 51 2 Objective 3 52 3 Background 3 53 3.1 IPSEC 3 54 3.2 TLS 5 55 3.3 SIP and RTP 5 56 3.4 H.235 6 57 4 Authentication 6 58 4.1 PIN-based 6 59 4.2 Cryptographic 7 60 4.3 Fraud Detection 7 61 4.4 Roaming access 7 62 5 Recommended Approach 8 63 6 Scenarios 9 64 6.1 PSTN-to-IP-to-PSTN 9 65 6.2 PSTN-to-IP 9 66 6.3 IP-to-PSTN 10 67 6.4 Pure IP 11 68 6.5 Roaming 11 69 7 Recommendations and Requirements 11 70 8 Security Considerations 12 71 9 Acknowledgements 13 72 10 Author's Address 13 73 11 Normative References 13 74 12 Informative References 14 75 13 Full Copyright Statement 14 77 1. Introduction 79 The International Emergency Preference Scheme is a set of mechanisms 80 specified for use in the Public Switched Telephone Network to 81 increase the probability of completion for certain telephone calls 82 during emergencies such as hurricanes or terrorist attacks. Calls are 83 given a higher probability of completion by exchanges waiting for 84 resources to become available rather than rejecting the call attempt 85 when congestion is encountered, and attempting to use alternate 86 carrier routing if network congestion is encountered. IEPS calls are 87 also exempted from restrictive network management controls [ITU00a]. 88 The Government Emergency Telecommunications System (GETS) already 89 operating in the United States includes these mechanisms. 91 As telecommunications providers start using the Internet Protocol 92 across their backbone networks, IEPS support is a feature they may 93 wish to extend to the new transport layers to continue their ability 94 to provide this service to support emergency recovery operations 95 through service level agreements. The end-points of telephone calls 96 may also start migrating to public or private IP networks. An effort 97 is underway in the IETF to standardise mechanisms to provide IEPS 98 support across these composite networks [Carlberg02]. 100 A companion ITU effort has also developed an International Emergency 101 Multimedia Service that will provide similar functionality across a 102 much wider range of applications in packet-switched networks [ITU01]. 104 This document considers the security requirements implicit in such an 105 Emergency Telecommunications Service in more detail. We begin by 106 outlining our security objectives and describing the existing IP 107 security protocols that can be used to meet these objectives. We then 108 explain our recommended approach and show how secure ETS support can 109 be provided in different configurations of PSTN and IP networks. We 110 conclude with recommendations to implementers of ETS-enabled IP 111 networks and requirements for IETF protocols that would allow 112 enhanced functionality such as roaming ETS access. 114 2. Objective 116 There are two primary security requirements for ETS: preventing theft 117 and denial of service by unauthorised users and ensuring the 118 confidentiality and integrity of calls using the system. 120 As far as possible, we wish to build on the security mechanisms 121 within existing IEPS systems and existing Internet standards. 122 Ideally, ETS users should not require separate authorisation 123 mechanisms for the PSTN and IP networks, or should be able to use 124 pre-existing authorisation mechanisms. We also aim to minimise 125 complexity of the system in order to reduce cost and maximise 126 security. Finally, we want to provide a flexible framework within 127 which telecommunications providers may use the methods best suited to 128 their networks. 130 3. Background 132 Several security protocols are already in use by IP telephony 133 applications. IPSEC and TLS are general-purpose network and transport 134 layer protocols that ensure the confidentiality and integrity of 135 communications. SIP and RTP are application-layer protocols that 136 define call signalling and content formats, and use application- 137 specific security extensions. This background section describes these 138 protocols in more detail. Further background information is available 139 in a report from Telcordia [Telcordia00]. 141 3.1 IPSEC 143 The Internet Protocol Security (IPSEC) extensions are a mandatory 144 part of IPv6 and can also be supported in IPv4. The specifications 145 provide an algorithm-independent framework into which specific 146 cryptographic methods can be inserted [Thayer98]. 148 Two mechanisms are used to protect packet data. The Authentication 149 Header (AH) allows data to be signed, assuring its authenticity 150 and integrity but not secrecy [Kent98a]. The Encapsulating 151 Security Payload (ESP) provides confidentiality [Kent98b]. Both 152 mechanisms can be used in tunnel mode (an entire IP packet is 153 encapsulated within another before applying the security services) 154 or transport mode (only higher-layer data is secured). ESP mode 155 can also incorporate authentication procedures, but AH allows the 156 protection of immutable and predictable IP headers, which ESP 157 cannot provide in transport mode. 159 The Authentication Header goes between the IP and higher layer 160 headers of a packet, and contains information that the recipient 161 can use to authenticate the sender and contents of the rest of the 162 packet. This is more efficient than applying transformations to 163 the entire packet. An anti-replay service can prevent old traffic 164 being resent to a host, using sequence numbers in the 165 authentication header. 167 Data can be placed in an Encapsulating Security Payload before it 168 leaves the sender, hiding its contents until it reaches the 169 receiver, who decrypts it using the secret key they share with the 170 sender. In tunnel mode, the source and destination of the 171 encapsulated packet can be hidden, so preventing some traffic 172 analysis attacks. The padding used to ensure the data being 173 encrypted is the correct length for use with a specific cipher can 174 also be extended to conceal the true length of that data, 175 providing further traffic flow confidentiality. Transport mode is 176 simpler, and normally used between end systems. If a security 177 gateway is at either end of a connection, tunnel mode must be 178 used. Only at the end of their journey are the encrypted and 179 authenticated contents of a packet revealed. Security gateways can 180 forward such packets to hosts without IPSEC support. 182 AH and ESP both require communicating hosts to share secret keys 183 to authenticate and encrypt transmitted data. It is relatively 184 simple to manually configure hosts with fixed keys, but this is 185 completely unscalable. Hosts also need to agree on the 186 cryptographic systems they both understand. 188 The Internet Key Exchange (IKE) allows two hosts to agree on these 189 parameters [Harkins98]. After setting up a secure ISAKMP (Internet 190 Security Association and Key Management Protocol) link 191 [Maughan98], IKE hosts generate keys for, and negotiate, IPSEC 192 Security Associations. Each association is used by network code to 193 select the transformations it will apply to each packet. The 194 exchange is finally authenticated to prevent a man-in-the-middle 195 attack, and optionally identify each host. Various types of 196 certificate can be used at this stage to increase the security of 197 the authentication. 199 ITU Recommendations H.323 and H.248, IETF Megaco, and AT&T 200 PacketCable use IPSEC to protect signalling messages. H.323's call 201 control messages and PacketCable's call content can also be 202 secured using IPSEC. 204 3.2 TLS 206 TLS (Transport Layer Security) is designed to provide privacy and 207 data integrity between two communicating applications (most 208 commonly, a Web server and browser). It is composed of two 209 main protocols: the record protocol, which provides a private and 210 reliable connection, and the handshake protocol, used to 211 authenticate client and server and negotiate cryptographic 212 algorithms and keys. 214 The record protocol fragments data into blocks of 2^14 bytes or 215 less. Each block can be compressed, encrypted, and authenticated 216 using a MAC (Message Authentication Code). A key calculation 217 algorithm is used to generate keys, Initialisation Vectors for the 218 encryption and MAC secrets from secret parameters supplied by the 219 handshake protocol. 221 The handshake protocol negotiates each session: a session 222 identifier, compression method, cipher specification (encryption 223 and MAC algorithms), 48-byte master secret, a resumable flag and 224 optional certificates for either party. A resumable session can be 225 used to set up several connections. A session can be renegotiated 226 at any time during a connection. Alert messages of varying levels 227 may be sent; "fatal" alerts cause the connection to be 228 terminated and session invalidated for future connections. 230 Because TLS runs over TCP it is vulnerable to several Denial of 231 Service attacks that have been found on that protocol [eg 232 Bellovin89]. 234 H.323 and SIP can use TLS to protect call signalling and control 235 messages. 237 3.3 SIP and RTP 239 The Session Initiation Protocol allows participants to be invited 240 to multimedia conferencing sessions using a simple ASCII-based 241 protocol. Nodes can communicate securely using TLS, and 242 authenticated and private invitations can be sent using the secure 243 S/MIME format [Handley99]. S/MIME also allows invitations to be 244 secured end-to-end, hiding information not necessary for the 245 routing of the invitation from intermediate points. Further 246 privacy for session initiators can be obtained using the privacy 247 services being developed for SIP [Peterson02]. 249 Invitations can also contain keys used to encrypt the conference 250 material itself using the Real-time Transport Protocol 251 [Schulzrinne96]. The Data Encryption Standard is the standardised 252 cipher used for this encryption. RTP does not provide 253 authentication services, and originally expected all of its 254 security capabilities to be superseded by services provided by 255 IPSEC once that becomes widespread. A Secure RTP standard is now 256 being defined that allows RTP packets to be encrypted and 257 authenticated whilst still allowing header compression, which is 258 useful for low-capacity wireless links [Blom01]. A more flexible 259 key exchange protocol is also being defined [Arkko02]. 261 PacketCable can use the RC4 encryption algorithm with RTP to 262 protect call content. 264 3.4 H.235 266 The ITU-T's Recommendation H.235 specifies the use of security 267 services by H-series multimedia terminals. It focuses on providing 268 authentication and privacy for call signalling using its own 269 security protocol, TLS or IPSEC, and for call traffic using RTP 270 security extensions. It allows password and certificate-based 271 authentication of users. 273 4. Authentication 275 ETS users must demonstrate they are authorised to use the service 276 before placing a call, in a similar way to calling card owners. GETS 277 users are authenticated by a twelve-digit personal identification 278 number (PIN); fraud detection techniques are used to watch for 279 suspicious usage patterns. 281 IP devices could use cryptographic methods to authenticate their 282 users to the network. It would also be possible to adapt the 283 authentication framework from the next-generation mobile phone 284 protocol 3GPP [ETSI00]. Users away from their home network can be 285 authenticated with protocols being developed by the Authentication, 286 Authorisation and Accounting (AAA) working group. 288 The impact of denial of service attacks can be reduced by authorising 289 users with the minimum resources required. Devices originating such 290 attacks may be temporarily ignored by an authentication service. 292 4.1 PIN-based 294 US GETS users are currently authenticated by an interexchange 295 carrier contracted to provide the service using a PIN entered 296 through the originating telephone. GETS users dial a toll-free 297 number beginning with the non-geographic area code 710, then enter 298 a PIN and the number they wish to call. Databases of authorised 299 PINs are regularly distributed to the interexchange carriers by 300 the responsible government agency, the National Communications 301 System. This system relies on physical line security to protect 302 PINs and the carrier's infrastructure security to prevent call 303 hijacking. 305 This system can be used virtually unchanged with IEPS over IP. It 306 could even be extended for use as a password with dial-up Internet 307 connections. Users would configure a specific ISP account that 308 used a GETS-type access number to dial-up, and then authenticate 309 themselves as someone authorised for ETS service. They would then 310 receive priority in setting up the dial-in connection, along with 311 priority on the IP side of the ISP's network. 313 System-wide user PINs could be replaced by one-time PINs 314 calculated using devices such as RSA's SecurID card. This 315 calculates a new PIN every 60 seconds using a secret shared 316 between the card and the authorisation centre along with a user- 317 entered PIN. These shared secrets rather than the PINs themselves 318 would have to be distributed to all points that need to 319 authenticate users; relying on one central authentication centre 320 would create a central point of failure for the whole system. 322 4.2 Cryptographic 324 More secure authentication of IP devices is possible using on-line 325 cryptographic mechanisms. Authorised ETS users would be provided 326 with a shared secret key or digital certificate [ITU00b] to 327 authenticate themselves to IEPS-capable networks. To protect these 328 secret keys and allow them to be used from a wide variety of 329 locations, they would almost certainly be stored on a smartcard. 330 This would require that communications devices contain smartcard 331 readers. 333 One way to achieve widespread interoperable authentication with 334 PSTN and IP devices would be to use an application on 3GPP 335 Universal Subscriber Identity Modules. The user's home network 336 would provide priority service to authorised users locally, and 337 signal to remote networks that a given roaming user was authorised 338 for emergency preference service. Again, redundant authorisation 339 points must be provided so that user access is not prevented by 340 the unavailability of one authentication centre. 342 4.3 Fraud Detection 344 The ETS threat model is most concerned with theft of service. 345 Because network operators can limit total prioritised calls to a 346 small percentage of their total capacity, prevention of all 347 unauthorised usage is not an absolute priority. Fraud detection 348 techniques can be used later to identify and update compromised 349 PINs and systems, and to attempt to trace the perpetrators. 351 Techniques used by GETS operators include detection of 352 simultaneous use of a given PIN, use of one PIN from distant 353 locations within a short time period, and other more sophisticated 354 usage pattern analysis. While fraudulent use can often be 355 recognised in real-time, carriers do not terminate such calls 356 immediately but instead log details for later investigation. 358 4.4 Roaming Access 359 The Diameter protocol being developed by the Authentication, 360 Authorisation and Accounting working group allows access networks 361 to authenticate roaming users with their home networks and bill 362 for services provided, as long as it has a roaming agreement with 363 their home network or a roaming consortium containing their home 364 network [Calhoun02]. It is an extensible protocol that allows 365 additional data flows between access and home networks to be 366 defined and used by specific applications. 368 Once an access network has authenticated an ETS user it will 369 provide basic IP service. If an extension to Diameter was defined 370 to allow the transport of Quality of Service information from home 371 to access network, ETS users could also be provided with 372 prioritised service at the link, network [Braun01] and application 373 layers. The Next Steps in Signalling working group is developing 374 building blocks by which such remote QoS support can be provided. 376 A protocol is also being developed by the Seamoby working group to 377 allow context such as QoS to be transferred between access points 378 as a roaming user moves within and between networks. This could 379 allow ETS priority to be maintained for an on-the-move mobile 380 terminal without the need to re-register for this service at each 381 new access point within one session. 383 5. Recommended Approach 385 The following protocols best meet the requirements we have outlined: 387 A security model of the type used by DiffServ [Blake98] should be the 388 basis for preventing theft of service. ETS-enabled networks must 389 authenticate end users before allowing them to send prioritised 390 traffic over their networks. Prioritised traffic may be passed 391 between two ETS-enabled networks; their interconnection agreement 392 should specify translation between different schemes being used to 393 provide that priority, and a limit on the ETS traffic as a percentage 394 of total capacity. An ETS-compliant network must not accept ETS- 395 marked traffic from users or interconnect points that are not 396 authorised for that service; such traffic should be given only normal 397 priority on the network. 399 Content integrity and confidentiality may be provided using any of 400 the standardised security protocols outlined in section two. TLS and 401 SRTP will be widely deployed in telephony and videoconferencing 402 applications supporting SIP and RTP. H.325 may be used between 403 multimedia terminals supporting that protocol suite. IPSEC can also 404 be used for other IP traffic such as e-mail transport or Web access, 405 and will be widely supported in IPv6 devices. 407 PIN-based authorisation should remain the primary access control 408 mechanism for simple telephony devices in the short-to-medium 409 term. This removes the need for users to remember how different 410 mechanisms and secrets work in placing calls using PSTN or IP 411 telephones - and from needing to work out which is which! In more 412 complex devices, ETS authorisation should be integrated with existing 413 authentication schemes to reduce unnecessary overhead in protocols 414 and on users' memories. Fraud detection should continue to be used to 415 detect unauthorized use of the system. In the longer term, 416 smartcard/SIM-based authentication should become more feasible. 418 6. Scenarios 420 This section examines in more detail how our recommended approach 421 would be applied in the primary scenarios identified for ETS use 422 [Carlberg02]. 424 6.1 PSTN-to-IP-to-PSTN 426 The most imminent scenario for IEPS-over-IP use is where a 427 carrier's backbone network uses IP to transport calls between two 428 PSTN domains. Authorisation of the call originator occurs as 429 before using a PIN entered through the telephone. The carrier then 430 uses traffic engineering to give enhanced priority to that data as 431 it enters and flows across the IP backbone network. It uses the 432 IEPS telephony methods to increase the likelihood of successful 433 call set-up at its gateway back into the PSTN. The carrier uses 434 its standard infrastructure security to prevent unauthorised use 435 of the facility and protect the integrity of calls. 437 If the carrier has IP peering arrangements with other networks 438 that are closer to a call's end-point, the prioritised traffic can 439 flow directly onto their networks rather than first travelling 440 back into the PSTN. Peering agreements must describe the level of 441 prioritised traffic as a percentage of total capacity that may 442 travel between the two networks, and a method of signalling that 443 traffic priority. DiffServ codepoints [Blake98] are a convenient 444 way to do so. The ingress points will perform traffic policing to 445 ensure compliance with the agreement and limit the theft of 446 service possible given compromise of the originating network. 448 For added confidentiality and integrity protection, the carrier 449 may choose to tunnel the traffic between the backbone ingress and 450 egress points using IPSEC, with pre-configured IKE Security 451 Associations to reduce call setup latency. 453 6.2 PSTN-to-IP 455 An even simpler scenario is where the end-point of the call is an 456 IP device. Again, the caller is authorised using a PIN, and the 457 resulting voice traffic marked as prioritised by the carrier's 458 PSTN-IP gateway. The traffic is likely to flow across several IP 459 networks to its destination. At each gateway, the ingress point 460 performs traffic policing and priority marking translation. 462 If a network in the path to the final traffic destination does not 463 support ETS Quality of Service prioritisation, the call will lose 464 its priority on that network. Unless that network performs traffic 465 policing, other networks later in the route will be unwilling to 466 accept marked traffic. They would otherwise be open to a massive 467 theft of service threat. If traffic policing is performed and IEPS 468 packets are accepted, the call will regain priority as it moves 469 back onto IEPS-capable networks. 471 To protect the confidentiality and integrity of the call traffic 472 as it travels across diverse networks, the PSTN-IP gateway should 473 tunnel it directly to the endpoint using protocols such as SRTP 474 and TLS. If IPSEC is used with DiffServ, the outer packet must be 475 marked to allow recognition by intermediate routers. 477 6.3 IP-to-PSTN 479 An IP device placing a call to a PSTN telephone must first 480 discover an appropriate PSTN gateway. While the details of that 481 discovery procedure are outside the scope of this document, the 482 simplest method is to rely on a trusted SIP proxy within the 483 user's ISP network, which then carries out the appropriate 484 forwarding. More advanced routing is possible using a protocol 485 such as Telephony Routing over IP [Rosenberg00]. 487 The device's access network must recognise that its user is 488 allowed ETS service to provide network-layer priority. This can be 489 integrated into the network's login procedure: only certain users 490 will be so authorised. The user's device may mark packets as 491 prioritised, or the network may do so at its ingress point. 493 To obtain priority call setup in the PSTN, the user must prove 494 that they are authorised to receive this service to the PSTN 495 gateway. They may do this by authenticating themselves as a user 496 allowed this facility, either to a trusted SIP proxy in their home 497 network or directly to the gateway. Alternatively the user may 498 authenticate themselves to a remote PSTN gateway using the same 499 procedure as on the PSTN: by dialling a known number and PIN. This 500 requires either that the PSTN gateway is able to route calls to 501 non-geographic numbers such as the 710 area code used by the US 502 GETS system, or that it is able to provide the verification 503 service itself. 505 If the PSTN signalling and content gateways are not co-located, 506 the former must securely instruct the latter to route the call 507 traffic onto the circuit set up by the signalling gateway. 509 To protect the confidentiality and integrity of the call traffic, 510 the originating IP device should tunnel it to the IP-PSTN gateway 511 using protocols such as TLS and SRTP. This will also allow devices 512 on non-ETS-enabled networks to authorise themselves to an ETS- 513 supporting IP-PSTN gateway using any of the security protocol's 514 authentication mechanisms. Their traffic on the PSTN side of the 515 connection can then be prioritised. 517 6.4 Pure IP 519 The simplest scenario is that both end-points of an ETS call are 520 IP devices linked by public or private internets. Again, the call 521 originator must mark call traffic packets as prioritised. The 522 ingress point of their first-hop network must recognise that the 523 originator is authorised for this service, and allow the marked 524 packets to flow across its network. As before, packet 525 prioritisation will be lost if the packets must flow across a non- 526 ETS-enabled network. For this reason, ETS-enabled networks may 527 attempt to use policy-based routing to keep such traffic on ETS- 528 capable networks. 530 For maximum assurance of call integrity and confidentiality, there 531 should be an end-to-end secured link between the originator and 532 recipient of a call using protocols such as TLS and SRTP. 534 6.5 Roaming 536 A roaming ETS user must first authenticate themselves to a local 537 access network using a protocol such as the Extensible 538 Authentication Protocol [Blunk98]. That network will verify the 539 user's credentials with their home network using Diameter, which 540 also needs to signal back the enhanced QoS that should be provided 541 for the user. The access network can then allow the use of 542 priority mechanisms at the link and network layers. 544 As an ETS user moves between different access points in the access 545 network, their priority should be signalled between points using 546 the context transfer protocol being developed by the Seamoby 547 working group. 549 To locate a PSTN gateway suitable for a specific telephone number, 550 an ETS user may attempt to discover a local TRIP Location Server 551 [Rosenberg00] or use a location server on their home network. The 552 latter option has the advantage that the user can be pointed to 553 gateways that have a business relationship with their home network 554 (and hence will be able to authenticate the user and charge for 555 calls) and that support PSTN call prioritisation mechanisms. 557 7. Recommendations and Requirements 559 We recommend that ETS-compliant IP networks should meet the following 560 requirements: 562 * ETS users should be authorised using a PIN or as part of the user 563 profile stored by their network or remote PSTN gateway. This 564 authorisation may be verified remotely for roaming users with AAA 565 protocols. The authorisation of a given user must be a highly 566 available service. 568 * Network-layer priority mechanisms such as DiffServ may be applied 569 to ETS traffic from authorised users. Networks must relabel ETS- 570 marked traffic sent by unauthorised users with a standard priority 571 marking. Priority mechanisms in link-layer protocols may also be 572 enabled on access links for authorised users. 574 * Inter-domain IP gateways must police prioritised traffic according 575 to the service-level agreement between the domains. Gateways must not 576 accept ETS-marked traffic from networks that do not police ETS 577 priority; such traffic should be re-marked to a normal priority 578 level. 580 * Gateways between domains using different QoS mechanisms (such as 581 DiffServ and Weighted Fair Queuing) must be able to translate ETS 582 markings appropriately. 584 * IP-to-PSTN gateways should use IEPS telephony mechanisms to provide 585 priority call setup for calls marked as ETS by authorised users. ETS 586 calls from unauthorised users must be treated with normal priority. 588 * PSTN-to-IP gateways should mark sessions resulting from an IEPS 589 telephony call as ETS-authorised and apply network-layer priority 590 schemes to signalling and media traffic as dictated by local policy. 592 * A gateway or proxy that verifies the authorisation of a given 593 session to receive prioritisation should allow other intermediaries 594 to check where possible that this verification has been done. 596 * The confidentiality and integrity of IP traffic should be protected 597 using a security protocol such as SRTP, TLS, H.235 or IPSEC to the 598 maximum possible extent. 600 In order to provide ETS support to roaming users, the following 601 protocol additions are required: 603 * The Diameter protocol must allow home networks to signal to a 604 remote network that a given user is authorised for ETS priority. This 605 may be through a specific indicator or as part of a more general 606 approach to signalling Quality of Service levels. 608 * The Seamoby protocol should allow priority to be included in the 609 context transferred between access points. 611 8. Security Considerations 613 This entire document is about security. 615 Operators of ETS-capable networks must maintain the overall security 616 of their network to prevent more general attacks upon ETS and other 617 traffic. 619 9. Acknowledgements 621 Many thanks to Ken Carlberg, Martin Euchner, Hal Folts, Stu Goldman, 622 Jack Garrity, Kimberly King, James Polk, Eric Rescorla and Gary Thom 623 for their comments on this draft. 625 10 Author's Address 627 Ian Brown 628 Department of Computer Science 629 University College London 630 Gower Street 631 London WC1E 6BT 632 United Kingdom 634 Phone: +44 20 7679 3704 635 Fax: +44 20 7387 1397 636 E-mail: I.Brown@cs.ucl.ac.uk 638 11 Normative References 640 [Arkko02] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and 641 K. Norrman, "MIKEY: Multimedia Internet KEYing", Internet draft, 642 February 2002. 644 [Blake98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 645 and W. Weiss, "An Architecture for Differentiated Services", RFC 646 2475, December 1998. 648 [Blom01] Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K., 649 and D. Oran, "The Secure Real Time Transport Protocol", IETF work-in- 650 progress, February 2002. 652 [Blunk98] Blunk L. and J. Vollbrecht, "PPP Extensible Authentication 653 Protocol", RFC 2284, March 1998. 655 [Calhoun02] Calhoun, P., Arkko, J., Guttman, E., Zorn, G. and J. 656 Loughney, "Diameter Base Protocol", IETF work-in-progress, April 657 2002. 659 [Carlberg02] Carlberg, K. and I. Brown, "Framework for Supporting 660 IEPS in IP Telephony", IETF work-in-progress, April 2002. 662 [Dierks99] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 663 RFC 2246, January 1999. 665 [Kent98a] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 666 2402, November 1998. 668 [Kent98b] Kent, S. and R. Atkinson, "IP Encapsulating Security 669 Payload", RFC 2406, November 1998. 671 [Handley99] Handley, M. et al, "SIP: Session Initiation Protocol", 672 RFC 2543, March 1999. 674 [Harkins98] Harkins, D. and D. Carrel, "The Internet Key Exchange", 675 RFC 2409, November 1998. 677 [ITU00b] ITU-T Recommendation X.509, "The Directory: Public-key and 678 attribute certificate frameworks", March 2000. 680 [Maughan98] Maughhan, D. et al, "Internet Security Association and 681 Key Management Protocol", RFC 2408, November 1998. 683 [Peterson02] Peterson, J., "A Privacy Mechanism for the Session 684 Initiation Protocol (SIP)", IETF work-in-progress, March 2002. 686 [Rosenberg00] Rosenberg, J. and H. Schulzrinne, "A Framework for 687 Telephony Routing over IP", RFC 2871, June 2000. 689 [Schulzrinne96] Schulzrinne, H., Casner, S., Frederick, R. and V. 690 Jacobson, "RTP: A Transport Protocol for Real-time Applications", RFC 691 1889, January 1996. 693 [Thayer98] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security 694 Document Roadmap", RFC 2411, November 1998. 696 12 Informative References 698 [Bellovin89] Bellovin, S.M., "Security Problems in the TCP/IP 699 Protocol Suite," Computer Communications Review 2:19, pp. 32-48, 700 April 1989. 702 [Braun01] Braun, T., Ru, L. and G. Stattenberger, "An AAA 703 Architecture Extension for Providing Differentiated Services to 704 Mobile IP Users", 6th IEEE Symposium on Computers and Communications 705 (ISCC 2001), Hammamet, Tunisia, July 2001. 707 [ETSI00] ETSI TR 33.102, "3GPP security architecture", December 2000. 709 [ITU00a] ITU-T Recommendation E.106, "Description of an International 710 Emergency Preference Scheme (IEPS)", March 2000. 712 [ITU01] ITU-T Draft Recommendation F.706, "International Emergency 713 Multimedia Service", 2001 715 [Telcordia00] Telcordia Technologies, "Next Generation, Voice over 716 Packet, and Hybrid Networks Security Issues", Report to National 717 Communications System, September 2000. 719 13 Full Copyright Statement 721 Copyright (C) The Internet Society (2002). All Rights Reserved. 723 This document and translations of it may be copied and furnished to 724 others, and derivative works that comment on or otherwise explain 725 it or assist in its implementation may be prepared, copied, 726 published and distributed, in whole or in part, without restriction 727 of any kind, provided that the above copyright notice and this 728 paragraph are included on all such copies and derivative works. 729 However, this document itself may not be modified in any way, such 730 as by removing the copyright notice or references to the Internet 731 Society or other Internet organizations, except as needed for the 732 purpose of developing Internet standards in which case the 733 procedures for copyrights defined in the Internet Standards process 734 must be followed, or as required to translate it into languages 735 other than English. 737 The limited permissions granted above are perpetual and will not be 738 revoked by the Internet Society or its successors or assigns. 740 This document and the information contained herein is provided on 741 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 742 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 743 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 744 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 745 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.