idnits 2.17.1 draft-perkins-aaav6-06.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 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.) ** The document seems to lack an Authors' Addresses Section. ** 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 too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 132: '... SHOULD NOT forward packets to that ...' RFC 2119 keyword, line 328: '...lient identifier MAY be a NAI or an IP...' RFC 2119 keyword, line 329: '... The NAI MAY also identify the user ...' RFC 2119 keyword, line 335: '... in the protocol SHOULD verify the fre...' RFC 2119 keyword, line 365: '...d AAAH. The credential SHOULD securely...' (56 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 677 has weird spacing: '... relay ser...' ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [4], but that reference does not seem to mention RFC 2119 either. -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2486 (ref. '1') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2284 (ref. '2') (Obsoleted by RFC 3748) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2989 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '6') == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-15 ** Obsolete normative reference: RFC 2461 (ref. '8') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3220 (ref. '9') (Obsoleted by RFC 3344) ** Obsolete normative reference: RFC 2462 (ref. '10') (Obsoleted by RFC 4862) Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Submitted to AAA Working Group Charles E. Perkins 2 INTERNET DRAFT Ernie Tacsik 3 1 May 2003 Nokia 4 Thomas Eklund 5 Xelerated Networks 7 AAA for IPv6 Network Access 8 draft-perkins-aaav6-06.txt 10 Status of This Memo 12 Distribution of this memo is unlimited. 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 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 27 The list of Internet-Draft Shadow Directories can be accessed at: 28 http://www.ietf.org/shadow.html. 30 Abstract 32 IPv6 nodes (clients) need a way to offer credentials to the AAA 33 infrastructure in order to be granted access to the local network. 34 For IPv6, it will be more efficient and thus reasonable to expect 35 such access controls to be exerted by IPv6 routers, possibly as 36 part of performing their role as DHCPv6 relays. Routers and DHCPv6 37 servers are expected to work in conjunction with AAA servers to 38 determine whether or not the client's credentials are valid. Routers 39 can exert such network access control by the device of carefully 40 controlling entries in their packet filter and Neighbor Cache. 42 Contents 44 Status of This Memo i 46 Abstract i 48 1. Introduction 1 50 2. Terminology 2 52 3. General Framework 4 53 3.1. Protocol Description . . . . . . . . . . . . . . . . . . 4 54 3.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 6 55 3.3. Replay Protection . . . . . . . . . . . . . . . . . . . . 6 56 3.4. AAA Credential . . . . . . . . . . . . . . . . . . . . . 7 58 4. Instantiation with Stateless Address Autoconfiguration 7 59 4.1. Structure of Protocol Messages . . . . . . . . . . . . . 7 60 4.1.1. AAAv6 Protocol Message types . . . . . . . . . . 7 61 4.1.2. AAA Protocol Message options . . . . . . . . . . 8 63 5. Protocol Overview 9 64 5.1. Basic operation . . . . . . . . . . . . . . . . . . . . . 9 65 5.2. Challenge Request . . . . . . . . . . . . . . . . . . . . 11 66 5.3. Initiation of the AAA Process . . . . . . . . . . . . . . 11 67 5.4. Termination . . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Instantiation with Mobile IPv6 12 71 7. Instantiation with DHCPv6 12 72 7.1. Mapping the general protocol . . . . . . . . . . . . . . 12 73 7.2. Mapping the message options . . . . . . . . . . . . . . . 13 74 7.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 14 75 7.3.1. Basic operation . . . . . . . . . . . . . . . . . 14 76 7.3.2. Termination . . . . . . . . . . . . . . . . . . . 16 77 7.4. Access Control . . . . . . . . . . . . . . . . . . . . . 16 79 8. Requesting a Home Challenge 16 81 9. Message Formats for Stateless Address Autoconfiguration 17 82 9.1. AAA Challenge Option . . . . . . . . . . . . . . . . . . 17 83 9.2. AAA Protocol Messages . . . . . . . . . . . . . . . . . . 17 84 9.3. AAA Protocol Message Options . . . . . . . . . . . . . . 19 85 9.3.1. Client Identifier option . . . . . . . . . . . . 19 86 9.3.2. Security Data . . . . . . . . . . . . . . . . . . 20 87 9.3.3. Challenge . . . . . . . . . . . . . . . . . . . . 21 88 9.3.4. Generalized Key Reply . . . . . . . . . . . . . . 21 89 9.3.5. Timestamp . . . . . . . . . . . . . . . . . . . . 23 90 9.3.6. IPv6 Address . . . . . . . . . . . . . . . . . . 23 91 9.3.7. Lifetime . . . . . . . . . . . . . . . . . . . . 24 92 9.3.8. Embedded Data . . . . . . . . . . . . . . . . . . 24 94 10. Message Formats for Stateful Address Autoconfiguration with 95 DHCPv6 26 96 10.1. Challenge option . . . . . . . . . . . . . . . . . . . . 26 97 10.2. Client NAI option . . . . . . . . . . . . . . . . . . . . 27 98 10.3. Timestamp option . . . . . . . . . . . . . . . . . . . . 27 99 10.4. Lifetime option . . . . . . . . . . . . . . . . . . . . . 28 100 10.5. Security Data option . . . . . . . . . . . . . . . . . . 28 101 10.6. Generalized Key Reply option . . . . . . . . . . . . . . 29 103 11. Security Considerations 30 105 12. Open Issues and Discussion 30 106 12.1. Packet Service Filter . . . . . . . . . . . . . . . . . . 30 107 12.2. Use of Destination Options . . . . . . . . . . . . . . . 30 108 12.3. AAAL . . . . . . . . . . . . . . . . . . . . . . . . . . 30 109 12.4. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 Contributors 31 113 References 31 115 Addresses 32 117 1. Introduction 119 This document proposes a way for IPv6 nodes (clients) to offer 120 credentials to a local AAA server in order to be granted access to 121 the local network. Whereas for IPv4 it is not clear that routers and 122 DHCP will be equipped to handle such functions, we believe that it is 123 more efficient and thus reasonable to expect such access controls to 124 be exerted by IPv6 routers, possibly as part of performing their role 125 as DHCPv6 relays. Routers and DHCPv6 servers are expected to work in 126 conjunction with AAA servers to determine whether or not the client's 127 credentials are valid. 129 Routers can exert such network access control by carefully 130 controlling entries in their packet filter and Neighbor Cache [8]. 131 If a client does not supply verifiable credentials, then the router 132 SHOULD NOT forward packets to that client. Furthermore, such 133 uncredentialed devices should have no access (or perhaps only very 134 limited access) to the other network links adjacent to the router. 135 Only in this way can a new client be prevented from abusing network 136 connectivity before its authorization is complete. 138 2. Terminology 140 This document makes use of many terms defined in recent AAA 141 requirements documents (for example, [6], [5]). The general 142 framework consists of nodes in the following general relationship: 144 Local Domain Home Domain 145 +------------------------+ +--------------+ 146 | +-------------+ | | +------+ | 147 | | | | | | | | 148 | | AAAL | | | | AAAH | | 149 | | +---------------+ | | | 150 | +----+---+----+ | | +------+ | 151 | | | +------+ | | | 152 | | | | other| | +--------------+ 153 +------+ | +----+-+-+----+ | | 154 | | | | | | | | C = client 155 | C |- -|- -| A | F |----+ | A = attendant 156 | | | | | | | F = packet filter 157 +------+ | +------+------+ | other = other AAA clients 158 | | AAAL = local authority 159 +------------------------+ AAAH = home authority 161 From a system point of view: 162 +--------------------------+ +----------------+ 163 | Router System | | AAA Server | 164 +--------------+ | | | Infrastructure | 165 | Client System| | +--------+ +---------+ | | +------------+ | 166 | | | | F | | A +-------+ AAAL | | 167 | | | +--------+ +---------+ | | | | | 168 | +------+ | | | | | | +-----+------+ | 169 | | C | | | +------+------+ | | | | 170 | +------+ | | Controlled | Uncontrolled| ================== 171 +------|-------+ +------------|-------------+ | | | 172 | | | +-----+------+ | 173 +-----------------------+ | | AAAH | | 174 | | | | 175 | +------------+ | 176 +----------------+ 178 The entities in the pictures above are defined as follows: 180 Client System: 181 The client system is the node requesting access to the 182 network. 184 Client: 185 The client is the entity whose authorization is 186 checked. The client resides on the client system. 188 Router System: 189 The router is the node that provides network access 190 to the client. In addition to the usual packet 191 forwarding functionality, the router system typically 192 consists of other functional blocks like the attendant 193 and the packet filter. 195 Attendant: 196 The attendant is the entity that extracts 197 identification and authorization data sent by the 198 client and forwards them to AAAL for verification. 199 It is also responsible for making the necessary 200 configuration updates (e.g., to the packet filter, and 201 the router's Neighbor Cache) so that only authorized 202 clients can access the network. 204 Packet filter: 205 A packet filter/firewall/security gateway is the 206 entity responsible for disallowing unauthorized 207 datagram traffic. When a client is authorized, the 208 access control list of the filter is updated with the 209 corresponding client's IP address(es). 211 Controlled and uncontrolled access: 212 Each network interface of the router can be configured 213 to provide AAA services. When an interface is 214 so configured, all transiting packets are subject 215 to controlled access. If a packet does not pass 216 access control, but is an AAA message addressed to 217 the router, it is given to the Attendant in the 218 uncontrolled access part. 220 AAAL: 221 The AAA server in the foreign domain that mediates 222 local access to the AAA infrastructure. 224 AAAH: 225 The AAA server in the home domain which is able to 226 authorize each of its clients. 228 Other nodes: 229 Other clients that perform some function as a result 230 of the policy received from AAAH, e.g. accounting, 231 QoS, etc. 233 AAA credential: 234 Data provided by a client to the AAA server in an 235 authorization request. For example, this can be a 236 message authentication code constructed using a secret 237 shared between the client and AAAH. 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in [4]. 243 3. General Framework 245 Using the terminology just introduced, in this section we describe 246 the general framework for our proposals. 248 3.1. Protocol Description 250 The client solicits access to the network in conjunction with some 251 protocol. Protocols considered in this document include Stateless 252 Address Autoconfiguration [10] Mobile IPv6 [7], and DHCPv6 [3], as an 253 example of a stateful autoconfiguration service. 255 If the router has AAA service enabled, a packet received on the 256 interface is made available to the controlled part. The controlled 257 part will only forward traffic that corresponds to an authorized 258 client. All other packets will be dropped except for upstream AAA 259 authorization protocol packets (sent by the client to the router). 260 Such packets are made available to the attendant in the uncontrolled 261 part. The attendant may extract the relevant AAA data and forward 262 them to AAAL. The overall protocol is depicted below. 264 Router system 265 +.......................+ 266 Client . UCP CP . AAAL AAAH 267 | LC . | | . | | 268 |<--------------------| | . | | 269 |AAA Req: LC,RPI,ID,CR| | . | | 270 |-------------------->| | . | | 271 | . | ACR | . | | 272 | . |- - - - - - - - |- - - - - - - - >| ACR | 273 | . | | . |- - - >| 274 | . | | . | ACA | 275 | . | ACA | . |< - - -| 276 | . |<- - - - - - - -| -.- - - - - - - | | 277 | . | | . | | 278 | . |--------------->| . | | 279 | . | Update config | . | | 280 | . | | . | | 281 | . | | . | | 282 |AAA Rep: stat,RPI,KR | | . | | 283 |<--------------------| | . | | 284 | . | | . | | 285 +.......................+ 287 LC = Local AAA Challenge 288 RPI = Replay Protection Indicator used between client and AAAH 289 CR = AAA Credential 290 ID = Client Identifier 291 KR = Key Reply 292 UCP = Uncontrolled part 293 CP = Controlled part 294 ACR = AAA Client Request (using an AAA protocol) 295 ACA = AAA Client Answer (using an AAA protocol) 297 The figure describes the authorization protocol exchanges in the 298 generic case. The operation of this protocol is initiated by either 299 the attendant or the client. First, the attendant (uncontrolled part 300 in the router) sends a local challenge to the client. The client 301 then constructs an AAA credential which securely binds the local 302 challenge, the client identifier, any replay protection indicator 303 used between the client and AAAH, and other necessary information. 304 The credential is such that it can be verified by AAAH. The client 305 then sends an ``AAA Request'' message containing the credential 306 and the information necessary to verify it. The attendant checks 307 that the local challenge included in the AAA Request is valid, 308 extracts the AAA related information and sends them to AAAL using an 309 appropriate AAA protocol. We label this message, AAA Client Request 310 (ACR). AAAL forwards ACR to AAAH, which verifies the credential 311 and sends back the result, and any necessary keys. We label this 312 reply message AAA Client Answer (ACA). The AAAL forwards ACA to the 313 attendant. AAAL may also forward any necessary keys. The attendant 314 extracts the relevant data from ACA and forwards them to the client. 315 The attendant updates configuration of the packet filter (controlled 316 part in the router) so that traffic to and from the client is allowed 317 to pass through. 319 3.2. Client Identifier 321 The client identifier has to be in some format that will enable 322 AAAL to identify a suitable AAAH for carrying out all necessary 323 authorization steps. 325 A Network Access Identifier (NAI) [1] is often used to convey user 326 identity, but IPv6 networks may well be constructed to determine the 327 user's identity based only on the IPv6 address of the user's host. 328 Therefore, the client identifier MAY be a NAI or an IPv6 address. 329 The NAI MAY also identify the user to AAAL, although this is not 330 necessary (e.g., the user part of the NAI may be intelligible only to 331 AAAH). 333 3.3. Replay Protection 335 Each participant in the protocol SHOULD verify the freshness of the 336 protocol messages in order to protect itself from replay attacks. 337 Replay protection between AAAL and AAAH, and between AAAL and 338 attendant are handled by the AAA protocol. Therefore, we only need 339 to consider replay protection between the client and the other 340 entities. 342 The attendant ensures freshness of an AAA Request message from the 343 client by verifying that the local challenge included in the Request 344 is a recent one. 346 The client and AAAH may use either timestamps or random challenges 347 (nonces) for replay protection. The former is straightforward. 348 The latter is as follows. In the AAA Reply, AAAH sends an AAAH 349 challenge. When the client makes the next AAA Request, it includes 350 this AAAH challenge. It also includes its own client challenge. 351 When AAAH receives this request, it verifies that the AAAH challenge 352 is current. In the reply, AAAH copies the client challenge, and 353 includes a new AAAH challenge. This way, the client can verify the 354 freshness of the reply from AAAH. 356 If the AAAH challenge in an AAA Request is not valid, or if the 357 client sends an explicit request for an AAAH challenge, AAAH will 358 reply with a new AAAH challenge. This operation is similar to that 359 for nonces as specified for Mobile IP [9]. 361 3.4. AAA Credential 363 An AAA credential is created by the client and is verified by AAAH. 364 The creation and verification is based on a security association 365 shared between the client and AAAH. The credential SHOULD securely 366 bind the following pieces of information: 368 - Client identifier, 370 - Local AAA challenge, if one was provided by the attendant, and 372 - Depending on the style of replay protection being used between 373 the client and AAAH, either a timestamp or a pair of challenges. 375 In certain applications, additional data may be included in the 376 computation of the AAA Credential. 378 The exact algorithm used to compute the AAA Credential depends on 379 the security association between the client and AAAH. HMAC_MD5 is a 380 suitable algorithm, based on a shared secret between the client and 381 AAAH. 383 4. Instantiation with Stateless Address Autoconfiguration 385 In this section, we describe how the general protocol sketched in 386 Section 3 can be used with Stateless Address Autoconfiguration [10]. 388 4.1. Structure of Protocol Messages 390 We define new ICMPv6 messages to transport AAA data between the 391 client and the attendant. In addition, we defined several options 392 that can be embedded in a AAAv6 Protocol Message. Detailed 393 definitions of these messages are given in Section 9. Here we give a 394 brief description of each AAAv6 protocol message type, and each AAAv6 395 option. In addition, we also defined an AAAv6 Challenge option to 396 Router Advertisement, enabling the attendant to send a challenge to 397 the client. 399 4.1.1. AAAv6 Protocol Message types 401 From client to attendant: 403 AAA Request: Request for client authorization. 405 AAA Home Challenge Request: Request for a new challenge from AAAH. 407 From attendant to client: 409 AAA Reply: Reply to AAA Request. 411 AAA Teardown: Indication of termination of the currently active 412 AAA registration. This message is always sent unsolicited to 413 the registered AAA client. 415 4.1.2. AAA Protocol Message options 417 Each AAA Protocol Message specifies the AAA options that may 418 accompany it. Currently, the following options are defined. 420 Security Data: This option is intended to carry security data. 421 Currently, two subtypes are defined. 423 AAA Credential: Sent by the client; used by AAAH to verify 424 the authorization of the client. 426 AAAH Authenticator: Sent by AAAH; used by the client to 427 verify the authenticity of AAA Reply. 429 Client Identifier: This option should enable AAAL to determine the 430 AAAH to which an AAA Request is to be forwarded. Currently, 431 two subtypes are defined: NAI, and IPv6 address. 433 Generalized Key Reply: This option is used to distribute session 434 keys to be used by the client. Currently several subtypes 435 are defined for both stateless and stateful operation (see 436 sections 9.3.4, 10.6). 438 Challenge: This option is used to carry nonces used for replay 439 protection. Currently three subtypes are defined: 441 Local Challenge: Challenge issued by the attendant to the 442 client. 444 Home Challenge: Challenge issued by AAAH to the client. 446 Client Challenge: Challenge issued by the client to AAAH. 448 Timestamp: This option is used to carry timestamp information used 449 for replay protection. 451 IPv6 Address: This option is used to carry IP address information. 453 Lifetime: This option indicates the lifetime of an AAA 454 authorization. 456 5. Protocol Overview 458 5.1. Basic operation 460 The basic operation follows the model described in Section 3.1. When 461 an IPv6 client starts up or enter a new subnet, it receives a Router 462 Advertisement with a AAA Challenge option. As is usual, this Router 463 Advertisement is either broadcast periodically, or MAY be sent in 464 response to a Router Solicitation by the client. 466 The client will construct a tentative IP address and MAY reply with 467 an AAA Request ICMPv6 message with the following options: 469 - Local Challenge option into which the challenge from the Router 470 Advertisement is copied. 472 - Either Timestamp option or both AAAH Challenge and Client 473 Challenge options 475 - Client Identifier option consisting of the client's NAI or some 476 long term IPv6 address, such as the client's home address. 478 - AAA Credential option constructed by concatenating all of the 479 preceding options and applying the algorithm specified by the 480 security association between the client and AAAH. 482 When challenges are used for replay protection, the client MUST 483 include the currently advertised AAAH challenge (perhaps as received 484 from AAAH via a previous AAA Reply message) in the AAAH Challenge 485 option, and a random number in the Client Challenge option. If the 486 client does not have an AAAH challenge, it SHOULD send an AAA Home 487 Challenge Request message first (see Section 5.2). 489 The client MUST perform Duplicate Address Detection (DAD) before 490 sending the AAA Request. The source address of AAA Request MUST be 491 the chosen IPv6 address. 493 On receiving the Request, the attendant MUST check if the chosen 494 address is already in use. If it is, the attendant MUST send an AAA 495 Reply with code ADDRESS_IN_USE. 497 Otherwise, the attendant will extract the AAA field values and 498 forward them to AAAL in an ACR message using an AAA protocol, which 499 is then forwarded to AAAH. The data in each AAA option MUST be 500 conveyed to AAAH by the ACR message. In return, AAAH will construct 501 an ACA message containing information in a suitable form that can be 502 be extracted by the attendant and conveyed to the client in an AAA 503 Reply message with appropriate options. The following options are 504 discussed in this document: 506 - Either Timestamp option or both AAAH Challenge and Client 507 Challenge options 509 - One or more Key Reply options 511 - Lifetime option 513 - AAAH Authenticator option 515 For error conditions other than those specifically identified in 516 this document, the attendant or the AAA servers can cause the AAAv6 517 Request to be denied, by returning the code AAAV6_FAILURE in the AAA 518 Reply message. 520 We describe AAAH behavior in terms of what the client should 521 eventually receive in the AAA Reply. If the AAA Credential 522 is incorrect, the client MUST receive an AAA Reply with code 523 INVALID_CREDENTIAL. If challenges are used for replay protection, 524 and if the AAAH challenge is absent or invalid, the AAA Reply SHOULD 525 have a code NEW_CHALLENGE, and SHOULD contain an AAAH Challenge 526 option. If timestamps are used for replay protection, and the 527 Timestamp option is absent or invalid, the AAA Reply SHOULD have code 528 INVALID_TIMESTAMP. 530 AAAH SHOULD choose a validity period for the verification which 531 should be included in the Lifetime option of AAA Reply. If AAAL 532 proposes its own lifetime value (in the ACR message), then the 533 Lifetime option MUST contain the lower of the two values. If AAAH 534 chooses a key to be used between the attendant and the client, that 535 key SHOULD be encoded in a Client-Attendant Key Reply option. If 536 timestamps are used for replay protection, there MUST be a timestamp 537 option. If challenges are used for replay protection, AAAH MUST copy 538 the Client Challenge, and include a new random number in the AAAH 539 Challenge. Finally, AAAH should compute an authenticator, to be 540 included in an AAAH Authenticator option, by concatenating all the 541 preceding options intended for the client, and applying the algorithm 542 specified by the security association between the client and AAAH. In 543 addition, AAAH MAY include information in the ACA message intended 544 for AAAL. 546 If the status of the request is successful, AAAH will send back an 547 ACA message indicating success to AAAL. AAAL will forward this to 548 the attendant. If there are any keys distributed by AAAH, AAAL MUST 549 re-encode those keys for the attendant. 551 The attendant MUST add an entry for the client in its Neighbor Cache 552 and at the same time update the packet filter with the client's IPv6 553 address when the AAA verification for the client has been successful. 554 The lifetime of these entries MUST be set to the value specified in 555 the ACA message. The attendant will extract all information in the 556 ACA message intended for the client and send them back in an AAA 557 Reply ICMPv6 message. If, in the case of stateful address allocation 558 (e.g., DHCPv6 [3]; see section 7), the source address of the AAA 559 Request was the unspecified address, the corresponding AAA Reply MUST 560 be sent to the all-nodes multicast address. Otherwise the AAA Reply 561 MUST be sent to the source address of the corresponding AAA Request. 563 The attendant MUST create security associations for the client 564 corresponding to any keys distributed to it by AAAL. 566 When the client receives an AAA Reply indicating success, it 567 MUST verify the AAAH authenticator and the validity of the replay 568 protection indicator. If verification succeeds, and key reply 569 extensions have been included in the Reply, the client MUST create 570 security associations for the attendant. The client MUST associate 571 the lifetime specified in the Lifetime option with the address that 572 was authorized. When the lifetime is close to expiration, the client 573 SHOULD re-initiate the AAA process. 575 5.2. Challenge Request 577 If the client does not have a valid AAAH challenge, it SHOULD send an 578 AAA Home Challenge Request message. This SHOULD include the Client 579 Challenge option and MAY include the Client Identifier option. The 580 AAA Reply SHOULD have code NEW_CHALLENGE, and SHOULD include an AAAH 581 Authenticator option. 583 5.3. Initiation of the AAA Process 585 The AAA process can be initiated either from the client or from the 586 attendant. The attendant can initiate the process by sending a 587 Router Advertisement with the AAA Challenge option. The client can 588 initiate the process by sending a Router Solicitation. 590 5.4. Termination 592 It is also possible to terminate valid sessions. To terminate a 593 session, the attendant clears the packet filter and sends a AAA 594 Teardown message to the client which invalidates the IP address. A 595 typical scenario for termination would be in a pre-paid service when 596 the pre-paid amount is used up. The client may request termination 597 by sending an AAA Request message with a zero lifetime. 599 6. Instantiation with Mobile IPv6 601 There are two ways to handle Mobile IPv6. First, the client could 602 do the AAA processing when it obtains a care-of address, and then it 603 could send a binding update to the home agent, and possibly to the 604 previous router and other correspondents. 606 If the home agent and AAAH belong to the same domain, it may be more 607 efficient to bundle the binding update to the home agent in the AAA 608 Request message so that the delay is minimized. We support this 609 possibility by defining a new option called Embedded Data option. 610 The client generates an IPv6 packet containing the binding update to 611 the home agent, but instead of sending it directly, it includes it in 612 the AAA Request as the payload of an Embedded Data option. AAAH will 613 extract the binding update IPv6 packet and send it to the home agent. 614 The home agent SHOULD send the binding acknowledgement back to AAAH 615 so that it can be similarly transported to the client as part of the 616 AAA Reply. 618 In addition, we define new subtypes to the AAA Generalized Key Reply 619 option so that AAAH could distribute authentication keys for use 620 between the home agent and the mobile node. 622 7. Instantiation with DHCPv6 624 In this section we describe how the general protocol sketched in 625 Section 3 can be used with DHCPv6 [3]. 627 Between the client and the server there may also be a DHCP Relay 628 which together with the DHCP server MAY be used to restrict access. 629 The exact behavior of the relay is described in Section 7.4 631 7.1. Mapping the general protocol 633 The general protocol messages in Section 3 and the instantiation with 634 stateless autoconfiguration in Section 4 are mapped to DHCP in the 635 following fashion. 637 - The Local Challenge is sent as an option in the DHCP Advertise 638 message. 640 - The AAA Request and the Home Challenge Request are sent as 641 options in the DHCP Request message. 643 - The AAA Reply is sent as options in the DHCP Reply message. 645 - The AAA Teardown messages is not explicitly sent in any message. 646 Instead the DHCP Reconfigure-init and the DHCP Release messages 647 will be used. 649 In addition to these two new error values called AAA_Failed 650 indicating failure of the AAA registration attempt and 651 AAA_New_Home_Challenge indicating that a new challenge has 652 been sent to the DHCP client will be defined. 654 7.2. Mapping the message options 656 Most of the Protocol Message options in Section 4.1.2 are mapped to 657 DHCP options. The following list specifies which options are needed 658 for DHCP. 660 - Security Data: As described in Section 4.1.2. 662 - Client Identifier: This option contains the NAI used by the 663 client. The IPv6 address subtype, since that information is 664 already supplied by DHCPv6. 666 - Generalized Key Reply: As described in Section 4.1.2. 668 - Challenge: As described in Section 4.1.2. 670 - Timestamp: As described in Section 4.1.2. 672 - Lifetime: As described in Section 4.1.2. 674 The detailed option formats are described in Section 10. 676 DHCP DHCP 677 Client relay server AAAL AAAH 678 | | | | | 679 | DS | | | 680 |------------------|------->| | | 681 | DA: LC | | | 682 |<-----------------|--------| | | 683 | DReq: LC, RPI, CR, ID | | | 684 |------------------|------->| | | 685 | | | | 686 | | | ACR | | 687 | |- - - - - - - - - - >| ACR | 688 | | | |- - - >| 689 | | | ACA | 690 | | | ACA |< - - -| 691 | |<- - - - - - - - - - | | 692 | DRep, RPI, KR, L | | | | 693 |<--------------------------| | | 694 | | | | | 695 | | | | 696 | | | | | 698 DS = DHCP Solicit 699 DA = DHCP Advertise 700 DReq = DHCP Request 701 DRep = DHCP Reply 702 LC = Local AAA Challenge 703 RPI = Replay Protection Indicator used between client and AAAH 704 CR = AAA Credential 705 ID = Client Identifier 706 KR = Key Reply 707 L = Lifetime 708 ACR = AAA Client Request (using an AAA protocol) 709 ACA = AAA Client Answer (using an AAA protocol) 711 7.3. Protocol Overview 713 7.3.1. Basic operation 715 The basic operation follows the model outlined in Section 3. 717 When the DHCP client starts up in the subnet, it will send a DHCP 718 Solicit as described in the DHCPv6 draft [3]. The DHCP servers 719 receiving the DHCPV6 Solicit reply by sending DHCP Advertise messages 720 containing the Local Challenge option. Either all or none of the 721 DHCP servers MUST include a Local Challenge option in order to avoid 722 any ambiguities. 724 The DHCP client will construct a DHCP Request message with the 725 following options added before any authentication option: 727 - Local Challenge option into which the challenge in the DHCP 728 Advertise message is copied. 730 - Either Timestamp option or both Home Challenge and Client 731 Challenge options. 733 - Client Identifier option. 735 - AAA Credential option. 737 When challenges are used for replay protection, the DHCP client MUST 738 include its current home challenge in the Home Challenge option, and 739 a random number in the Client Challenge option. If the DHCP client 740 does not have an Home Challenge, it SHOULD request a Home Challenge 741 first as described in Section 8. 743 On receiving a valid DHCP Request the DHCP server will extract the 744 relevant data and forward them to the AAAL in the ACR message using 745 the AAA protocol. The ACR is then forwarded to the AAAH via the AAA 746 network. In addition to the options relating to AAA sent in the DHCP 747 Request message, the IPv6 address that will be assigned to the DHCP 748 client might be relevant to the AAAH. 750 In return, AAAH will construct an ACA message and send it to the 751 AAAL via the AAA infrastructure. The AAAL will then forward the ACA 752 message to the DHCP server. 754 If the ACA message indicates failure the value of the DHCP Reply will 755 be set to AAA_Failed and the DHCP server denies the DHCP address 756 acquisition. 758 If the ACA message indicates success it will contain information to 759 allow the following DHCP options to be attached to the DHCP Reply 760 message: 762 - Either Timestamp option or both Home Challenge and Client 763 Challenge options. 765 - One or more Key Reply options. 767 - Lifetime option. 769 - AAAH Authenticator option. 771 In addition to these options the DHCP server will attach those 772 options needed to satisfy the DHCP client's request. 774 7.3.2. Termination 776 The lease can be terminated either by the DHCP client or the DHCP 777 server. The DHCP client terminates the lease by sending a DHCP 778 Release message and waiting for a DHCP Reply. Alternatively, 779 the DHCP server MAY terminate the address lease by sending an 780 Reconfigure-init message by unicast to the DHCP client. The DHCP 781 client will try to reacquire its address lease which the DHCP server 782 then will deny. 784 7.4. Access Control 786 The access to the controlled part (CP) of the network can be carried 787 out in three different ways. 789 In a subnetwork using a DHCP Relay to forward messages between 790 the client and the server the access control MAY be located in 791 the DHCP Relay if the default router and the DHCP relay are also 792 co-located. The DHCP Relay MUST add an entry in its Neighbor Cache 793 when forwarding a DHCP Replay indicating successful allocation of an 794 address. In addition to adding an entry in the Neighbor Cache subnet 795 or site specific filtering rules MAY also be added. 797 In small sites where there is one DHCP server co-located in the 798 default router the DHCP server MUST add the entries in its neighbor 799 cache and MAY also add subnet or site specific filtering rules. 801 The filtering rules MAY also be added to suitable locations in the 802 accessed network by some other means, e.g. through AAA interaction. 804 8. Requesting a Home Challenge 806 If the AAAv6 client does not have a Home Challenge, it SHOULD request 807 one by sending a AAAv6 Home Challenge Request message. This request 808 message contains authentication data so that the AAAH can eventually 809 ensure that the request comes from an authorized client. The 810 attendant SHOULD relay this request to the AAAL in an extension to 811 a ACR message. The AAAL, if it does not have any challenge values 812 buffered for the AAAv6 client, SHOULD relay the ACR and the request 813 extension to the AAAH. 815 If the AAAH decides to honor the request, it formulates one or more 816 random challenges, each of which MAY be required to meet certain test 817 conditions agreed upon beforehand between the AAAv6 client and the 818 AAAH. The random challenges are gathered into an extension to an ACA 819 message which is sent to the AAAL. The AAAL then transmits (to the 820 attendant) an ACA containing no more than one of the Home Challenge 821 values in an ACA challenge reply extension. Finally, the attendant 822 transmits an AAAv6 Home Challenge Reply message to the AAAv6 client. 824 This additional mechanism is intended to enable use with EAP, which 825 requires a challenge value to be acted on by the EAP client. This 826 challenge value has to be generated by the AAAH, and is not available 827 to the client until requested. Thus, it is not possible with this 828 mechanism to handle all authentication signaling needs in a single 829 round trip. 831 However, depending on the security association between the AAAv6 832 client and the AAAH, the Home Challenge Request may be used to 833 acquire challenge values for security protocols other than EAP. 835 9. Message Formats for Stateless Address Autoconfiguration 837 9.1. AAA Challenge Option 839 The AAA challenge option is applied to Router Advertisements. If 840 the only purpose is to indicate support for AAAv6 in the router 841 advertisement, the option contains only the type and a length field 842 set to zero. 844 0 1 2 3 845 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 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Type = TBD | Length | Reserved | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Challenge ..... 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 Type The Type field identifies the option as being an AAA 853 challenge option and has a value of TBD. 855 Length The Length field gives the length measured in octets 856 of this option, including the Type and Length fields. 858 Reserved Ignored on reception; sent as 0. 860 Challenge This field contains a challenge. 862 9.2. AAA Protocol Messages 864 AAA Messages are new ICMPv6 messages. They have the following 865 general structure. 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Type = TBD | Code | Checksum | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Message body .......... 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 875 Type The following new types are defined: 877 AAA Request: TBD 879 AAA Home Challenge Request: TBD 881 AAA Reply: TBD 883 AAA Teardown: TBD 885 Code The code field depends on the message type. Currently the 886 following Code fields are defined: 888 For AAA Reply 890 SUCCESS: 0 892 NEW_CHALLENGE: 1 894 ADDRESS_IN_USE: 20 896 INVALID_CREDENTIAL: 50 898 INVALID_TIMESTAMP: 51 900 AAAV6_FAILURE: 52 902 For AAA Teardown 904 SUCCESS: 0 906 No Code values are defined for the remaining AAA message 907 types. The Code field MUST be set to zero. 909 Message body The message body may consist of one or more options. 911 9.3. AAA Protocol Message Options 913 The general structure of an AAA Protocol Message Option is as 914 follows. 916 0 1 2 3 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Type = TBD | Subtype | Length | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Option data ....... 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 Type The Type field identifies the option. Currently, 925 the following types are supported. The most 926 significant bit of the Type indicates if the option 927 is unskippable (0) or skippable (1). 929 Subtype Each option type may be further subdivided. The 930 Subtype field identifies option at the next level of 931 granularity. 933 Length The Length field indicates the size of the Option 934 data in octets. 936 Option data The format of option data is depends on the type and 937 subtype, and is defined below. 939 9.3.1. Client Identifier option 941 The Client Identifier option is used by AAAL to determine the 942 appropriate realm towards which to route the AAA request, and by AAAH 943 in verifying the AAA Credential. 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Type = TBD | Subtype | Length | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Identifier | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Type 1 (unskippable) 955 Subtype Currently two subtypes are defined: NAI (0) and IPv6 956 address (1) 958 Length For subtype 1, the Length should be 16. 960 Identifier For subtype 0, this field contains a NAI formatted 961 according to RFC2486 [1]. For subtype 1, this field 962 contains an IPv6 address. 964 9.3.2. Security Data 966 0 1 2 3 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Type = TBD | Subtype | Length | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | SPI | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Security Data ... 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 Type 2 (unskippable) 978 Subtype Currently two subtypes are defined: AAA 979 Credential (0) and AAAH Authenticator (1) 981 Length Length of the option in octets, not including the 982 first four octets. 984 SPI The security parameter index to be used in 985 interpreting the Security Data. 987 Security Data The actual payload. 989 9.3.3. Challenge 991 The Challenge option is used to convey nonces for replay protection 992 between various pairs of entities. 994 0 1 2 3 995 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 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Type = TBD | Subtype | Length | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Challenge ....... 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 Type 3 (unskippable) 1004 Subtype Currently three subtypes are defined: 1006 - Local Challenge: Challenge issued by the 1007 attendant to the client (0) 1009 - Home Challenge: Challenge issued by AAAH to the 1010 client (1) 1012 - Client Challenge: Challenge issued by the client 1013 to AAAH (2) 1015 Length Length of the challenge in octets. 1017 Challenge The actual challenge data. 1019 9.3.4. Generalized Key Reply 1021 This option is used to convey keys distributed by AAAH for use 1022 between the client and other entities. 1024 0 1 2 3 1025 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 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Type = TBD | Subtype | Length | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | AAAH SPI | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Key SPI | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | | 1034 | Peer IPv6 Address | 1035 | | 1036 | | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Encoded Key Data ......... 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 Type 4 (unskippable) 1043 Subtype Currently subtypes are defined for three 1044 entity pairs: 1046 - Client-Attendant authentication key: Key 1047 to be used between the current attendant 1048 and the client for IPSec authentication 1049 (1) 1051 - Client-Attendant encryption key: Key to 1052 be used between the current attendant and 1053 the client for IPsec encryption (2) 1055 - MN-HA authentication key: Key to be used 1056 between the home agent and the client for 1057 IPsec authentication (4) 1059 If the most significant bit of the Subtype 1060 value is 1, the ``Peer IPv6 Address'' field is 1061 present. Otherwise, it is absent. 1063 Length Length of the option in octets except the 1064 first four octets. 1066 AAAH SPI This field indicates the security association 1067 between the client and AAAH which should be 1068 used by the client to interpret the Encoded 1069 Key Data field. 1071 Key SPI This field indicates the SPI value for the new 1072 security association into which the key should 1073 be inserted. 1075 Peer IPv6 Address When present, this field indicates the IPv6 1076 address of the peer. This is useful when the 1077 client does not already know the address to be 1078 used. This field is present in subtypes 128 1079 and above. 1081 Encoded Key Data This field contains the key, along with any 1082 other information required by the client to 1083 create the security association. The contents 1084 of the field MUST be encrypted by AAAH as 1085 specified by AAAH SPI. 1087 9.3.5. Timestamp 1089 Timestamp field may be used for replay protection between the client 1090 and AAAH. 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Type = TBD | Subtype | Length | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Timestamp ... 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 Type 5 (unskippable) 1102 Subtype Currently no subtypes are defined. Should be zero. 1104 Length Length of the Timestamp in octets. 1106 Timestamp Timestamp value in some format mutually intelligible 1107 to the client and AAAH 1109 9.3.6. IPv6 Address 1111 This option is used by the client to convey the IPv6 address it has 1112 chosen. There may be other uses for this option, too. 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Type = TBD | Subtype | Length | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | | 1120 | IPv6 Address | 1121 | | 1122 | | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 Type 6 (unskippable) 1127 Subtype Currently no subtypes are defined. Should be zero. 1129 Length 16 1131 IPv6 Address A valid IPv6 address. 1133 9.3.7. Lifetime 1135 This option is used to indicate the validity period of a successful 1136 AAA verification. 1138 0 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Type = TBD | Subtype | Length | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | Lifetime | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 Type 7 (unskippable) 1148 Subtype Currently no subtypes are defined. Should be zero. 1150 Length 4 1152 Lifetime Lifetime in seconds. 1154 9.3.8. Embedded Data 1156 This option is used to transport specific kinds of embedded data in 1157 the AAA messages. 1159 0 1 2 3 1160 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 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Type = TBD |WHO| Subtype | Length | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Embedded Data ........ 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 Type 8 (unskippable) 1169 WHO This field indicates who should process the embedded data. 1170 It is interpreted as follows (values in binary) 1172 00 - Recipient of the AAA Protocol message (i.e., either 1173 the client or the attendant) 1174 01 - AAAL 1175 10 - AAAH 1176 11 - reserved 1178 Subtype Currently two subtypes are defined: 1179 (0) -- MN-HA binding update 1180 (1) -- HA-MN binding acknowledgement 1181 (2) -- EAP Request [2] 1182 (3) -- EAP Response [2] 1184 Data The actual embedded data itself. For subtype 0, this MUST 1185 be an IPv6 packet addressed to the HA, and containing 1186 a binding update. For subtype 1, this MUST be an IPv6 1187 packet addressed to the CoA, and containing a binding 1188 acknowledgement from the HA. 1190 For example, to bundle the HA binding update with AAA processing, 1191 the client will first generate a binding update, and insert it into 1192 an embedded data option of the AAA Request message, with WH = 10 1193 (binary) and Subtype = 0. Based on the value of WH, the attendant 1194 will extract the Embedded Data and forward it to AAAH via AAAL. Based 1195 on the Subtype, AAAH will forward the binding update to the home 1196 agent, and will receive a binding acknowledgement in reply. The 1197 attendant will forward the binding acknowledgement in an Embedded 1198 Data option to the AAA Reply message, with WH - 00 (binary) and 1199 Subtype = 1. 1201 10. Message Formats for Stateful Address Autoconfiguration with DHCPv6 1203 10.1. Challenge option 1205 0 1 2 3 1206 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 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | Type = TBD | Length | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Subtype | reserved | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Challenge... 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 Type The Type field identifies the option as a Local 1216 Challenge option. 1218 Length The Length of the option in octets not 1219 including the Type and Length fields. 1221 Subtype The Subtype field identifies the type of the 1222 challenge. Currently defined subtypes are: 1224 - Local Challenge: Challenge issued by the 1225 DHCP server to the client, 0 1227 - Home Challenge: Challenge issued by AAAH 1228 to the client, 1 1230 - Client Challenge: Challenge issued by the 1231 client to AAAH, 2 1233 reserved 0, used for aligning the Challenge field. 1235 Challenge The actual challenge data. 1237 10.2. Client NAI option 1239 0 1 2 3 1240 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 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | Type = TBD | Length | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Client Network Access Identifer (NAI) ... 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 Type The Type field identifies the option as a 1248 Client Identifier option. 1250 Length The Length of the option in octets not 1251 including the Type and Length fields. 1253 Client NAI The client NAI formatted according to 1254 RFC2486 [1] 1256 10.3. Timestamp option 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Type = TBD | Length | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Timestamp ... 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 Type The Type field identifies the option as a 1267 Timestamp option. 1269 Length The Length of the option in octets not 1270 including the Type and Length fields. 1272 Timestamp Timestamp value in some format mutually 1273 intelligible to the client and AAAH. 1275 10.4. Lifetime option 1277 0 1 2 3 1278 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 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Type = TBD | Length | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | Lifetime | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 Type The Type field identifies the option as a 1286 Timestamp option. 1288 Length 4 1290 Lifetime Lifetime in seconds indicating the validity 1291 period of a successful AAA verification. 1293 10.5. Security Data option 1295 0 1 2 3 1296 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 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | Type = TBD | Length | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | Subtype | reserved | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | SPI | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Security Data... 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 Type The Type field identifies the option as a 1308 Timestamp option. 1310 Length The Length of the option in octets not 1311 including the Type and Length fields. 1313 Subtype Currently two subtypes are defined: AAA 1314 Credential (0) and AAAH Authenticator (1). 1316 reserved 0, used for aligning the Challenge field. 1318 Security Data The actual payload. 1320 10.6. Generalized Key Reply option 1322 0 1 2 3 1323 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 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Type = TBD | Length | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | Subtype | reserved | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | AAAH SPI | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Key SPI | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Encoded Key... 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 Type The Type field identifies the option as a Timestamp 1337 option. 1339 Length The Length of the option in octets not including 1340 The Type and Length fields. 1342 Subtype Currently three pairs of subtypes are defined: 1344 Client-Attendant authentication key: Key to be used 1345 between the current attendant and the client for 1346 IPSec authentication (1) 1348 Client-Attendant encryption key: Key to be used 1349 between the current attendant and the client for 1350 IPsec encryption (2) 1352 MN-HA authentication key: Key to be used between 1353 The home agent and the client for Ipsec 1354 authentication (4) 1356 reserved 0, used for aligning the next field. 1358 AAAH SPI This field indicates the security association 1359 between the client and AAAH which should be used by 1360 the client to interpret the Encoded Key Data field. 1362 Key SPI This field indicates the SPI value for the new 1363 security association into which the key should be 1364 inserted. 1366 Encoded Key This field contains the key, along with any other 1367 information required by the client to create the 1368 security association. The contents of the field 1369 MUST be encrypted by AAAH as specified by AAAH SPI. 1371 11. Security Considerations 1373 Source address based packet filtering does not guarantee that only 1374 authorized clients will be able to send out traffic through the 1375 router. An attacker can fake the source address of IP packets. In 1376 situations where strong protection is needed, clients should be 1377 required to use an IPSec AH tunnel to the router. 1379 12. Open Issues and Discussion 1381 12.1. Packet Service Filter 1383 Future work may be needed to determine how services can be 1384 updated dynamically based on the authorized services. A typical 1385 service filter will permit/deny a filter rule based on upper layer 1386 information for the authenticated IP address. 1388 The attendant could prepare an ACL with service filters based on the 1389 AAA response for the authenticated services for the different UDP/TCP 1390 ports. 1392 12.2. Use of Destination Options 1394 An alternative to defining new ICMPv6 messages and associated options 1395 will be to define new IPv6 destination options for all AAA related 1396 payload. One disadvantage is that the length of destination options 1397 is limited by the 8-bit length field. An advantage is that embedded 1398 data may be transported more naturally using either a Routing Header 1399 or IP-in-IP encapsulation, thereby avoiding the need for something 1400 like the Embedded Data option. 1402 12.3. AAAL 1404 If QoS or other traffic parameters affecting the whole site are 1405 received from the AAAH, the AAAL SHOULD have some means to enforce 1406 these. In this case the AAAL SHOULD also enforce some form of 1407 filtering separate from the DHCP infrastructure. 1409 12.4. Other 1411 How are the AAA Credentials computed? 1413 Do we need the padding in the DHCPv6 options? 1415 Contributors 1417 Patrik Flykt (Nokia) 1419 References 1421 [1] B. Aboba and M. Beadles. The Network Access Identifier. 1422 Request for Comments (Proposed Standard) 2486, Internet 1423 Engineering Task Force, January 1999. 1425 [2] L. Blunk and J. Vollbrecht. PPP Extensible Authentication 1426 Protocol (EAP). Request for Comments (Proposed Standard) 2284, 1427 Internet Engineering Task Force, March 1998. 1429 [3] J. Bound, C. Perkins, M. Carney, and R. Droms. Dynamic Host 1430 Configuration Protocol for IPv6 (DHCPv6) (work in progress). 1431 Internet Draft, Internet Engineering Task Force, January 2001. 1433 [4] S. Bradner. Key words for use in RFCs to Indicate Requirement 1434 Levels. Request for Comments (Best Current Practice) 2119, 1435 Internet Engineering Task Force, March 1997. 1437 [5] B. Aboba et al. Criteria for Evaluating AAA Protocols for 1438 Network Access. Request for Comments (Proposed Standard) 2989, 1439 Internet Engineering Task Force, November 2000. 1441 [6] S. Glass, T. Hiller, S. Jacobs, and C. Perkins. Mobile IP 1442 Authentication, Authorization, and Accounting Requirements. 1443 Request for Comments (Proposed Standard) 2977, Internet 1444 Engineering Task Force, October 2000. 1446 [7] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in 1447 progress). 1448 draft-ietf-mobileip-ipv6-15.txt, October 2001. 1450 [8] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 1451 IP Version 6 (IPv6). Request for Comments (Draft Standard) 1452 2461, Internet Engineering Task Force, December 1998. 1454 [9] C. Perkins. IP Mobility Support. Request for Comments 1455 (Proposed Standard) 3220, Internet Engineering Task Force, 1456 December 2001. 1458 [10] S. Thomson and T. Narten. IPv6 Stateless Address 1459 Autoconfiguration. Request for Comments (Draft Standard) 2462, 1460 Internet Engineering Task Force, December 1998. 1462 Addresses 1464 Questions about this memo can be directed to the authors: 1466 Ernie Tacsik Thomas Eklund 1467 Nokia Inc. Xelerated Networks 1468 6000 Connection Drive 3:1000 Regeringsgatan 67 1469 Irving, Texas 75039 1470 USA 103 86 Stockholm 1471 Sweden 1472 Phone: +1 972 894 4044 Phone: +46 8 50625753 1473 E-mail: ernie.tacsik@nokia.com E-mail: thomas.eklund@xelerated.com 1474 Fax: +1 972 894 5525 Fax: +46 8 54553211 1476 Charles E. Perkins 1477 Communications Systems Lab 1478 Nokia Research Center 1479 313 Fairchild Drive 1480 Mountain View, California 94043 1481 USA 1482 Phone: +1-650 625-2986 1483 EMail: charliep@iprg.nokia.com 1484 Fax: +1 650 625-2502