idnits 2.17.00 (12 Aug 2021) /tmp/idnits8298/draft-kroeselberg-sip-3g-security-req-00.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2543]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 151 has weird spacing: '...rouping funct...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - Any cryptographic mechanism that has to be executed by the mobile device, especially authentication and key agreement which happens in the USIM, MUST not mandate the use of public key cryptography, i.e., MUST allow for symmetric key cryptography only. -- 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 (January 2001) is 7795 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: 'RFC 2119' is defined on line 434, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Kroeselberg 3 Internet Draft Siemens 5 Expires: Juli, 2001 January 2001 7 SIP security requirements from 3G wireless networks 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is an individual submission for the SIP Working Group 32 of the Internet Engineering Task Force (IETF). Comments should be 33 submitted to the sip-security@eGroups.com mailing list. 35 Abstract 37 At present based on a different protocol architecture, 3G wireless 38 standards start to become more and more IP-based. The upcoming set 39 of 3G wireless specifications defined by 3GPP will include SIP 40 [RFC2543] as the session control protocol for IP-based voice and 41 multimedia. An important requirement for introducing SIP is the 42 definition of a security architecture protecting the session control 43 signaling. 45 This Internet Draft collects requirements for a SIP security 46 architecture that are related to the use of SIP in 3GPP wireless 47 networks. It is intended to stimulate the discussion about SIP 48 security and is meant as a source of input for a requirements draft 49 on SIP security. 51 Table of Contents 53 1. Definitions.....................................................2 54 2. Introduction....................................................3 55 3. Security architecture of the first release of 56 3GPP specifications (Release 99)................................4 57 4. Scope of SIP security in 3GPP...................................5 58 5. Requirements for securing SIP...................................7 59 5.1 Access domain security requirements.........................7 60 5.2 Network domain security requirements........................8 61 5.3 System requirements on security.............................8 62 6. Security Considerations.........................................9 63 7. References......................................................9 65 1. Definitions 67 Some of the following definitions related to mobile cellular 68 networks are taken from [3G TR 21.905] and [3G TR 23.821]. 70 3GPP: Third Generation Partnership Project 72 UMTS: Universal Mobile Telecommunications System 74 PLMN: Public land mobile network. A telecommunications 75 network providing 3GPP mobile cellular services, in the 76 context of this document. 78 Domain: Highest-level group of functional PLMN entities. 80 Network domain: The fixed part of a PLMN which is independent of the 81 connection technology of the terminal (eg radio, 82 wired). 84 Access domain: The part of a PLMN that is responsible for carrying 85 communication between the UE and the network domain, 86 which especially includes the air interface. 88 CS domain: Comprises all network domain entities for provision of 89 circuit-switched telecommunication services. 91 PS domain: Comprises all network domain entities for provision of 92 packet switched, IP connectivity services. 94 IMS: IM subsystem. Comprises all network domain entities 95 providing support for IP multimedia services on the 96 signaling and control level, carried on top of the PS 97 domain. This especially includes the network domain SIP 98 entities. 100 UICC: UMTS IC Card. An IC card (or 'smartcard') of defined 101 electromechanical specification which contains at least 102 one USIM. 104 Mobile user: A user who is subscribed to a mobile network, and is 105 represented by a USIM. 107 USIM: Universal Subscriber Identity Module. An application 108 residing on the UICC used for accessing services 109 provided by mobile networks, which the application is 110 able to register on with the appropriate security. 112 UE: User Equipment. A device allowing a user access to 113 network services. For the purpose of 3GPP 114 specifications the interface between the UE and the 115 network is the radio interface. A User Equipment can be 116 subdivided into a number of domains. Currently one 117 defined domain is the USIM which is part of the UE. 119 SIP NE: A network entity that belongs to the network domain of 120 a PLMN, is part of the IM subsystem, and offers the 121 functionality of a SIP server, location server or 122 proxy. 124 Visited network: The PLMN that a UE is currently roaming to. 126 Home network: The PLMN that a UE is subscribed to. In the special 127 case that a UE roams within the home network, the 128 visited equals the home network. 130 RNC: Radio Network Controller, in charge of controlling the 131 use and the integrity of the PLMN radio resources. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 135 this document are to be interpreted as described in RFC 2119. 137 2. Introduction 139 There are currently two bodies producing two different sets of 140 specifications for third generation (3G) mobile systems. These 141 bodies are known as 3GPP and 3GPP2. This draft concentrates on 142 requirements resulting from 3GPP. The views expressed in this 143 document are those of the author, not 3GPP as a whole. 145 The system specified by 3GPP is also known as UMTS. For UMTS whose 146 core network evolves out of the second generation mobile system GSM, 147 3GPP has produced a first release of 3G specifications referred to 148 as "Release 99". 150 The architecture of this 3G wireless network is based on a domain 151 concept, grouping functional network entities. The Release 99 152 network domain splits into a CS domain that is responsible for all 153 "classical" circuit-switched services and a PS domain that 154 introduces IP connectivity to the network. 156 On top of the PS domain, a future Release (so-called Release 5, 157 specifications are due to be completed by the end of 2001) of 3GPP 158 specifications introduces an IM subsystem (IMS) that shall provide 159 IP-based services with session control using the SIP protocol. 161 From a SIP point of view, the UE provides the functionality of a SIP 162 user agent, and the IM subsystem roughly consists of SIP proxies, 163 registrars and location servers that support global roaming. 165 Since there are several threats to SIP messages sent between the 166 different mobile network entities, a framework offering complete 167 security for these messages is required for Release 5. This draft 168 gives a short overview of the current 3GPP security architecture. It 169 discusses several security issues raised by the introduction of SIP 170 with the 3GPP Release 5 specifications and collects related security 171 requirements. 173 3. Security architecture of 3GPP Release 99 specifications 175 The 3GPP security architecture protecting the first generation of 3G 176 mobile networks offers mutual entity authentication and session key 177 establishment between a roaming UE and the network side. 179 Across the most exposed part of mobile networks, the air interface, 180 all data sent between a UE and the visited network is optionally 181 encrypted at the link layer. 182 In addition to encryption, signaling data is mandatorily integrity 183 protected across the air interface (more precisely, confidentiality 184 and integrity protection extend further back to the RNC, covering 185 parts of the fixed network as well). This is the signaling used to 186 control the bearers in the circuit and the packet switching domains 187 of UMTS and is different from session control signaling by an 188 application layer protocol such as SIP. 190 The protocol used for authentication and key establishment is called 191 the UMTS AKA (authentication and key agreement) protocol. It is 192 based on long-term secret keys shared between the USIM and the 193 authentication center in the home network. 195 Within a run of this protocol short-term session keys are derived. 196 Subsequently all signaling messages sent between the UE and the 197 visited network are protected by applying integrity protection and 198 encryption transforms based on these session keys.In so far, this 199 could be compared roughly to the approach taken in the IPSec 200 framework [RFC2401]. A major difference between UMTS AKA and e.g. 201 IKE [RFC2409] is that UMTS AKA has been designed especially for 202 roaming scenarios. According to 3GPP, IKE does not match the 203 requirements for these scenarios. 205 Authentication involves three parties: the roaming UE, the visited 206 network and the home network. The authenticating entities are the 207 USIM and an Authentication Center in the user’s home network as they 208 share the long-term secret key. However, the home network delegates 209 control of authentication to the visited network, mainly for 210 performance reasons. Here, mutual trust is required between the 211 visited and the home network, handled within a so-called "roaming 212 agreement". 214 The UE and the Authentication Center also establish the session keys 215 between them. The Authentication Center subsequently transfers the 216 session keys to the visited network which terminates confidentiality 217 and integrity to the UE. By using the session keys, the visited 218 network proves to the UE that it is authorized by the home network 219 to serve the UE. 221 Delegation of authentication control and transfer of session keys to 222 the visited network is realized by the transfer of authentication 223 vectors from the authentication center to the visited network. These 224 authentication vectors contain challenge-response pairs and session 225 keys. Usually several authentication vectors for a specific USIM are 226 transferred to the visited network within a single request to the 227 home network, which significantly reduces the network load between 228 visited and home network for subsequent authentications and 229 minimizes the delay the mobile user experiences. 231 The UMTS AKA protocol is specified in [3G TS 33.102]. 233 4. Scope of SIP security in 3GPP 235 This section shows why security mechanisms for SIP are important in 236 3G networks and what they shall be used for. 238 SIP security is meant for IM subsystem session control (i.e., SIP 239 messages) only. The protection of media streams, whether this is 240 end-to-end or hop-by-hop, is not in the scope of the current 3GPP 241 discussion on SIP security. 242 Therefore, this draft compiles requirements for the protection of 243 SIP messages only and does not deal with media stream security, e.g. 244 the exchange of keys for media stream encryption within SIP. 246 Human user authentication is not in the scope of this document as 247 well. A mobile user is represented by a USIM within a PLMN and a 248 secure method to authenticate a human user against the secure token 249 containing the USIM is assumed as given. 251 Within this context, each PLMN and each IM subsystem represents a 252 single domain of trust. Different PLMN operators can set up a 253 roaming agreement to establish an inter-domain trust relationship 254 between their networks. 256 The bearer level signaling of a PLMN is separated from the media 257 (e.g. voice) data, and the already in place integrity protection 258 over the air interface is only provided for the bearer level 259 signaling channels, not for media data. 260 In contrast to bearer level signaling, SIP messages as new 261 application level signaling introduced for the IM subsystem are 262 handled by the air interface as media data, and are not integrity 263 protected. Therefore the goal is to define a new mechanism for 264 protecting SIP messages between the UE and the SIP NE terminating 265 security at the network side. 267 There are different parts of mobile networks where different means 268 of protection are required. Two important parts of the IM subsystem 269 must be considered for securing SIP. These are the interface between 270 the UE and the SIP NE that terminates security at the network side 271 (access domain part), including the air interface, on the one hand 272 and IP-based traffic between SIP NEs in the IM subsystem, within the 273 same or between different networks on the other (network domain 274 part). 276 Roaming Visited Network Home Network 277 user 278 +--------------+ +------------+ 279 | | | | 280 +---+---+ + +------+ | | +-----+ | 281 | UE +<------>+<->+SIP NE+<->+<------->+<->+ AuC | | 282 +-------+ + +------+ | | +-----+ | 283 | | | | 284 +--------------+ +------------+ 286 <----------> <---------------> 287 access domain network domain 289 Figure 1: IM subsystem parts to be secured 291 For securing both access and network domain parts of the IM 292 subsystem, it is important that each single SIP message is integrity 293 protected and, optionally, confidentiality protected. 294 This shall be achieved for the access domain part by running the 295 UMTS AKA protocol during SIP registration and protecting all 296 subsequent SIP messages sent between UE and visited network by 297 applying integrity protection and encryption mechanisms, based on 298 session keys which are derived during AKA and are individual per 299 user. Theses session keys are different from the session keys used 300 for bearer level security as described in section 3. 302 The security mechanism for SIP integrity and confidentiality 303 protection for the access domain part is still open. When discussing 304 the layer at which integrity and confidentiality protection shall be 305 applied it should be taken into account that the SIP NE which 306 terminates access security at the network side is not necessarily 307 the first SIP hop from the UE perspective. Hence, there may be a 308 requirement for end-to-end security mechanisms at the SIP layer that 309 are able to pass intermediate SIP hops. Security mechanisms at lower 310 network layers, e.g. IPsec, do not provide end-to-end security in 311 this case. 313 For the provision of SIP security the USIM will have a pre-shared 314 secret key in common with the home network, where it is subscribed 315 to for IM subsystem services. For the network domain part, IP 316 packets carrying SIP messages between SIP NEs are envisaged to be 317 secured by using IPSec. 319 5. Requirements for securing SIP 321 As a general requirement, any security architecture MUST allow 322 different mechanisms for access domain security (i.e., UE - SIP NE) 323 on the one hand and network domain security (i.e., SIP NE - SIP NE) 324 on the other. This stems from different system requirements and 325 different roles of SIP entities being part of one or the other 326 network part. 328 5.1 Access domain security requirements 330 - Mutual authentication and key agreement between a mobile user 331 (represented by the USIM) and the network side MUST be supported. 332 The long-term shared secret used for authentication and key 333 agreement MUST only be known to the USIM and the home network. 335 - Integrity protection between the mobile user and the 336 SIP NE terminating integrity on the network side MUST be 337 supported. 339 - Confidentiality between the mobile user and the SIP NE 340 terminating confidentiality on the network side MUST be supported. 342 - A secure mechanism for delegating integrity or confidentiality to 343 a specific SIP NE MUST be supported. In addition, a secure 344 mechanism for delegating control of entity authentication and key 345 agreement MAY be supported. 346 This stems from the fact that control of integrity, 347 confidentiality and authentication need not necessarily be carried 348 out in the home network, or by the same entity. A secure transport 349 for the agreed session keys to the SIP NE that terminates SIP 350 integrity and confidentiality with the user MUST be provided. 352 - Any SIP security mechanism SHOULD be independent of the underlying 353 access technology that provides IP connectivity and mobility. 355 - User identity confidentiality SHOULD be supported. It should be 356 possible to hide a mobile user’s identity or other data from which 357 this identity can be derived or which allows to trace the user or 358 derive his location, while transmitted in the access domain (the 359 problem here is that the user identity needs to be sent before a 360 session key for confidentiality protection can be established). 362 5.2 Network domain security requirements 364 - Between SIP NEs of different IM subsystems mutual authentication 365 and key agreement MUST be supported. Authentication based on pre- 366 shared secret keys (instead of mandating a public-key based 367 method) MUST be supported within this mechanism. 368 Integrity protection and confidentiality between SIP NEs of 369 different IM subsystems MUST be supported. 371 - Hop-by-hop integrity and confidentiality SHOULD be supported 372 between SIP NEs within the same IM subsystem. 374 - User identity confidentiality in the network domain SHOULD be 375 supported (this will be provided by confidentiality when the 376 complete SIP messages are protected e.g. by IPsec.) 378 5.3 System requirements on security 380 - Any cryptographic mechanism that has to be executed by the mobile 381 device, especially authentication and key agreement which happens 382 in the USIM, MUST not mandate the use of public key cryptography, 383 i.e., MUST allow for symmetric key cryptography only. 385 - The limits of processing power, storage capacity of a USIM and the 386 bandwidth on the USIM-UE interface have to be taken into account 387 in the selection of mechanisms. 389 - The air interface has limited bandwidth and is error prone. 390 Security mechanisms for the air interface MUST be able to deal 391 with delays caused by high failure rates or low bandwidth. 393 - Any security solution SHOULD be scalable to accommodate a very 394 large user base (up to one billion). 396 - Any security solution SHOULD be scalable to support a large 397 number of different PLMNs (different domains of trust). 399 - Any security solution MUST support global roaming, i.e., a mobile 400 user MUST be able to get access to a visited network without 401 previous contact between the mobile user and the visited network 402 (which is currently handled by the UMTS AKA protocol described in 403 section 3 for non-IMS access). 405 - Any protocol for authentication and key agreement should be 406 efficient. It should minimize the number of roundtrips for 407 authenticating a mobile user through a visited network, to reduce 408 network load. 410 - A secure storage of long-term keys used for IM subsystem security 411 MUST be provided, on the mobile user side and on the home network 412 side. 414 - A secure storage and execution of security algorithms MUST be 415 provided. Algorithms which require access to the long-term keys 416 shall run in the same entities in which these keys are stored. 418 6. Security Considerations 420 The focus of this document is security, and security considerations 421 permeate the document. 423 7. References 425 [3G TR 21.905] 3GPP TSG SA, TR 21.905: "Vocabulary for 3GPP 426 Specifications (Release 1999)";V3.2.0, 10/2000. 427 [3G TR 23.821] 3GPP TSG SA2, TR 23.281: "Architecture 428 principles for Release 2000" 429 [3G TS 33.102] 3GPP TSG SA WG 3 Security, TS 33.102: Security 430 Architecture (Release 1999); v3.5.0, 07/2000. 431 [3G TR 33.8xx] 3GPP TSG SA WG3 Security, TR 33.8xx: Access 432 security for IP-based services (Release 2000); 433 v0.3.0, 11/2000. 434 [RFC 2119] Bradner, S., "Key words for use in RFCs to 435 Indicate Requirement Level", BCP 14, RFC 2119, 436 March 1997. 437 [RFC2401] Kent, S., and R. Atkinson, "Security 438 Architecture for the Internet Protocol", RFC 439 2401, November 1998. 440 [RFC2409] Harkins, D., and D. Carrel, "The Internet Key 441 Exchange (IKE)", RFC 2409, November 1998. 442 [RFC2543] Handley, M., H. Schulzrinne, E. Schooler, and 443 J. Rosenberg. "SIP: Session Initiation 444 Protocol", RFC 2543, March 1999. 446 Author's Address 448 Dirk Kroeselberg 449 Siemens CT IC 3 450 Otto-Hahn-Ring 6 451 81739 Munich, Germany 453 Email: dirk.kroeselberg@mchp.siemens.de