idnits 2.17.1 draft-hiller-aaa-diamaka-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. 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. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '2' on line 48 looks like a reference -- Missing reference section? '3' on line 57 looks like a reference -- Missing reference section? '4' on line 61 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Authentication, Authorization, and Accounting Tom Hiller 3 Internet Draft Peter J. McCann 4 Document: draft-hiller-aaa-diamaka-00.txt Lucent Technologies 5 Category: Informational February, 2001 7 DIAMETER Support for Authentication and Key Agreement (AKA) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 1. Abstract 31 The Authentication and Key Agreement (AKA) protocol is a widely 32 used mechanism for authenticating mobile nodes in wireless 33 networks. This draft proposes new DIAMETER AVPs to carry AKA 34 parameters, which will enable DIAMETER to serve as an inter-domain 35 transport mechanism for AKA messages. 37 Because AKA was designed for a slightly different trust 38 environment than that likely to be encountered in a DIAMETER-based 39 network, we also discuss how AKA can be deployed in a DIAMETER 40 environment to provide additional authenticity guarantees. 42 2. Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 45 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 46 "OPTIONAL" in this document are to be interpreted as described in 47 RFC-2119 [2]. 49 DIAMETER AKA February, 2001 51 3. Introduction 53 Authentication and Key Agreement (AKA) is a mutual authentication 54 algorithm involving a set of message exchanges between mobile node 55 (MN) and entities in the visited and home network. The basic 56 Authentication and Key Agreement (AKA) protocol is described in 57 the 3GPP document 3G TS 33.102 [3]. A by-product of AKA operation 58 is the generation of integrity and encryption keys. Wireless SDOs 59 such as 3GPP and 3GPP2 plan to support AKA as the primary means of 60 authenticating mobile nodes. AKA extensions have already been 61 proposed for SIP [4]. 63 3GPP2 plans to support authentication and authorization via the 64 use of DIAMETER. DIAMETER support is being considered in 3GPP. 65 This contribution proposes extensions to DIAMETER that will allow 66 it to serve as a transport for AKA parameters during the 67 authentication procedure. For ease of reading, DIAMETER augmented 68 with AKA extensions is simply referred to in this contribution as 69 �DIAMETER AKA�. 71 4. Overview of AKA 73 AKA is a 3-party protocol that takes place between a client, a 74 service provider, and a home authentication center. For the 75 explanation below, we assume that the service being used is basic 76 network access as in today�s cellular network; that the service 77 provider is a visited wireless carrier; and that the home 78 authentication center is associated with a home network. In this 79 case the client is a mobile node (MN), which will carry out AKA 80 negotiation with a visited AAA server (VAAA), which will in turn 81 communicate with a home AAA server (HAAA). However, the reader 82 should keep in mind that AKA is a generic authentication and key 83 agreement mechanism that could be used for other types of 84 services, as outlined in later sections of this document. In this 85 section we assume that the protocol used to carry AKA parameters 86 between the client and service provider is some wireless link 87 layer, but in other scenarios the particular protocol used may 88 differ. For all scenarios, we assume that DIAMETER is the 89 protocol of choice between VAAA and HAAA. 91 Initially, the MN is given an identity, which in cellular 92 applications is the IMSI, and a secret K that it shares with HAAA. 93 Upon connecting to the visited network, the MN transmits this 94 identity to the VAAA. The VAAA uses the identity to locate the 95 HAAA and make an authentication data request, which returns a set 96 of authentication vectors (AVs) from the home network. 98 Each AV contains a set of parameters (RAND, XRES, CK, IK, AUTN). 99 RAND is a random number generated by the home network. XRES is 100 DIAMETER AKA February, 2001 102 the expected response from the MN that would indicate a successful 103 authentication. CK and IK are the Cipher Key and Integrity Key 104 that should be used to protect the subsequent link layer data, 105 assuming authentication was successful. The MN derives CK and IK 106 by applying a key generating function to RAND, using the shared 107 secret K known to the MN and HAAA. Finally, AUTN is itself 108 another vector consisting of the elements (SQN+AK, AMF, MAC). 109 Here SQN+AK is a monotonically increasing sequence number SQN 110 XORed with an Anonymity Key AK, which is computed as a secure hash 111 of RAND. AMF is a key management field that is used during re- 112 synchronization procedures and for other purposes. Finally, MAC 113 is a message authentication code computed over SQN, RAND, and AMF. 114 All secure hashes (key generating and message authentication 115 functions) are parameterized by the secret key K, so they are 116 unique to a given mobile node. 118 Upon receipt of the AV set, the VAAA chooses the next AV and 119 transmits (RAND, AUTN) from the AV to the MN. Note that CK and IK 120 are not transmitted to the MN. However, because the MN possesses 121 the secret key K, it can derive the AK from RAND and hence can 122 derive the SQN from the SQN+AK present in AUTN. This allows the 123 MN to compute an expected value for MAC based on the inputs SQN, 124 RAND, and AMF, and to compare this to the MAC received in AUTN. 125 If the result matches, and if the sequence number SQN is in an 126 acceptable range relative to the last authentication that was 127 performed, the MN can verify that the VAAA did indeed get the AV 128 from HAAA. This provides some assurance that the MN is 129 communicating with a legitimate visited network. 131 Now the MN must prove its identity to the VAAA. It does so by 132 computing RES, which is a simple message authentication function 133 applied to RAND. It transmits this value to VAAA, which compares 134 it to XRES. If the values match, the VAAA can assume that it is 135 communicating with a legitimate MN that is in possession of the 136 secret key K used to generate the AV. Also, it is now in agreement 137 on CK and IK that are used to encrypt and authenticate data to and 138 from the MN for the link layer session. 140 5. Trust Model Issues 142 The AKA protocol provides the proper guarantees for the 143 environment in which it was designed to operate: that of a fairly 144 small number of wireless operators communicating over a secure 145 network, and with a large degree of trust among the various 146 carriers. However, as we move to an all-IP wireless network, 147 there are likely to be many more carriers supporting different 148 types of access networks, and they will be interconnected by a 149 network of brokers each of whom acts as a manager for many pair- 150 wise trust relationships. As such, there may not be a direct 151 DIAMETER AKA February, 2001 153 contractual or trust relationship between the VAAA and HAAA when a 154 MN roams to a given visited network. 156 In particular, AKA allows the comparison of RES with XRES to be 157 performed completely in the VAAA. This gives the HAAA no 158 assurance that a legitimate MN was actually connected to VAAA. 159 For this reason we propose that AKA authentication with DIAMETER 160 proceed in two steps, one which retrieves AUTN but does not expose 161 XRES to the VAAA, and a second round-trip where the home network 162 can actually compare RES to XRES. Then the HAAA can return a 163 DIAMETER Access-Accept or -Reject as appropriate to the VAAA. 164 This would be in accordance with usual IETF AAA based 165 authentication models. 167 This extra step introduces an additional round-trip through the 168 AAA infrastructure. A potential remedy to this situation would be 169 to alter AKA protocol such that the MN includes self-contained 170 authentication credentials, based on a timestamp, sequence number, 171 and random value. When this request is presented to the HAAA, the 172 HAAA can immediately verify the identity of the MN and release a 173 set of standard AKA AV (i.e., including XRES) to the VAAA. The 174 VAAA then compares RES with XRES in the subsequent response from 175 the MN. This solution would have improved latency, but it implies 176 a change to the basic AKA protocol, which may not be possible in a 177 legacy environment. 179 6. Application Scenarios 181 Figures 1-3 identify application scenarios for DIAMETER AKA in an 182 all-IP wireless network. 184 Figure 1 shows a mobile using AKA for device level authentication. 185 Note that in this scenario, the keys IK and CK could be used for 186 over-the-air encryption and integrity protection of data and 187 signaling traffic. This is because the HAAA provides CK and IK to 188 the VAAA via the Authentication Vector (AV), which, in turn, 189 passes the AV to the link layer access network element. 191 Figure 2 shows a legacy (circuit voice) mobile node connecting to 192 a network that supports DIAMETER AKA. This network contains a 193 VAAA that communicates with an HAAA via DIAMETER. The HAAA may 194 gateway the AKA parameters to a legacy HLR-based authentication 195 center to which the mobile node is homed. 197 Figure 3 shows a mobile with a SIP client being authenticated by a 198 SIP server. The SIP registrations contain AKA extensions. The SIP 199 server generates DIAMETER AKA messages directly. The SIP server 200 could be in a wireless carrier network, private network, or the 201 network of a third party provider. N.B. The 3GPP and 3GPP2 SDOs 202 DIAMETER AKA February, 2001 204 place the authenticating SIP server only in the home network. In 205 this case there might not be a need for an interdomain AAA 206 protocol. However, we show this scenario to cover other 207 relationships that might exist between a SIP server and the home 208 network. 210 DIAMETER AKA February, 2001 212 +-------------+ +-------------+ 213 | | | | 214 | VAAA +-------+ HAAA 215 | | | | 216 +------+------+ +-------------+ 217 | 218 | 219 +----------+ +------+------+ 220 | | | Radio | 221 | Mobile +---+ Access | 222 | Station | | Network | 223 +----------+ +-------------+ 225 Figure 1: Network Access using DIAMETER-AKA 227 +-------------+ +-------------+ 228 | | | | 229 | VAAA +-------|HAAA/Gateway | 230 | | | | 231 +-----+-------+ +-------\-----+ 232 | \ 233 | +------\------+ 234 +----------+ +------+------+ | | 235 | Mobile | | Radio Access| | HLR | 236 | Station +--+ Network | | | 237 | | | | +-------------+ 238 +----------+ +-------------+ 240 Figure 2: Network Access using Legacy HLR 242 +-------------+ +-------------+ 243 | | | | 244 | VAAA +-------+ HAAA 245 | | | | 246 +-----+-------+ +-------------+ 247 | 248 | 249 +----------+ +------+------+ 250 | Mobile | | SIP | 251 | Station +--+ Server | 252 | | | | 253 +----------+ +-------------+ 255 Figure 3: Application-layer (SIP) access using DIAMETER AKA. 257 DIAMETER AKA February, 2001 259 In all cases, the following statements apply: 261 - The mobile and network entity or entities involved mutually 262 authenticate each other. 264 - The mobile and some participating entity in the network may use 265 keys derived from AKA message exchanges (i.e., the AV) for 266 integrity or encryption purposes. This could apply to data link 267 layer or application layer protection mechanisms. 269 7. Protocol Extensions 271 Section 5 outlined two approaches. The first approach requires two 272 traversals and places the RES and XRES comparison in the HAAA 273 (i.e. the HAAA does not send the XRES in the AV to the VAAA). The 274 second approach requires only one traversal but relies on a 275 challenge from the VAAA followed by a corresponding response from 276 the MN. 278 The AKA Request AVP is given in Figure 4. It is an optional AVP 279 for use only when the MN supports the response to a global 280 challenge in its initial request for service. If not then only the 281 NAI AVP is present in the Access Request, which may require the 282 HAAA to withhold XRES in its response, forcing a two round trip 283 authentication procedure. 285 The AKA Response AVP is given in Figure 5. It is used to supply 286 the VAAA with the random challenge plus authentication information 287 to be sent to the MN. 289 The AKA Keys AVP is given in Figure 6. It is used to supply 290 encryption and integrity keys to the VAAA after the HAAA has 291 verified the identity of the MN. It may be included in the first 292 response if the AKA Request AVP was included in the initial 293 request from the VAAA. Otherwise it should only be included in a 294 second response to the VAAA after the HAAA has compared RES with 295 XRES. 297 The AKA Request Result AVP is given in Figure 7. This is used 298 during the two-round AKA protocol to communicate the MN's response 299 to the HAAA. 301 DIAMETER AKA February, 2001 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 306 | AVP Code | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | AVP Length |Reserved |P|R|V|R|M| 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 + + 312 | | 313 + G-RAND + 314 | | 315 + + 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 + + 320 | | 321 + AUTHR + 322 | | 323 + + 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 4: AKA Request AVP 328 DIAMETER AKA February, 2001 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 333 | AVP Code | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | AVP Length |Reserved |P|R|V|R|M| 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 + + 339 | | 340 + RAND + 341 | | 342 + + 343 | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 + SQN+AK +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | AMF | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | 350 + + 351 | | 352 + MAC + 353 | | 354 + + 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Figure 5: AKA Response AVP 359 DIAMETER AKA February, 2001 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 364 | AVP Code | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | AVP Length |Reserved |P|R|V|R|M| 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 + + 370 | | 371 + XRES + 372 | | 373 + + 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 + + 378 | | 379 + CK + 380 | | 381 + + 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | | 385 + + 386 | | 387 + IK + 388 | | 389 + + 390 | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 6: AKA Key AVP 394 DIAMETER AKA February, 2001 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 399 | AVP Code | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | AVP Length |Reserved |P|R|V|R|M| 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | | 404 + + 405 | | 406 + RES + 407 | | 408 + + 409 | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Figure 7: AKA Request Result AVP 414 8. Security Considerations 416 This draft provides a basic transport function for the parameters 417 of AKA, which is itself a protocol designed to authenticate the 418 identity of a mobile node and to distribute keying material to a 419 service provider. However, we rely on the DIAMETER infrastructure 420 itself to guarantee that keying material is not exposed or 421 tampered with between the VAAA and the HAAA. If one or more 422 intervening brokers are present on the path between VAAA and HAAA, 423 then mechanisms for end-to-end security in DIAMETER (which are 424 outside the scope of this draft) should be applied. In any case 425 we assume that any two peer DIAMETER servers will make use of IP 426 Security mechanisms to protect data in transit. 428 8. References 430 1 Bradner, S., "The Internet Standards Process -- Revision 3", 431 BCP 9, RFC 2026, October 1996. 433 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 434 Levels", BCP 14, RFC 2119, March 1997 436 rd 437 3 3G TS 33.102 version 3.4.0 Release 99; 3 Generation 438 Partnership Project; Technical Specification Group Services and 439 System Aspecs; 3G Security 440 DIAMETER AKA February, 2001 442 4 UMTS AKA in SIP; S3-000456; 3GPP TSG SA WG3 Security; S3#14; 443 August 2-4 2000 445 9. Acknowledgments 447 Semyon Mizikovsky provided valuable review and feedback on this 448 draft. 450 10. Author's Addresses 452 Peter J. McCann 453 Lucent Technologies 454 Rm 2Z-305 455 263 Shuman Blvd 456 Naperville, IL 60566-7050 457 USA 459 Phone: +1 630 713 9359 460 FAX: +1 630 713 4982 461 EMail: mccap@lucent.com 463 Tom Hiller 464 Lucent Technologies 465 Rm 2F-218 466 263 Shuman Blvd 467 Naperville, IL 60566-7050 468 USA 470 Phone: +1 630 979 7673 471 FAX: +1 630 979 7673 472 EMail: tom.hiller@lucent.com 474 Intellectual Property Statement 476 The IETF takes no position regarding the validity or scope of any 477 intellectual property or other rights that might be claimed to 478 pertain to the implementation or use of the technology described 479 in this document or the extent to which any license under such 480 rights might or might not be available; neither does it represent 481 that it has made any effort to identify any such rights. 482 Information on the IETF's procedures with respect to rights in 483 standards-track and standards-related documentation can be found 484 in BCP-11. Copies of claims of rights made available for 485 publication and any assurances of licenses to be made available, 486 or the result of an attempt made to obtain a general license or 487 DIAMETER AKA February, 2001 489 permission for the use of such proprietary rights by implementers 490 or users of this specification can be obtained from the IETF 491 Secretariat. 493 The IETF invites any interested party to bring to its attention 494 any copyrights, patents or patent applications, or other 495 proprietary rights that may cover technology that may be required 496 to practice this standard. Please address the information to the 497 IETF Executive Director. 499 Full Copyright Statement 501 Copyright (C) The Internet Society (2000). All Rights Reserved. 502 This document and translations of it may be copied and furnished 503 to others, and derivative works that comment on or otherwise 504 explain it or assist in its implementation may be prepared, 505 copied, published and distributed, in whole or in part, without 506 restriction of any kind, provided that the above copyright notice 507 and this paragraph are included on all such copies and derivative 508 works. However, this document itself may not be modified in any 509 way, such as by removing the copyright notice or references to the 510 Internet Society or other Internet organizations, except as needed 511 for the purpose of developing Internet standards in which case the 512 procedures for copyrights defined in the Internet Standards 513 process must be followed, or as required to translate it into 514 languages other than English. 516 The limited permissions granted above are perpetual and will not 517 be revoked by the Internet Society or its successors or assigns. 519 This document and the information contained herein is provided on 520 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 521 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 522 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 523 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 524 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.