idnits 2.17.00 (12 Aug 2021) /tmp/idnits11588/draft-irtf-aaaarch-handoff-04.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 646 has weird spacing: '...t realm are t...' == Line 787 has weird spacing: '...e might not b...' == Line 1049 has weird spacing: '...imed to perta...' == Line 1093 has weird spacing: '...>, and expir...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Where RADIUS is run over IPsec ESP with a non-null transform, the secret shared between the NAS and the RADIUS server MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed. However, a RADIUS server that cannot know whether incoming traffic is IPsec-protected MUST be configured with a non-null RADIUS shared secret. -- 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 (26 October 2003) is 6775 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Note 1' is mentioned on line 489, but not defined == Missing Reference: 'Note 2' is mentioned on line 493, but not defined == Missing Reference: 'Note 5' is mentioned on line 514, but not defined == Missing Reference: 'Note 10' is mentioned on line 536, but not defined -- Looks like a reference, but probably isn't: '11' on line 463 == Missing Reference: 'Note 12' is mentioned on line 557, but not defined == Missing Reference: 'Note 3' is mentioned on line 496, but not defined == Missing Reference: 'Note 4' is mentioned on line 505, but not defined == Missing Reference: 'Note 7' is mentioned on line 523, but not defined == Missing Reference: 'Note 6' is mentioned on line 518, but not defined == Missing Reference: 'Note 9' is mentioned on line 532, but not defined == Missing Reference: 'Note 8' is mentioned on line 528, but not defined == Missing Reference: 'Note 11' is mentioned on line 546, but not defined == Missing Reference: 'RFC2486' is mentioned on line 644, but not defined ** Obsolete undefined reference: RFC 2486 (Obsoleted by RFC 4282) == Missing Reference: 'RFC2401' is mentioned on line 697, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'RFC2409' is mentioned on line 791, but not defined ** Obsolete undefined reference: RFC 2409 (Obsoleted by RFC 4306) == Missing Reference: 'RFC2406' is mentioned on line 698, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'NTPAUTH' is mentioned on line 832, but not defined == Unused Reference: 'RFC1305' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 915, but no explicit reference was found in the text == Unused Reference: 'RFC2607' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'RFC3162' is defined on line 928, but no explicit reference was found in the text == Unused Reference: 'RFC3579' is defined on line 931, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'IEEE8021Q' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'IEEE8021X' is defined on line 948, but no explicit reference was found in the text == Unused Reference: 'IEEE8023' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'NTPAuth' is defined on line 1014, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Unexpected draft version: The latest known version of draft-aboba-802-context is -02, but you're referring to -03. == Outdated reference: draft-ietf-eap-rfc2284bis has been published as RFC 3748 == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 == Outdated reference: draft-ietf-aaa-diameter-nasreq has been published as RFC 4005 -- Unexpected draft version: The latest known version of draft-ietf-stime-ntpauth is -04, but you're referring to -05. Summary: 11 errors (**), 0 flaws (~~), 39 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group William A. Arbaugh 2 INTERNET-DRAFT University of Maryland 3 CATEGORY: Informational Bernard Aboba 4 Microsoft Corporation 5 26 October 2003 7 Handoff Extension to RADIUS 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of Section 10 of RFC 2026. 12 Internet-Drafts are working documents of the Internet Engineering Task 13 Force (IETF), its areas, and its working groups. Note that other groups 14 may also distribute working documents as Internet- Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Copyright Notice 29 Copyright (C) The Internet Society (2003). All Rights Reserved. 31 Abstract 33 In order to decrease handoff latency, this specification describes an 34 extension to the RADIUS protocol that enables an accounting server to 35 notify a NAS of a prospective handoff. This enables the NAS to reserve 36 resources and obtain the session parameters prior to arrival of the 37 client, potentially reducing handoff times. The extension described in 38 this document is useful across a range of access technologies and is 39 capable of enabling handoffs between providers. Recent implementation 40 experience in 802.11 networks indicates that this extension is capable 41 of reducing handoff times to levels suitable for use with Voice over IP 42 (VOIP), even in cases where clients are travelling at vehicular 43 velocities. 45 Table of Contents 47 1. Introduction .......................................... 3 48 1.1 Terminology ..................................... 5 49 1.2 Requirements language ........................... 6 50 2. Packet format ......................................... 6 51 2.1 Notify-Request .................................. 8 52 2.2 Notify-Accept ................................... 9 53 2.3 Notify-Reject ................................... 10 54 3. Table of Attributes ................................... 10 55 4. Security considerations ............................... 13 56 4.1 Authorize-Only messages ......................... 13 57 4.2 State removal ................................... 14 58 4.3 Authorization issues ............................ 14 59 4.4 Impersonation ................................... 15 60 4.5 IPsec usage guidelines .......................... 15 61 4.6 Replay protection ............................... 18 62 4.7 Spoofing and hijacking .......................... 19 63 5. IANA considerations ................................... 19 64 6. References ............................................ 19 65 6.1 Normative references ............................ 19 66 6.2 Informative references .......................... 20 67 ACKNOWLEDGMENTS .............................................. 22 68 AUTHORS' ADDRESSES ........................................... 23 69 Intellectual Property Statement .............................. 23 70 Full Copyright Statement ..................................... 24 71 1. Introduction 73 In wireless networks such as IEEE 802.11, described in [IEEE80211], it 74 may be desirable to improve the speed at which handoff can be completed. 75 Where RADIUS Accounting [RFC2866] is implemented, RADIUS Accounting 76 packets will be generated each time the client connects to a NAS. 77 Accounting packets from a single session, across multiple NASes, are 78 uniquely identified by the Acct-Multi-Session-Id Attribute, described in 79 [RFC2866] and [RFC3580]. 81 The sequence of NASes contacted by clients as they move creates a graph 82 representing the mobility paths of the clients. We call this graph a 83 neighbor graph with NASes as the vertices and the mobility paths between 84 the NASes as the edges. Thus, the number of neighbors for a given NAS 85 is given by the degree function applied to the vertex representing the 86 given NAS, e.g. for NAS_A the number of neighbors would be given by 87 deg(v_A) where deg is the degree function deg: V -> int. Through 88 knowledge of the neighbor graph, it is possible for a RADIUS server to 89 anticipate client movements and provide advance notice of a potential 90 handoff to the NAS. This advance notice, known as a Notify-Request in 91 this specification, allows the NAS to reserve resources and obtain the 92 session authorization parameters prior to arrival of the client. This 93 removes the latency of the RADIUS exchange from the critical path for 94 processing a handoff, decreasing handoff latency substantially, as 95 described in [IEEE-02-758, IEEE-03-084]. Assuming that the coverage 96 area is overlapping, this technique can support handoffs at vehicular 97 velocities. The creation and maintenance of neighbor graphs at an 98 authentication server is described in [IEEE-03-084]. An alternate 99 approach to using neighbor graphs uses a matrix of probabilities and is 100 described in [8021XHandoff]. 102 By nature, client behavior is not completely predictable, so that the 103 handoff advance notice is only advisory. The client identified in the 104 advance notice may never contact the NAS, or may contact it long after 105 the initial notice is received. As a result, the NAS will typically 106 free reserved resources after a suitable waiting period, known as the 107 Reservation-Lifetime. In situations where resources are at a premium, 108 it may be desirable to minimize resources reserved for clients that are 109 no longer likely to attempt to connect to a given NAS. To accomplish 110 this, the reservation period can be shortened, or alternatively, the 111 RADIUS server can remove resource reservations using the Disconnect- 112 Request, specified in [RFC3576]. A client contacting the NAS after the 113 Reservation-Lifetime has expired or a resource reservation has been 114 removed will be unable to complete a handoff, and will need to do a fast 115 resume, such as is supported in EAP TLS [RFC2716]. 117 The extension described in this document enables a RADIUS Server to send 118 Notify-Requests to NASes, and to receive Notify-Responses. The Notify- 119 Request identifies the session to be handed off and the NAS on which it 120 currently resides. Attributes included within the Notify-Request are 121 described in Section 2.1. 123 If the NAS has resources available to reserve, and if it is enabled to 124 support this handoff extension, then it will respond with a Notify- 125 Accept. If resources are not available (such as when previous resource 126 commitments leave insufficient resources remaining), or if the NAS does 127 not wish to support the prospective handoff for any other reason, the 128 NAS will respond with a Notify-Reject, specifying the reason why the 129 requested handoff reservation could not be carried out, using the Error- 130 Cause Attribute, specified in [RFC3576]. 132 After the NAS responds with a Notify-Accept, it will typically issue an 133 Access-Request to the RADIUS server. This allows the NAS to obtain the 134 authorizations for the session before it is contacted by the client. 135 The contents of the Access-Request sent by the NAS will depend on the 136 form of access it is providing, so that it cannot be specified in detail 137 here. However, for use with IEEE 802.11, it is expected that an Access- 138 Request will be sent with a NAS-Port-Type Attribute with value "802.11" 139 and a Service-Type Attribute with value "Authorize Only", as defined in 140 [RFC3576]. For other access methods, a different NAS-Port-Type value 141 might be sent, perhaps with a different value for Service-Type. 143 Since the extension defined in this document supports multiple access 144 methods and service types, and leverages the conventional RADIUS Access- 145 Request/Response exchange, it can be used to enable handoffs between any 146 acess technology compatible with RADIUS. For example, using this 147 extension, it is possible to enable a handoff between 802.11 and 148 cellular technologies such as GPRS or CDMA 1X-RTT. When this extension 149 is used to enable handoff between heterogeneous technologies, the 150 "correctness" issues described in [Context] do not arise, since the 151 RADIUS server provides the authorizations appropriate for each NAS and 152 access mechanism. 154 This extension can also enable handoffs between providers that do not 155 establish mutual trust, as would be required when using a context 156 transfer approach, such as [IEEE80211f]. All that is necessary is that 157 each NAS be able to reach the home RADIUS server through an appropriate 158 path. Of course, where handoffs occur across different providers and 159 access media, it is unlikely that session continuity can be preserved, 160 since the client will be likely to change its IP address. 162 In response to receiving a Notify-Request, a NAS that does not support 163 these Extensions will typically respond with an ICMP Port Unreachable 164 message. Since this extension utilizes the same UDP port (3799) as the 165 Dynamic Authorization Extensions to RADIUS described in [RFC3576], it is 166 possible that a Notify-Request may be sent to a NAS that while listening 167 on the port, does not support the extensions specified in this document. 168 In this case, the NAS will silently discard the Notify-Request. In 169 order to confirm that the NAS is listening on port 3799 but does not 170 support the Handoff Extensions, the RADIUS server may send one or more 171 test dynamic authorization message as described in [RFC3576], in order 172 to determine the NAS capabilities. 174 1.1. Terminology 176 This document uses the following terms: 178 Authenticator 179 An Authenticator is an entity that require authentication from 180 the Supplicant. The Authenticator may be connected to the 181 Supplicant at the other end of a point-to-point LAN segment or 182 802.11 wireless link. 184 authentication server 185 An authentication server is an entity that provides an 186 Authentication Service to an Authenticator. This service 187 verifies from the credentials provided by the Supplicant, the 188 claim of identity made by the Supplicant. 190 Network Access Server (NAS) 191 The device providing access to the network. 193 Service The NAS provides a service to the user, such as IEEE 802 or 194 PPP. 196 Port Access Entity (PAE) 197 The protocol entity associated with a physical or virtual 198 (802.11) Port. A given PAE may support the protocol 199 functionality associated with the Authenticator, Supplicant or 200 both. 202 Session Each service provided by the NAS to a user constitutes a 203 session, with the beginning of the session defined as the 204 point where service is first provided and the end of the 205 session defined as the point where service is ended. A user 206 may have multiple sessions in parallel or series if the NAS 207 supports that, with each session generating a separate start 208 and stop accounting record. Where the client is mobile and is 209 able to handoff between NASes, multiple related sessions may 210 be uniquely identified by the Acct-Multi-Session-Id Attribute. 212 Supplicant 213 A Supplicant is an entity that is being authenticated by an 214 Authenticator. The Supplicant may be connected to the 215 Authenticator at one end of a point-to-point LAN segment or 216 802.11 wireless link. 218 1.2. Requirements language 220 In this document, several words are used to signify the requirements of 221 the specification. These words are often capitalized. The key words 222 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 223 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 224 interpreted as described in [RFC2119]. 226 2. Packet format 228 Exactly one Notify-Request, Notify-Accept or Notify-Reject packet is 229 encapsulated in the UDP Data field. For the Notify-Request packet, the 230 UDP Destination Port is 3799. When a reply is generated, the source and 231 destination ports are reversed. 233 A summary of the data format is shown below. The fields are transmitted 234 from left to right. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Code | Identifier | Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 | Authenticator | 243 | | 244 | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Attributes ... 247 +-+-+-+-+-+-+-+-+-+-+-+-+- 249 Code 251 The Code field is one octet, and identifies the type of RADIUS 252 packet. When a packet is received with an unsupported Code field, it 253 is silently discarded. RADIUS codes (decimal) for this extension are 254 assigned as follows: 256 TBD - Notify-Request 257 TBD - Notify-Accept 258 TBD - Notify-Reject 260 Identifier 262 The Identifier field is one octet, and aids in matching requests and 263 replies. The RADIUS server can detect a duplicate request if it has 264 the same client source IP address and source UDP port and Identifier 265 within a short span of time. 267 Length 269 The Length field is two octets. It indicates the length of the 270 packet including the Code, Identifier, Length, Authenticator and 271 Attribute fields. Octets outside the range of the Length field MUST 272 be treated as padding and ignored on reception. If the packet is 273 shorter than the Length field indicates, it MUST be silently 274 discarded. The minimum length is 20 and maximum length is 4096. 276 Authenticator 278 The Authenticator field is sixteen (16) octets. The most significant 279 octet is transmitted first. This value is used to authenticate the 280 messages between the client and RADIUS server. 282 Request Authenticator 284 In Notify-Request Packets, the Authenticator value is a 16 octet MD5 285 [RFC1321] checksum, called the Request Authenticator. The Request 286 Authenticator is calculated the same way as for an Accounting- 287 Request, specified in [RFC2866]. 289 Note that the Request Authenticator of an Notify-Request can not be 290 done the same way as the Request Authenticator of a RADIUS Access- 291 Request, because there is no User-Password Attribute in an Notify- 292 Request. 294 Response Authenticator 296 The Authenticator field in a Notify-Accept or Notify-Reject packet is 297 called the Response Authenticator, and contains a one-way MD5 hash 298 calculated over a stream of octets consisting of the Notify-Response 299 Code, Identifier, Length, the Request Authenticator field from the 300 Notify-Request packet being replied to, and the response Attributes 301 if any, followed by the shared secret. The resulting 16 octet MD5 302 hash value is stored in the Authenticator field of the Notify-Accept 303 or Notify-Reject packet. 305 Attributes 307 In Notify-Request messages, all Attributes are treated as mandatory. 308 A NAS supporting this extension MUST respond to a Notify-Request 309 containing one or more unsupported Attributes with a Notify-Reject. 310 A Notify-Reject MUST NOT result in resources being reserved on the 311 NAS. Attributes beyond those specified in Section 3 SHOULD NOT be 312 included within Notify-Request messages, since this could produce 313 unpredictable results. 315 When using a forwarding proxy, the proxy must be able to alter the 316 packet as it passes through in each direction. When the proxy 317 forwards a Notify-Request, it MAY add a Proxy-State Attribute, and 318 when the proxy forwards a response, it MUST remove its Proxy-State 319 Attribute if it added one. Proxy-State is always added or removed 320 after any other Proxy-States, but no other assumptions regarding its 321 location within the list of Attributes can be made. Since Notify 322 responses are authenticated on the entire packet contents, the 323 stripping of the Proxy-State Attribute invalidates the integrity 324 check - so the proxy needs to recompute it. A forwarding proxy MUST 325 NOT modify existing Proxy-State, State, or Class Attributes present 326 in the packet. 328 If there are any Proxy-State Attributes in a Notify-Request received 329 from the server, the forwarding proxy MUST include those Proxy-State 330 Attributes in its response to the server. The forwarding proxy MAY 331 include the Proxy-State Attributes in the Notify-Request when it 332 forwards the request, or it MAY omit them in the forwarded request. 333 If the forwarding proxy omits the Proxy-State Attributes in the 334 request, it MUST attach them to the response before sending it to the 335 server. 337 2.1. Notify-Request 339 Description 341 A Notify-Request packet is sent by the RADIUS server to the NAS to 342 notify it of the potential handoff of a specified session. 344 Code 346 TBD - Notify-Request 348 Identifier 350 The Identifier field MUST be changed whenever the content of the 351 Attributes field changes, and whenever a valid reply has been 352 received for a previous request. For retransmissions where the 353 contents are identical, the Identifier MUST remain unchanged. 355 Note that if the Event-Timestamp Attribute is included the Notify- 356 Request then the Event-Timestamp value will be updated when the 357 packet is retransmitted, changing the content of the Attributes field 358 and requiring a new Identifier and Request Authenticator. 360 Request Authenticator 362 The Request Authenticator of an Accounting-Request contains a 363 16-octet MD5 hash value calculated according to the method described 364 in "Request Authenticator" in Section 2. 366 Attributes 368 The Attribute field is variable in length, and contains a list of 369 Attributes. In Notify-Request packets, certain Attributes are used 370 to uniquely identify the NAS as well as a potential user session on 371 the NAS, and to describe the services to be provided. All NAS 372 identification Attributes included in a Notify-Request message MUST 373 match in order for a Notify-Accept to be sent; otherwise a Notify- 374 Reject MUST be sent. 375 To address security concerns described in Section 4.1, the User-Name 376 Attributes MUST be present in Notify-Request packets. To address 377 security concerns described in Section 4.2, the NAS-IP-Address and/or 378 NAS-IPv6-Address Attributes SHOULD be present in Notify-Request 379 packets; the NAS-Identifier Attribute MAY be present in addition. 380 Details of the Attributes which may be included in Notify-Request 381 packets are provided in Section 3. 383 2.2. Notify-Accept 385 Description 387 The NAS responds to the Notify-Request with a Notify-Accept if the 388 NAS agrees to to prepare for a handoff of the specified session. 390 Code 392 TBD - Notify-Accept 394 Identifier 396 The Identifier field is a copy of the Identifier field of the Notify- 397 Request which caused this Notify-Accept. 399 Response Authenticator 401 The Response Authenticator of a Notify-Accept contains a 16-octet MD5 402 hash value calculated according to the method described in "Response 403 Authenticator" in Section 2. 405 Attributes 407 The Attribute field is variable in length, and contains a list of 408 Attributes. Within the Notify-Accept, Attributes are used to provide 409 the RADIUS server with the session identifiers that will be used by 410 the NAS in subsequent Access-Request and Accounting-Request packets. 411 This includes session identification Attributes, such as the User- 412 Name and Acct-Multi-Session-Id Attributes provided by the RADIUS 413 server in the Notify-Request, as well as an Acct-Session-Id allocated 414 by the NAS for the handoff, should it occur. The Idle-Timeout 415 Attribute, when included in the Notify-Accept, provides the RADIUS 416 server with the time that the NAS is willing to reserve resources for 417 the handoff. Section 3 provides more detail on the Attributes 418 permitted within the Notify-Accept packet. 420 2.3. Notify-Reject 422 Description 424 The NAS responds to the Notify-Request with a Notify-Reject if the 425 NAS does not have the resources to make the required handoff 426 preparations, or wishes to decline for any other reason. 428 Code 430 TBD - Notify-Reject 432 Identifier 434 The Identifier field is a copy of the Identifier field of the Notify- 435 Request which caused this Notify-Reject. 437 Response Authenticator 439 The Response Authenticator of a Notify-Accept contains a 16-octet MD5 440 hash value calculated according to the method described in "Response 441 Authenticator" in Section 2. 443 Attributes 445 The Attribute field is variable in length, and contains a list of 446 Attributes. Within the Notify-Reject, the Error-Cause Attribute 447 provides the RADIUS server with the reason why the Notify-Request 448 could not be honored. Values of the Error-Cause Attribute, and their 449 corresponding meanings are described in [RFC3576], Section 3.1. 451 3. Table of Attributes 453 The following table provides a guide to which Attributes may be found in 454 which kinds of packets, and in what quantity. If an Attribute is not 455 mentioned in this table, then it SHOULD NOT be included in Notify- 456 Request, Notify-Accept or Notify-Reject packets. 458 Notify Notify Notify 459 Request Accept Reject # Attribute 460 1 1 0 1 User-Name [Note 1] 461 0-1 0 0 4 NAS-IP-Address [Note 2] 462 0-1 0 0 5 NAS-Port [Note 5] 463 1 0 0 6 Service-Type [Note 10,11] 464 0-1 0 0 7 Framed-Protocol [Note 10] 465 0-1 0-1 0-1 24 State [Note 12] 466 0-1 0-1 0 28 Idle-Timeout [Note 3] 467 0-1 0 0 30 Called-Station-Id [Note 4] 468 0-1 0 0 31 Calling-Station-Id [Note 1] 469 0-1 0 0 32 NAS-Identifier [Note 2] 470 0+ 0+ 0+ 33 Proxy-State 471 0 0-1 0 44 Acct-Session-Id [Note 7] 472 0-1 0-1 0 50 Acct-Multi-Session-Id [Note 6] 473 0-1 0-1 0-1 55 Event-Timestamp [Note 9] 474 1 0 0 61 NAS-Port-Type [Note 10] 475 0-1 0 0 87 NAS-Port-Id [Note 5] 476 0-1 0 0 94 Originating-Line-Info [Note 5] 477 0-1 0 0 95 NAS-IPv6-Address [Note 2] 478 0 0 0-1 101 Error-Cause [Note 8] 479 Notify Notify Notify 480 Request Accept Reject # Attribute 482 The following table defines the meaning of the above table entries. 484 0 This Attribute MUST NOT be present in packet. 485 0+ Zero or more instances of this Attribute MAY be present in packet. 486 0-1 Zero or one instance of this Attribute MAY be present in packet. 487 1 Exactly one instance of this Attribute MUST be present in packet. 489 [Note 1] The User-Name Attribute MUST be provided in the Notify-Request 490 and MUST be echoed in the Notify-Accept, and subsequent Access-Request 491 packets. 493 [Note 2] A Notify-Request MUST contain a NAS-IP-Address, NAS- 494 IPv6-Address or NAS-Identifier Attribute (or some combination of these). 496 [Note 3] Within a Notify-Request, the Idle-Timeout Attribute provides a 497 suggested amount of time for which the NAS may reserve resources for a 498 potential handoff. If an Idle-Timeout Attribute is included within the 499 Notify-Request, then if the NAS is unable to reserve resources for this 500 period of time, then it MUST include an Idle-Timeout Attribute in the 501 Notify-Accept, if sent, specifying the time it is willing to commit to. 502 The RADIUS server should assume that the resources have been released at 503 time Event-Timestamp + Idle-Timeout. 505 [Note 4] Within a Notify-Request, Called-Station-Id refers to the NAS 506 from which the handoff is expected to occur. If the handoff does not 507 occur from that NAS referred to in Called-Station-Id, then the NAS MAY 508 refuse the handoff. In the case where NAS-Port-Type = 802.11, and the 509 Called-Station-Id contains an SSID, then if the handoff occurs, the 510 client MUST be granted access only to this SSID. If the attempts to 511 connect to another SSID, then the NAS MUST deny network access to the 512 client. If the SSID field is omitted, then a value of ANY is assumed. 514 [Note 5] The NAS-Port and NAS-Port-Id Attributes, if present, refer to 515 the NAS port from which the handoff is expected to occur. Originating- 516 Line-Info provides information on how the session originated. 518 [Note 6] Within a Notify-Request, the Acct-Multi-Session-Id provides a 519 unique identifier for user sessions during handoffs between NASes. The 520 Acct-Multi-Session-Id is echoed in subsequent Access-Request and 521 Accounting-Request packets. 523 [Note 7] The Acct-Session-Id, if present in Notify-Accept packets, 524 denotes the accounting session id allocated by the NAS for the 525 prospective handoff, should it occur. The Acct-Session-Id is echoed in 526 subsequent Access-Request and Accounting-Request packets. 528 [Note 8] The Error-Cause Attribute is present only in Notify-Reject 529 packets, and specifies the reason for the rejection. It is defined in 530 [RFC3576], Section 3.1. 532 [Note 9] When IPsec replay protection is not used, the Event-Timestamp 533 Attribute MUST be present in all packets in order to prevent replay 534 attacks. This is discussed in Section 4. 536 [Note 10] The Service-Type, NAS-Port-Type, and Framed-Protocol 537 Attributes are used to specify the services that are to be provided to 538 the handed off session. The Service-Type and NAS-Port-Type Attributes 539 MUST be present in the Notify-Request; when used with 802.11, it is 540 expected that a NAS-Port-Type Attribute with value "802.11" and a 541 Service-Type Attribute with a value of "Authorize Only" will be 542 included. The Service-Type is echoed in the subsequent Access-Request. 543 If the NAS is not able to provide the specified service, then it MUST 544 send a Notify-Reject. 546 [Note 11] The Service-Type Attribute is included with a value of 547 "Authorize Only" within a RADIUS Access-Request in order to indicate 548 that only authorization is being requested, as defined in [RFC3576]. 549 Where used in concert with this specification, such an Access-Request 550 indicates that a handoff request is being anticipated and that the 551 RADIUS server should send back an Access-Accept to allow the prospective 552 handoff to occur, or an Access-Reject to deny the prospective handoff. 554 The decision is typically based on the User-Name, Called-Station-Id, 555 Calling-Station-Id, and State attributes. 557 [Note 12] The State Attribute is available to be sent by the RADIUS 558 server to the NAS in a Notify-Request message and MUST be sent 559 unmodified from the NAS to the RADIUS server in subsequent Notify- 560 Accept, Notify-Reject or Access-Request messages. The NAS MUST NOT 561 interpret the State Attribute locally. A Notify-Request, Notify-Accept 562 or Notify-Reject packet must have only zero or one State Attribute. 563 Usage of the State Attribute is implementation dependent. If the RADIUS 564 server does not recognize the State Attribute in the Access-Request, 565 then it MUST send an Access-Reject. 567 4. Security considerations 569 4.1. Authorize-Only messages 571 After receipt of a Notify-Request, a NAS supporting this specification 572 will respond with a Notify-Response, and if the Response is a Notify- 573 Accept, the NAS will then send an Access-Request to the RADIUS server 574 with a Service-Type value of "Authorize Only". In some cases, the NAS 575 MAY send an Access-Request with a Service-Type value of "Authorize Only" 576 even if it had not previously received a Notify-Request packet. 578 This could occur, for example, in the case of an IEEE 802.11 Access 579 Point (AP) receiving a Reassociation-Request frame from a Station. In 580 order to avoid a complete EAP authentication as described in 581 [RFC2284bis], it may be desirable for the AP to instead retrieve 582 suitable keying material in order to complete a proof-of-possession 583 exchange with the Station, as described in [IEEE80211i]. 585 A RADIUS server SHOULD NOT respond to an Access-Request with a Service- 586 Type value of "Authorize Only" unless a Message-Authenticator attribute 587 is present, since otherwise the Access-Request will be unauthenticated. 588 Even when a Message-Authenticator attribute is present, a RADIUS server 589 MAY choose not to respond to "Authorize Only" Access-Requests unless 590 certain conditions are met. For example, a RADIUS server MAY only 591 respond to NAS devices to which a Notify-Request has previously been 592 sent. Alternatively a RADIUS server MAY only respond to "Authorize 593 Only" Access-Requests in situations where the user will subsequently 594 authenticate to the NAS device. For example, IEEE 802.11 APs supporting 595 WPA or RSN carry out a proof-of-possession exchange with the station, 596 ensuring that only stations with access to appropriate keying material 597 can gain access to the network. 599 4.2. State removal 601 By responding to an Access-Request with an Access-Accept and suitable 602 keying material, the RADIUS server installs state on the NAS, as 603 described in [Keyframe]. While the NAS will typically remove unused 604 state at a suitable interval, there may be circumstances in which it is 605 desirable for the server to initiate removal of the state. For example, 606 if a user account were to become compromised, it may be necessary not 607 only to disable the account, but to remove state associated with the 608 user on all NASes. 610 State removal can be accomplished by use of Disconnect messages, as 611 described in [RFC3576]. To request that a NAS remove state associated 612 with a given user, the RADIUS server can send a Disconnect-Request to 613 the NAS containing session identification attributes describing the 614 state to be removed. Typically this will include a User-Name attribute, 615 but other attributes could be included as well. 617 If the user session is not active on the NAS, but the NAS is able to 618 remove the state associated with the user, it will respond with a 619 Disconnect-NAK containing an Error-Cause Attribute with a value of 620 "Residual Session Context Removed". If the NAS is not able to remove 621 the state, it will respond with a Disconnect-NAK containing an Error- 622 Cause Attribute with a value of "Session Context Not Removable" or 623 "Session Context Not Found". See Section 3.1 of [RFC3576] for more 624 details. 626 4.3. Authorization issues 628 A NAS or RADIUS proxy MUST silently discard Notify-Request packets from 629 untrusted sources. By default, a RADIUS proxy SHOULD perform a "reverse 630 path forwarding" (RPF) check to verify that a Notify-Request originates 631 from an authorized RADIUS server. In addition, it SHOULD be possible to 632 explicitly authorize additional sources of Notify-Request packets 633 relating to certain classes of sessions. For example, a particular 634 source can be explicitly authorized to send Notify-Request messages 635 relating to users within a set of realms. 637 To perform the RPF check, the proxy uses the session identification 638 attributes included in Notify-Request packets, in order to determine the 639 RADIUS server(s) to which an equivalent Access-Request could be routed. 640 If the source address of the Notify-Request is within this set, then the 641 Request is forwarded; otherwise it MUST be silently discarded. 643 Typically the proxy will extract the realm from the Network Access 644 Identifier [RFC2486] included within the User-Name Attribute, and 645 determine the corresponding RADIUS servers in the proxy routing tables. 646 The RADIUS servers for that realm are then compared against the source 647 address of the packet. Where no RADIUS proxy is present, the RPF check 648 will need to be performed by the NAS itself. 650 Since authorization to send a Notify-Request is determined based on the 651 source address and the corresponding shared secret, the NASes or proxies 652 SHOULD configure a different shared secret for each RADIUS server. 654 4.4. Impersonation 656 [RFC2865] Section 3 states: 658 A RADIUS server MUST use the source IP address of the RADIUS 659 UDP packet to decide which shared secret to use, so that 660 RADIUS requests can be proxied. 662 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 663 NAS-IPv6-Address Attributes will typically not match the source address 664 observed by the RADIUS server. Since the NAS-Identifier Attribute need 665 not contain an FQDN, this Attribute may not be resolvable to the source 666 address observed by the RADIUS server, even when no proxy is present. 668 As a result, the authenticity check performed by a RADIUS server or 669 proxy does not verify the correctness of NAS identification Attributes. 670 This makes it possible for a rogue NAS to forge NAS-IP-Address, NAS- 671 IPv6-Address or NAS-Identifier Attributes within a RADIUS Access-Request 672 in order to impersonate another NAS. It is also possible for a rogue 673 NAS to forge session identification Attributes such as the Called- 674 Station-Id, Calling-Station-Id, or Originating-Line-Info [NASREQ]. This 675 could fool the RADIUS server into sending Notify-Request messages 676 containing forged session identification Attributes to a NAS targeted by 677 an attacker. 679 To address these vulnerabilities RADIUS proxies SHOULD check whether NAS 680 identification Attributes match the source address of packets 681 originating from the NAS. Where one or more Attributes do not match, 682 Notify-Request messages SHOULD be silently discarded. 684 Such a check may not always be possible. Since the NAS-Identifier 685 Attribute need not correspond to an FQDN, it may not be resolvable to an 686 IP address to be matched against the source address. Also, where a NAT 687 exists between the RADIUS client and proxy, checking the NAS-IP-Address 688 or NAS-IPv6-Address Attributes may not be feasible. 690 4.5. IPsec usage guidelines 692 In addition to security vulnerabilities unique to Notify messages, the 693 protocol exchanges described in this document are susceptible to the 694 same vulnerabilities as RADIUS [RFC2865]. It is RECOMMENDED that IPsec 695 be employed to afford better security. 697 Implementations of this specification SHOULD support IPsec [RFC2401] 698 along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with a 699 non-null transform SHOULD be supported, and IPsec ESP with a non-null 700 encryption transform and authentication support SHOULD be used to 701 provide per-packet confidentiality, authentication, integrity and replay 702 protection. IKE SHOULD be used for key management. 704 Within RADIUS [RFC2865], a shared secret is used for hiding Attributes 705 such as User-Password, as well as used in computation of the Response 706 Authenticator. In RADIUS accounting [RFC2866], the shared secret is 707 used in computation of both the Request Authenticator and the Response 708 Authenticator. 710 Since in RADIUS a shared secret is used to provide confidentiality as 711 well as integrity protection and authentication, only use of IPsec ESP 712 with a non-null transform can provide security services sufficient to 713 substitute for RADIUS application-layer security. Therefore, where 714 IPsec AH or ESP null is used, it will typically still be necessary to 715 configure a RADIUS shared secret. 717 Where RADIUS is run over IPsec ESP with a non-null transform, the secret 718 shared between the NAS and the RADIUS server MAY NOT be configured. In 719 this case, a shared secret of zero length MUST be assumed. However, a 720 RADIUS server that cannot know whether incoming traffic is IPsec- 721 protected MUST be configured with a non-null RADIUS shared secret. 723 When IPsec ESP is used with RADIUS, per-packet authentication, integrity 724 and replay protection MUST be used. 3DES-CBC MUST be supported as an 725 encryption transform and AES-CBC SHOULD be supported. AES-CBC SHOULD be 726 offered as a preferred encryption transform if supported. HMAC-SHA1-96 727 MUST be supported as an authentication transform. DES-CBC SHOULD NOT be 728 used as the encryption transform. 730 A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate 731 IPsec, from me to any destination port UDP 1812". This IPsec policy 732 causes an IPsec SA to be set up by the RADIUS client prior to sending 733 RADIUS traffic. If some RADIUS servers contacted by the client do not 734 support IPsec, then a more granular policy will be required: "Initiate 735 IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 736 1812". 738 For a client implementing this specification the policy would be "Accept 739 IPsec, from any to me, destination port UDP 3799". This causes the 740 RADIUS client to accept (but not require) use of IPsec. It may not be 741 appropriate to require IPsec for all RADIUS servers connecting to an 742 IPsec-enabled RADIUS client, since some RADIUS servers may not support 743 IPsec. 745 For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept 746 IPsec, from any to me, destination port 1812". This causes the RADIUS 747 server to accept (but not require) use of IPsec. It may not be 748 appropriate to require IPsec for all RADIUS clients connecting to an 749 IPsec-enabled RADIUS server, since some RADIUS clients may not support 750 IPsec. 752 For servers implementing this specification, the policy would be 753 "Initiate IPsec, from me to any, destination port UDP 3799". This 754 causes the RADIUS server to initiate IPsec when sending RADIUS handoff 755 extension traffic to any RADIUS client. If some RADIUS clients 756 contacted by the server do not support IPsec, then a more granular 757 policy will be required, such as "Initiate IPsec, from me to IPsec- 758 capable-RADIUS-client, destination port UDP 3799". 760 Where IPsec is used for security, and no RADIUS shared secret is 761 configured, it is important that the RADIUS client and server perform an 762 authorization check. Before enabling a host to act as a RADIUS client, 763 the RADIUS server SHOULD check whether the host is authorized to provide 764 network access. Similarly, before enabling a host to act as a RADIUS 765 server, the RADIUS client SHOULD check whether the host is authorized 766 for that role. 768 RADIUS servers can be configured with the IP addresses (for IKE 769 Aggressive Mode with pre-shared keys) or FQDNs (for certificate 770 authentication) of RADIUS clients. Alternatively, if a separate 771 Certification Authority (CA) exists for RADIUS clients, then the RADIUS 772 server can configure this CA as a trust anchor [RFC3280] for use with 773 IPsec. 775 Similarly, RADIUS clients can be configured with the IP addresses (for 776 IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate 777 authentication) of RADIUS servers. Alternatively, if a separate CA 778 exists for RADIUS servers, then the RADIUS client can configure this CA 779 as a trust anchor for use with IPsec. 781 Since unlike SSL/TLS, IKE does not permit certificate policies to be set 782 on a per-port basis, certificate policies need to apply to all uses of 783 IPsec on RADIUS clients and servers. In IPsec deployment supporting 784 only certificate authentication, a management station initiating an 785 IPsec-protected telnet session to the RADIUS server would need to obtain 786 a certificate chaining to the RADIUS client CA. Issuing such a 787 certificate might not be appropriate if the management station was not 788 authorized as a RADIUS client. 790 Where RADIUS clients may obtain their IP address dynamically (such as an 791 Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409] 792 SHOULD NOT be used, since this requires use of a group pre-shared key; 793 instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses 794 are statically assigned either Aggressive Mode or Main Mode MAY be used. 795 With certificate authentication, Main Mode SHOULD be used. 797 Care needs to be taken with IKE Phase 1 Identity Payload selection in 798 order to enable mapping of identities to pre-shared keys even with 799 Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity 800 Payloads are used and addresses are dynamically assigned, mapping of 801 identities to keys is not possible, so that group pre-shared keys are 802 still a practical necessity. As a result, the ID_FQDN identity payload 803 SHOULD be employed in situations where Aggressive mode is utilized along 804 with pre-shared keys and IP addresses are dynamically assigned. This 805 approach also has other advantages, since it allows the RADIUS server 806 and client to configure themselves based on the fully qualified domain 807 name of their peers. 809 Note that with IPsec, security services are negotiated at the 810 granularity of an IPsec SA, so that RADIUS exchanges requiring a set of 811 security services different from those negotiated with existing IPsec 812 SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also 813 advisable where quality of service considerations dictate different 814 handling RADIUS conversations. Attempting to apply different quality of 815 service to connections handled by the same IPsec SA can result in 816 reordering, and falling outside the replay window. For a discussion of 817 the issues, see [RFC2983]. 819 4.6. Replay protection 821 Since this specification utilizes the Request Authenticator field for 822 integrity protection and authentication, rather than as a nonce, no 823 liveness or protection against replay is provided by the RADIUS header. 825 Where IPsec replay protection is not used, the Event-Timestamp (55) 826 Attribute [RFC2869] SHOULD be included within all messages. When this 827 attribute is present, both the NAS and the RADIUS server MUST check that 828 the Event-Timestamp Attribute is current within an acceptable time 829 window. If the Event-Timestamp Attribute is not current, then the 830 message MUST be silently discarded. This implies the need for time 831 synchronization within the network, which can be achieved by a variety 832 of means, including secure NTP, as described in [NTPAUTH]. 834 Both the NAS and the RADIUS server SHOULD be configurable to silently 835 discard messages lacking an Event-Timestamp Attribute. A default time 836 window of 300 seconds is recommended. 838 4.7. Spoofing and hijacking 840 Access-Request packets with a User-Password Attribute establish the 841 identity of both the user and the NAS sending the Access-Request, 842 because of the way the shared secret between the NAS and RADIUS server 843 is used. Access-Request packets with CHAP-Password or EAP-Message 844 Attributes do not have a User-Password Attribute. As a result, the 845 Message-Authenticator Attribute SHOULD be used in Access-Request packets 846 that do not have a User-Password Attribute, in order to establish the 847 identity of the NAS sending the request. This includes Access-Request 848 packets with a Service-Type Attribute with a value of "Authorize Only". 850 An attacker may attempt to inject packets into the conversation between 851 the NAS and the RADIUS server. RADIUS [RFC2865] does not support 852 encryption other than Attribute hiding. As described in [RFC2865], only 853 Access-Reply and Access-Challenge packets are authenticated and 854 integrity protected. ??? from here until ???END lines may have been 855 inserted/deleted Moreover, the per-packet authentication and integrity 856 protection mechanism described in this specification has known 857 weaknesses [MD5Attack], making it a tempting target for attackers. 859 To provide stronger security, implementations of this specification 860 SHOULD use IPsec ESP with non-null transform and per-packet encryption, 861 authentication, integrity and replay protection, as specified in Section 862 4.3. 864 5. IANA Considerations 866 This specification requires assignment of RADIUS Type codes for Notify- 867 Request, Notify-Accept, and Notify-Reject. IANA considerations for 868 RADIUS are described in [RFC3575]. 870 6. References 872 6.1. Normative references 874 [RFC1305] Mills, D. L., "Network Time Protocol (version 3) 875 Specification, Implementation and Analysis, RFC 1305 876 March, 1992. 878 [RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest 879 Algorithm", RFC 1321, April 1992. 881 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 882 Hashing for Message Authentication", RFC 2104, February 883 1997. 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", RFC 2119, March, 1997. 888 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 889 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 890 October 1998. 892 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 893 "Remote Authentication Dial In User Service (RADIUS)", 894 RFC 2865, June 2000. 896 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 898 [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS 899 Extensions", RFC 2869, June 2000. 901 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 902 X.509 Public Key Infrastructure Certificate and 903 Certificate Revocation List (CRL) Profile", RFC 3280, 904 April 2002. 906 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, 907 July 2003. 909 [RFC3576] Chiba, M., et. al., "Dynamic Authorization Extensions to 910 Remote Authentication Dial-in User Service (RADIUS)", 911 RFC 3576, July 2003. 913 6.2. Informative references 915 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 916 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 917 October 1998. 919 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 920 Implementation in Roaming", RFC 2607, June 1999. 922 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 923 Protocol", RFC 2716, October 1999. 925 [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 926 2983, October 2000. 928 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 929 3162, August 2001. 931 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 932 Authentication Protocol (EAP)", RFC 3579, September 2003. 934 [RFC3580] Congdon, P., et al., "IEEE 802.1X RADIUS Usage 935 Guidelines", RFC 3580, September 2003. 937 [Context] Aboba, B. and T. Moore, "A Model for Context Transfer in 938 IEEE 802", draft-aboba-802-context-03.txt, Internet draft 939 (work in progress), October 2003. 941 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 942 Overview and Architecture, ANSI/IEEE Std 802, 1990. 944 [IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: 945 Draft Standard for Virtual Bridged Local Area Networks, 946 P802.1Q, January 1998. 948 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 949 Port based Network Access Control, IEEE Std 802.1X-2001, 950 June 2001. 952 [IEEE-02-758] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 953 "Proactive Caching Strategies for IAPP Latency 954 Improvement during 802.11 Handoff", IEEE 802.11 Working 955 Group, IEEE-02-758r1-F, November 2002. 957 [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 958 "Proactive Key Distribution to support fast and secure 959 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 960 http://www.ieee802.org/11/Documents/DocumentHolder/ 961 3-084.zip, January 2003. 963 [8021XHandoff] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in 964 a Public Wireless LAN Based on IEEE 802.1X Model", School 965 of Computer Science and Engineering, Seoul National 966 University, Seoul, Korea, 2002. 968 [IEEE8023] ISO/IEC 8802-3 Information technology - 969 Telecommunications and information exchange between 970 systems - Local and metropolitan area networks - Common 971 specifications - Part 3: Carrier Sense Multiple Access 972 with Collision Detection (CSMA/CD) Access Method and 973 Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 974 1996), 1996. 976 [IEEE80211] Information technology - Telecommunications and 977 information exchange between systems - Local and 978 metropolitan area networks - Specific Requirements Part 979 11: Wireless LAN Medium Access Control (MAC) and 980 Physical Layer (PHY) Specifications, IEEE Std. 981 802.11-1999, 1999. 983 [IEEE80211f] Information technology - Telecommunications and 984 information exchange between systems - Local and 985 metropolitan area networks - Specific Requirements Part 986 11: Recommended Practice for Multi-Vendor Access Point 987 Interoperability via an Inter-Access Point Protocol 988 Across Distribution Systems Supporting IEEE 802.11 989 Operation, IEEE Draft 802.11f/D5, January 2003. 991 [IEEE80211i] Institute of Electrical and Electronics Engineers, "Draft 992 Supplement to STANDARD FOR Telecommunications and 993 Information Exchange between Systems - LAN/MAN Specific 994 Requirements - Part 11: Wireless Medium Access Control 995 (MAC) and physical layer (PHY) specifications: 996 Specification for Enhanced Security", IEEE Draft 802.11I/ 997 D6.1, August 2003. 999 [RFC2284bis] Blunk, L. et al., "Extensible Authentication Protocol 1000 (EAP)", draft-ietf-eap-rfc2284bis-06.txt, Internet draft 1001 (work in progress), September 2003. 1003 [Keyframe] Aboba, B., Simon, D. and J. Arkko, "EAP Key Management 1004 Framework", draft-ietf-eap-keying-01.txt, Internet draft 1005 (work in progress), November 2003. 1007 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack." 1008 CryptoBytes Vol.2 No.2, Summer 1996. 1010 [NASREQ] Calhoun, P., et al., "Diameter Network Access Server 1011 Application", draft-ietf-aaa-diameter-nasreq-13.txt, 1012 Internet draft (work in progress), October 2003. 1014 [NTPAuth] Mills, D., "Public Key Cryptography for the Network Time 1015 Protocol", Internet draft (work in progress), draft-ietf- 1016 stime-ntpauth-05.txt, November 2002. 1018 Acknowledgments 1020 The authors would like to acknowledge the following people for 1021 contributions to this document: Tim Moore (Microsoft), Min-ho Shin 1022 (University of Maryland), Nick Petroni (University of Maryland), Adam 1023 Sulmicki (University of Maryland), Insun Lee (Samsung Electronics), 1024 Kyunghun Jang (Samsung Electronics). 1026 Authors' Addresses 1028 William A. Arbaugh 1029 Department of Computer Science 1030 University of Maryland, College Park 1031 A.V. Williams Building 1032 College Park, MD 20742 1034 EMail: waa@cs.umd.edu 1035 Phone: +1 301 405 2774 1037 Bernard Aboba 1038 Microsoft Corporation 1039 One Microsoft Way 1040 Redmond, WA 98052 1042 EMail: bernarda@microsoft.com 1043 Phone: +1 425 706 6605 1044 Fax: +1 425 936 7329 1046 Intellectual Property Statement 1048 The IETF takes no position regarding the validity or scope of any 1049 intellectual property or other rights that might be claimed to pertain 1050 to the implementation or use of the technology described in this 1051 document or the extent to which any license under such rights might or 1052 might not be available; neither does it represent that it has made any 1053 effort to identify any such rights. Information on the IETF's 1054 procedures with respect to rights in standards-track and standards- 1055 related documentation can be found in BCP-11. Copies of claims of 1056 rights made available for publication and any assurances of licenses to 1057 be made available, or the result of an attempt made to obtain a general 1058 license or permission for the use of such proprietary rights by 1059 implementors or users of this specification can be obtained from the 1060 IETF Secretariat. 1062 The IETF invites any interested party to bring to its attention any 1063 copyrights, patents or patent applications, or other proprietary rights 1064 which may cover technology that may be required to practice this 1065 standard. Please address the information to the IETF Executive 1066 Director. 1068 Full Copyright Statement 1070 Copyright (C) The Internet Society (2003). All Rights Reserved. 1071 This document and translations of it may be copied and furnished to 1072 others, and derivative works that comment on or otherwise explain it or 1073 assist in its implementation may be prepared, copied, published and 1074 distributed, in whole or in part, without restriction of any kind, 1075 provided that the above copyright notice and this paragraph are included 1076 on all such copies and derivative works. However, this document itself 1077 may not be modified in any way, such as by removing the copyright notice 1078 or references to the Internet Society or other Internet organizations, 1079 except as needed for the purpose of developing Internet standards in 1080 which case the procedures for copyrights defined in the Internet 1081 Standards process must be followed, or as required to translate it into 1082 languages other than English. The limited permissions granted above are 1083 perpetual and will not be revoked by the Internet Society or its 1084 successors or assigns. This document and the information contained 1085 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1086 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1087 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1088 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1089 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1091 Expiration Date 1093 This memo is filed as , and expires 1094 April 22, 2004.