idnits 2.17.1 draft-niemi-sipping-digest-aka-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: ---------------------------------------------------------------------------- == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. 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 (February 21, 2002) is 8097 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) ** Obsolete normative reference: RFC 2617 (ref. '2') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) == Outdated reference: A later version (-09) exists of draft-ietf-sip-rfc2543bis-07 == Outdated reference: A later version (-03) exists of draft-garcia-sipping-3gpp-reqs-02 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Niemi 3 Internet-Draft Nokia 4 Expires: August 22, 2002 J. Arkko 5 V. Torvinen 6 Ericsson 7 February 21, 2002 9 HTTP Digest Authentication Using AKA 10 draft-niemi-sipping-digest-aka-00 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 22, 2002. 35 Copyright Notice 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 Abstract 41 The Hypertext Transfer Protocol (HTTP) Authentication Framework 42 includes two authentication schemes: Basic and Digest. Both schemes 43 employ a shared secret based mechanism for access authentication. 44 The Authentication and Key Agreement (AKA) mechanism performs user 45 authentication and session key distribution in Universal Mobile 46 Telecommunications System (UMTS) networks. AKA is a challenge- 47 response based mechanism that uses symmetric cryptography. This memo 48 specifies an AKA based password generation mechanism for HTTP Digest 49 access authentication. 51 Table of Contents 53 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 54 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. AKA Mechanism Overview . . . . . . . . . . . . . . . . . . . . 5 57 3. Specification of Digest AKA . . . . . . . . . . . . . . . . . 7 58 3.1 Algorithm Directive . . . . . . . . . . . . . . . . . . . . . 7 59 3.2 Creating a Challenge . . . . . . . . . . . . . . . . . . . . . 7 60 3.3 Client Authentication . . . . . . . . . . . . . . . . . . . . 8 61 3.4 Synchronization Failure . . . . . . . . . . . . . . . . . . . 9 62 3.5 Server Authentication . . . . . . . . . . . . . . . . . . . . 9 63 4. Example Digest AKA Operation . . . . . . . . . . . . . . . . . 10 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 5.1 Authentication of Clients using Digest AKA . . . . . . . . . . 12 66 5.2 Limited Use of Nonce Values . . . . . . . . . . . . . . . . . 12 67 5.3 Multiple Authentication Schemes and Algorithms . . . . . . . . 13 68 5.4 Online Dictionary Attacks . . . . . . . . . . . . . . . . . . 13 69 5.5 Session Protection . . . . . . . . . . . . . . . . . . . . . . 13 70 5.6 Replay Protection . . . . . . . . . . . . . . . . . . . . . . 14 71 5.7 Improvements to AKA Security . . . . . . . . . . . . . . . . . 14 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 75 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 76 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction and Motivation 80 The Hypertext Transfer Protocol (HTTP) Authentication Framework 81 described in RFC 2617 [2] includes two authentication schemes: Basic 82 and Digest. Both schemes employ a shared secret based mechanism for 83 access authentication. The Basic scheme is inherently insecure in 84 that it transmits user credentials in plain text. The Digest scheme 85 improves security by hiding user credentials with cryptographic 86 hashes, and additionally by providing limited message integrity. 88 The Authentication and Key Agreement (AKA) [8] mechanism performs 89 authentication and session key distribution in Universal Mobile 90 Telecommunications System (UMTS) networks. AKA is a challenge- 91 response based mechanism that uses symmetric cryptography. AKA is 92 typically run in a UMTS IM Services Identity Module (ISIM), which 93 resides on a smart card like device that also provides tamper proof 94 storage of shared secrets. 96 This document specifies a mapping of AKA parameters onto HTTP Digest 97 authentication. In essence, this mapping enables the usage of AKA as 98 a password generation mechanism for Digest authentication, thus 99 meeting the requirements set in [6] and [5]. 101 As the Session Initiation Protocol (SIP) [4] Authentication Framework 102 closely follows the HTTP Authentication Framework, Digest AKA is 103 directly applicable to SIP as well as any other embodiment of HTTP 104 Digest. 106 1.1 Terminology 108 This chapter explains the terminology used in this document. 110 AKA 111 Authentication and Key Agreement. 113 AuC 114 Authentication Center. The network element in mobile networks 115 that can authorize users either in GSM or in UMTS networks. 117 AUTN 118 Authentication Token. A 128 bit value generated by the AuC, which 119 together with the RAND parameter authenticates the server to the 120 client. 122 AUTS 123 Authentication Token. A 112 bit value generated by the client 124 upon experiencing an SQN synchronization failure. 126 CK 127 Cipher Key. An AKA session key for encryption. 129 IK 130 Integrity Key. An AKA session key for integrity check. 132 ISIM 133 IM Services Identity Module. 135 PIN 136 Personal Identification Number. Commonly assigned passcodes for 137 use with automatic cash machines, smart cards, etc. 139 RAND 140 Random Challenge. Generated by the AuC using the SQN. 142 RES 143 Authentication Response. Generated by the ISIM. 145 SIM 146 Subscriber Identity Module. GSM counter part for ISIM. 148 SQN 149 Sequence Number. Both AuC and ISIM maintain the value of the SQN. 151 UMTS 152 Universal Mobile Telecommunications System. 154 XRES 155 Expected Authentication Response. This is equal to RES. 157 1.2 Conventions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [1]. 163 2. AKA Mechanism Overview 165 This chapter describes the AKA operation in detail: 167 1. A shared secret K is established beforehand between the ISIM and 168 the Authentication Center (AuC). The secret is stored in the 169 ISIM, which resides on a smart card like, tamper proof device. 171 2. The AuC of the home network produces an authentication vector AV 172 based on the shared secret K and a sequence number SQN. The 173 authentication vector contains a random challenge RAND, network 174 authentication token AUTN, expected authentication result XRES, a 175 session key for integrity check IK, and a session key for 176 encryption CK. 178 3. The authentication vector is downloaded to a server. Optionally, 179 the server can also download a batch of AVs, containing more than 180 one authentication vector. 182 4. The server creates an authentication request, which contains the 183 random challenge RAND, and the network authenticator token AUTN. 185 5. The authentication request is delivered to the client. 187 6. Using the shared secret K and the sequence number SQN, the client 188 verifies the AUTN with the ISIM. If the verification is 189 successful, the network has been authenticated. The client then 190 produces an authentication response RES, using the shared secret 191 and the random challenge RAND. 193 7. The authentication response is delivered to the server. 195 8. The server compares the authentication response RES with the 196 expected response XRES. If the result is correct, the user has 197 been successfully authenticated, and the session keys IK and CK 198 can be used for protecting further communications between the 199 client and the server. 201 When verifying the AUTN, the client may detect, that the sequence 202 numbers between the client and the server have fallen out of sync. 203 In this case, the client produces a synchronization parameter AUTS, 204 using the shared secret K and the client SQN. The AUTS parameter is 205 delivered to the network in the authentication response, and the 206 authentication can be tried again based on authentication vectors 207 generated with the synchronized sequence number. 209 For a specification of the AKA mechanism and the generation of the 210 cryptographic parameters AUTN, RES, IK, CK, and AUTS, see reference 211 3GPP TS 33.102 [8]. 213 3. Specification of Digest AKA 215 In general, Digest AKA operation is identical to Digest operation in 216 RFC 2617 [2]. This chapter specifies the parts, in which Digest AKA 217 extends the Digest operation. 219 3.1 Algorithm Directive 221 In order to direct the client into using AKA for authentication, 222 instead of the standard password system, the RFC 2617 defined 223 algorithm directive is extended: 225 algorithm = "algorithm" EQUAL aka-namespace 226 aka-namespace = aka-version "-" algorithm-value 227 aka-version = "AKAv" 1*DIGIT 228 algorithm-value = ( "MD5" / "MD5-sess" / token ) 230 algorithm 231 A string indicating the algorithm used in producing the digest and 232 the checksum. If the directive is not understood, the nonce 233 SHOULD be ignored, and another challenge (if one is present) 234 should be used instead. The default aka-version is "AKAv1". 235 Further AKA versions can be specified, with version numbers 236 assigned by IANA [9]. When the algorithm directive is not 237 present, it is assumed to be "MD5". This indicates, that AKA is 238 not used to produce the password. 240 Example: 242 algorithm=AKAv1-MD5 244 3.2 Creating a Challenge 246 In order to deliver the AKA authentication challenge to the client in 247 Digest AKA, the nonce directive defined in RFC 2617 is extended: 249 nonce = "nonce" EQUAL aka-nonce 250 aka-nonce = LDQUOT aka-nonce-value RDQUOT 251 aka-nonce-value = 254 nonce 255 A parameter, which is populated with the Base64 [7] encoding of: 256 the AKA authentication challenge RAND; concatenated with the AKA 257 AUTN token; concatenated optionally with some server specific 258 data, as in Figure 1. 260 Example: 262 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093" 264 0 1 2 3 265 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 | RAND | 269 | | 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 | AUTN | 274 | | 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Server Data... 278 +-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 1: Generating the nonce value. 282 If the server receives a client authentication containing the "auts" 283 parameter defined in Section 3.4 that includes a valid AKA AUTS 284 parameter, the server MUST use it to generate a new challenge to the 285 client. Note that when the AUTS is present, the included "response" 286 parameter is calculated using an empty password (password of ""), 287 instead of the RES. 289 3.3 Client Authentication 291 When a client receives a Digest AKA authentication challenge, it 292 extracts the RAND and AUTN from the "nonce" parameter, and assesses 293 the AUTN token provided by the server. If the client successfully 294 authenticates the server with the AUTN, and determines that the SQN 295 used in generating the challenge is within expected range, the AKA 296 algorithms are run with the RAND challenge and shared secret K. 298 The resulting AKA RES parameter is treated as "password" when 299 calculating the response directive of RFC 2617. 301 3.4 Synchronization Failure 303 For indicating an AKA sequence number synchronization failure, and to 304 re-synchronize the SQN in the AuC using the AUTS token, a new 305 directive is defined for the "digest-response" of the "Authorization" 306 request header defined in RFC 2617: 308 auts = "auts" EQUAL auts-param 309 auts-param = LDQUOT auts-value RDQUOT 310 auts-value = 312 auts 313 A string carrying a base64 encoded AKA AUTS parameter. This 314 directive is used to re-synchronize the server side SQN. If the 315 directive is present, the client doesn't use any password when 316 calculating its credentials. Instead, the client MUST calculate 317 its credentials using an empty password (password of ""). 319 Example: 321 auts="5ccc069c403ebaf9f0171e9517f40e41" 323 Upon receiving the "auts" parameter, the server will check the 324 validity of the parameter value using the shared secret K. A valid 325 AUTS parameter is used to re-synchronize the SQN in the AuC. The 326 synchronized SQN is then used to generate a fresh authentication 327 vector AV, with which the client is then re-challenged. 329 3.5 Server Authentication 331 Even though AKA provides inherent mutual authentication with the AKA 332 AUTN token, mutual authentication mechanisms provided by Digest may 333 still be useful in order to provide message integrity. 335 In Digest AKA, the server uses the AKA XRES parameter as "password" 336 when calculating the "response-auth" of the "Authentication-Info" 337 header defined in RFC 2617. 339 4. Example Digest AKA Operation 341 Figure 2 below describes a message flow describing a Digest AKA 342 process of authenticating a SIP request, namely the SIP REGISTER 343 request. 345 Client Server 347 | 1) REGISTER | 348 |------------------------------------------------------>| 349 | | 350 | +-----------------------------+ 351 | | Server runs AKA algorithms, | 352 | | generates RAND and AUTN. | 353 | +-----------------------------+ 354 | | 355 | 2) 401 Unauthorized | 356 | WWW-Authenticate: Digest | 357 | (RAND, AUTN delivered) | 358 |<------------------------------------------------------| 359 | | 360 +------------------------------------+ | 361 | Client runs AKA algorithms on ISIM,| | 362 | verifies AUTN, derives RES | | 363 | and session keys. | | 364 +------------------------------------+ | 365 | | 366 | 3) REGISTER | 367 | Authorization: Digest (RES is used) | 368 |------------------------------------------------------>| 369 | | 370 | +------------------------------+ 371 | | Server checks the given RES, | 372 | | and finds it correct. | 373 | +------------------------------+ 374 | | 375 | 4) 200 OK | 376 | Authentication-Info: (XRES is used) | 377 |<------------------------------------------------------| 378 | | 380 Figure 2: Message flow representing a successful authentication. 382 1) Initial request 384 REGISTER sip:home.mobile.biz SIP/2.0 386 2) Response containing a challenge 388 SIP/2.0 401 Unauthorized 389 WWW-Authenticate: Digest 390 realm="RoamingUsers@mobile.biz", 391 qop="auth-int", 392 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 393 opaque="5ccc069c403ebaf9f0171e9517f40e41", 394 algorithm=AKAv1-MD5 396 3) Request containing credentials 398 REGISTER sip:home.mobile.biz SIP/2.0 399 Authorization: Digest 400 username="jon.dough@mobile.biz", 401 realm="RoamingUsers@mobile.biz", 402 nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", 403 uri="sip:home.mobile.biz", 404 qop=auth-int, 405 nc=00000001, 406 cnonce="0a4f113b", 407 response="6629fae49393a05397450978507c4ef1", 408 opaque="5ccc069c403ebaf9f0171e9517f40e41" 410 4) Successful response 412 SIP/2.0 200 OK 413 Authentication-Info: 414 qop=auth-int, 415 rspauth="6629fae49393a05397450978507c4ef1", 416 cnonce="0a4f113b", 417 nc=00000001 419 5. Security Considerations 421 In general, Digest AKA is vulnerable to the same security threats as 422 HTTP authentication [2]. This chapter discusses the relevant 423 exceptions. 425 5.1 Authentication of Clients using Digest AKA 427 AKA is typically -- though this isn't a theoretical limitation -- run 428 on an ISIM application that usually resides in a tamper resistant 429 smart card. Interfaces to the ISIM exist, which enable the host 430 device to request authentication to be performed on the card. 431 However, these interfaces do not allow access to the long-term secret 432 outside the ISIM, and the authentication can only be performed if the 433 device accessing the ISIM has knowledge of a PIN code, shared between 434 the user and the ISIM. Such PIN codes are typically obtained from 435 user input, and are usually required when the device is powered on. 437 The use of tamper resistant cards with secure interfaces implies that 438 Digest AKA is typically more secure than regular Digest 439 implementations, as neither possession of the host device nor Trojan 440 Horses in the software give access to the long term secret. Where a 441 PIN scheme is used, the user is also authenticated when the device is 442 powered on. However, there may be a difference in the resulting 443 security of Digest AKA, compared to traditional Digest 444 implementations, depending of course on whether those implementations 445 cache/store passwords that are received from the user. 447 5.2 Limited Use of Nonce Values 449 The Digest scheme uses server-specified nonce values to seed the 450 generation of the request-digest value. The server is free to 451 construct the nonce in such a way, that it may only be used from a 452 particular client, for a particular resource, for a limited period of 453 time or number of uses, or any other restrictions. Doing so 454 strengthens the protection provided against, for example, replay 455 attacks. 457 Digest AKA limits the applicability of a nonce value to a particular 458 ISIM. Typically, the ISIM is accessible only to one client device at 459 a time. However, the nonce values are strong and secure even though 460 limited to a particular ISIM. 462 A server may allow each nonce value to be used only once by sending a 463 next-nonce directive in the Authentication-Info header field of every 464 response. However, this may cause a synchronization failure, and 465 consequently some additional round trips in AKA, if the same SQN 466 space is also used for other access schemes at the same time. 468 5.3 Multiple Authentication Schemes and Algorithms 470 In HTTP authentication, a user agent MUST choose the strongest 471 authentication scheme it understands and request credentials from the 472 user based upon that challenge. 474 In general, using passwords generated by Digest AKA with other HTTP 475 authentication schemes is not recommended even though the realm 476 values or protection domains would coincide. In these cases, a 477 password should be requested from the end-user instead. Digest AKA 478 passwords MUST NOT be re-used with such HTTP authentication schemes, 479 which send the password in clear. In particular, AKA passwords MUST 480 NOT be re-used with HTTP Basic. 482 The same principle must be applied within a scheme if several 483 algorithms are supported. A client receiving an HTTP Digest 484 challenge with several available algorithms MUST choose the strongest 485 algorithm it understands. For example, Digest with "AKAv1-MD5" would 486 be stronger than Digest with "MD5". 488 5.4 Online Dictionary Attacks 490 Since user-selected passwords are typically quite simple, it has been 491 proposed that servers should not accept passwords for HTTP Digest, 492 which are in the dictionary [2]. This potential threat does not 493 exist in HTTP Digest AKA because the algorithm will use ISIM 494 originated passwords. However, the end-user must still be careful 495 with PIN codes. Even though HTTP Digest AKA password requests are 496 never displayed to the end-user, she will be authenticated to the 497 ISIM via a PIN code. Commonly known initial PIN codes are typically 498 installed to the ISIM during manufacturing and if the end-users do 499 not change them, there is a danger that an unauthorized user may be 500 able to use the device. Naturally this requires that the 501 unauthorized user has access to the physical device, and that the 502 end-user has not changed the initial PIN code. For this reason, end- 503 users are strongly encouraged to change their PIN codes when they 504 receive an ISIM. 506 5.5 Session Protection 508 Digest AKA is able to generate additional session keys for integrity 509 (IK) and confidentiality (CK) protection. Even though this document 510 does not specify the use of these additional keys, they may be used 511 for creating additional security within HTTP authentication or some 512 other security mechanism. 514 5.6 Replay Protection 516 Optionally, AKA allows sequence numbers to be tracked for each 517 authentication, with the SQN parameter. This allows authentications 518 to be replay protected even if the RAND parameter happened to be the 519 same for two authentication requests. More importantly, this offers 520 additional protection for the case where an attacker replays an old 521 authentication request sent by the network. The client will be able 522 to detect that the request is old, and refuse authentication. This 523 proves liveliness of the authentication request even in the case 524 where a MitM attacker tries to trick the client into providing an 525 authentication response, and then replaces parts of the message with 526 something else. In other words, a client challenged by Digest AKA is 527 not vulnerable for chosen plain text attacks. Finally, frequent 528 sequence number errors would reveal an attack where the tamper- 529 resistant card has been cloned and is being used in multiple devices. 531 The downside of sequence number tracking is that servers must hold 532 more information for each user than just their long-term secret, 533 namely the current SQN value. However, this information is typically 534 not stored in the SIP nodes, but in dedicated authentication servers 535 instead. 537 5.7 Improvements to AKA Security 539 Even though AKA is perceived as a secure mechanism, Digest AKA is 540 able to improve it. More specifically the AKA parameters carried 541 between the client and the server during authentication may be 542 protected along with other parts of the message, by using using 543 Digest AKA. This is not possible with plain AKA. 545 6. IANA Considerations 547 This document specifies a namespace for the AKA versions in Section 548 3.1, with the default version being "AKAv1". Following the policies 549 outlined in [3], versions above 1 are allocated as Expert Review. 551 References 553 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 554 Levels", BCP 14, RFC 2119, March 1997. 556 [2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 557 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 558 Basic and Digest Access Authentication", RFC 2617, June 1999. 560 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 561 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 563 [4] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation 564 Protocol", draft-ietf-sip-rfc2543bis-07 (work in progress), 565 February 2002. 567 [5] Garcia, M., "3GPP requirements on SIP", draft-garcia-sipping- 568 3gpp-reqs-02 (work in progress), November 2001. 570 [6] Arkko, J., "3GPP Requirements for SIP Authentication", draft- 571 uusitalo-sipping-authentication-00 (work in progress), February 572 2002. 574 [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 575 Extensions (MIME) Part One: Format of Internet Message Bodies", 576 RFC 2045, November 1996. 578 [8] 3rd Generation Partnership Project, "Security Architecture 579 (Release 4)", TS 33.102, December 2001. 581 [9] http://www.iana.org, "Assigned Numbers", February 2002. 583 Authors' Addresses 585 Aki Niemi 586 Nokia 587 P.O. Box 301 588 NOKIA GROUP, FIN 00045 589 Finland 591 Phone: +358 50 389 1644 592 EMail: aki.niemi@nokia.com 593 Jari Arkko 594 Ericsson 595 Hirsalantie 1 596 Jorvas, FIN 02420 597 Finland 599 Phone: +358 40 5079256 600 EMail: jari.arkko@ericsson.com 602 Vesa Torvinen 603 Ericsson 604 Joukahaisenkatu 1 605 Turku, FIN 20520 606 Finland 608 Phone: +358 40 7230822 609 EMail: vesa.torvinen@ericsson.fi 611 Appendix A. Acknowledgements 613 The authors would like to thank Sanjoy Sen, Jonathan Rosenberg, Pete 614 McCann, Tao Haukka, Ilkka Uusitalo, Henry Haverinen, John Loughney 615 and Allison Mankin. 617 Full Copyright Statement 619 Copyright (C) The Internet Society (2002). All Rights Reserved. 621 This document and translations of it may be copied and furnished to 622 others, and derivative works that comment on or otherwise explain it 623 or assist in its implementation may be prepared, copied, published 624 and distributed, in whole or in part, without restriction of any 625 kind, provided that the above copyright notice and this paragraph are 626 included on all such copies and derivative works. However, this 627 document itself may not be modified in any way, such as by removing 628 the copyright notice or references to the Internet Society or other 629 Internet organizations, except as needed for the purpose of 630 developing Internet standards in which case the procedures for 631 copyrights defined in the Internet Standards process must be 632 followed, or as required to translate it into languages other than 633 English. 635 The limited permissions granted above are perpetual and will not be 636 revoked by the Internet Society or its successors or assigns. 638 This document and the information contained herein is provided on an 639 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 640 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 641 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 642 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 643 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 645 Acknowledgement 647 Funding for the RFC Editor function is currently provided by the 648 Internet Society.