idnits 2.17.1 draft-irtf-aaaarch-handoff-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 20 longer pages, the longest (page 13) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 619 has weird spacing: '...e might not b...' == Line 801 has weird spacing: '...imed to perta...' == Line 844 has weird spacing: '...>, and expir...' -- 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 (22 February 2003) is 7733 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Note 1' is mentioned on line 455, but not defined == Missing Reference: 'Note 2' is mentioned on line 461, but not defined == Missing Reference: 'Note 10' is mentioned on line 510, but not defined -- Looks like a reference, but probably isn't: '11' on line 439 == Missing Reference: 'Note 3' is mentioned on line 464, but not defined == Missing Reference: 'Note 4' is mentioned on line 473, but not defined == Missing Reference: 'Note 7' is mentioned on line 494, but not defined == Missing Reference: 'Note 8' is mentioned on line 502, but not defined == Missing Reference: 'Note 6' is mentioned on line 489, but not defined == Missing Reference: 'Note 9' is mentioned on line 506, but not defined == Missing Reference: 'Note 5' is mentioned on line 478, but not defined == Missing Reference: 'Note 11' is mentioned on line 520, but not defined == Missing Reference: 'RFC2401' is mentioned on line 548, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'RFC2409' is mentioned on line 623, but not defined ** Obsolete undefined reference: RFC 2409 (Obsoleted by RFC 4306) == Missing Reference: 'RFC2406' is mentioned on line 549, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'RFC2983' is mentioned on line 650, but not defined == Unused Reference: 'RFC1305' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC3162' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'IEEE8021X' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'DynAuth' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'RFC2607' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'IEEE8021Q' is defined on line 736, but no explicit reference was found in the text == Unused Reference: 'IEEE8023' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'MD5Attack' is defined on line 772, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) == Outdated reference: A later version (-29) exists of draft-congdon-radius-8021x-21 == Outdated reference: A later version (-20) exists of draft-chiba-radius-dynamic-authorization-05 -- No information found for draft-irtf-aaaarch-neighbor-graph - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Unexpected draft version: The latest known version of draft-ietf-stime-ntpauth is -04, but you're referring to -05. (However, the state information for draft-irtf-aaaarch-neighbor-graph is not up-to-date. The last update was unsuccessful) Summary: 8 errors (**), 0 flaws (~~), 34 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group William A. Arbaugh 3 INTERNET-DRAFT University of Maryland 4 Category: Experimental 5 6 22 February 2003 8 Experimental Handoff Extension to RADIUS 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet- Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2003). All Rights Reserved. 32 Abstract 34 In order to decrease handoff latency, the concept of pre-emptive 35 provisioning is under investigation. This document describes an 36 experimental extension to the RADIUS protocol that enables a RADIUS 37 server to notify a NAS of a prospective handoff. This enables the NAS to 38 reserve resources and obtain the session parameters prior to arrival of 39 the client, potentially reducing handoff times. Whether the approach 40 described in this document is effective, deployable or secure is a 41 subject of current research. As a result, implementation of this 42 extension for purposes other than research is not recommended at this 43 time. 45 Table of Contents 47 1. Introduction .......................................... 3 48 1.1 Terminology ..................................... 4 49 1.2 Requirements language ........................... 5 50 2. Packet format ......................................... 5 51 2.1 Notify-Request .................................. 7 52 2.2 Notify-Accept ................................... 7 53 2.3 Notify-Reject ................................... 8 54 3. Attributes ............................................ 9 55 3.1 Previous-Called-Station-Id ...................... 9 56 3.2 Table of attributes ............................. 11 57 4. Security considerations ............................... 13 58 4.1 IPsec usage guidelines .......................... 13 59 4.2 Replay protection ............................... 15 60 5. IANA considerations ................................... 15 61 6. Normative references .................................. 15 62 7. Informative references ................................ 16 63 ACKNOWLEDGMENTS .............................................. 17 64 AUTHORS' ADDRESSES ........................................... 17 65 Intellectual Property Statement .............................. 18 66 Full Copyright Statement ..................................... 18 67 1. Introduction 69 In wireless networks such as IEEE 802.11, described in [IEEE80211], it 70 may be desirable to improve the speed at which handoff can be completed. 71 Where RADIUS Accounting [RFC2866] is implemented, RADIUS Accounting 72 packets will be generated each time the client connects to a NAS. 73 Accounting packets from a single session, across multiple NASes, are 74 uniquely identified by the Acct-Multi-Session-Id attribute, described in 75 [RFC2866] and [Congdon]. 77 The sequence of NASes contacted by clients as they move creates a graph 78 representing the mobility paths of the clients. We call this graph a 79 neighbor graph with NASes as the vertices and the mobility paths between 80 the NASes as the edges. Thus, the number of neighbors for a given NAS is 81 given by the degree function applied to the vertex representing the 82 given NAS, e.g. for NAS_A the number of neighbors would be given by 83 deg(v_A) where deg is the degree function- deg: V -> int. Through 84 knowledge of the neighbor graph, it is possible for a RADIUS server to 85 anticipate client movements and provide advance notice of a potential 86 handoff to the NAS. This advance notice, known as a Notify-Request in 87 this specification, allows the NAS to reserve resources and obtain the 88 session authorization parameters prior to arrival of the client. This 89 removes the latency of the RADIUS exchange from the critical path for 90 processing a handoff, decreasing handoff latency substantially, as 91 described in [IEEE-02-758, IEEE-03-084]. Assuming that the coverage area 92 is over-lapping, this technique can support handoffs at vehicular 93 velocities. The creation and maintenance of neighbor graphs at an AS is 94 described in [Mishra]. 96 An alternate approach to using neighbor graphs uses a matrix of 97 probabilities and is described in [8021XHandoff]. 99 By nature, client behavior is not completely predictable, so that the 100 handoff advance notice is only advisory. The client identified in the 101 advance notice may never contact the NAS, or may contact it long after 102 the initial notice is received. As a result, the NAS will typically free 103 reserved resources after a suitable waiting period, known as the 104 Reservation-Lifetime. A client contacting the NAS after the Reservation- 105 Lifetime has expired will be unable to complete a handoff, and will need 106 to do a fast resume, such as is supported in EAP TLS [RFC2716]. 108 The extension described in this document enables a RADIUS Server to send 109 Notify-Requests to NASes, and to receive Notify-Responses. The Notify- 110 Request identifies the session to be handed off. Attributes included 111 within the Notify-Request are described in Section 2.1. If the NAS has 112 resources available to reserve, and if it is enabled to support this 113 handoff extension, then it will respond with a Notify-Accept. If 114 resources are not available (such as when previous resource commitments 115 leave insufficient resources remaining), or if the NAS does not wish to 116 support the handoff for any other reason, the NAS will respond with a 117 Notify-Reject, specifying the reason why the requested handoff 118 reservation could not be carried out. 120 After the NAS responds with a Notify-Accept, it will typically issue an 121 Access-Request to the RADIUS server. This allows the NAS to obtain the 122 authorizations for the session before it is contacted by the client. The 123 contents of the Access-Request sent by the NAS will depend on the form 124 of access it is providing, so that it cannot be specified in detail 125 here. However, for use with IEEE 802.11, it is expected that an Access- 126 Request will be sent with a NAS-Port-Type=802.11 and a Service- 127 Type=Handoff. For other access methods, a different NAS-Port-Type value 128 might be sent, along with a different value for Service-Type. 130 1.1. Terminology 132 This document uses the following terms: 134 Authenticator 135 An Authenticator is an entity that require authentication from 136 the Supplicant. The Authenticator may be connected to the 137 Supplicant at the other end of a point-to-point LAN segment or 138 802.11 wireless link. 140 Authentication Server 141 An Authentication Server is an entity that provides an 142 Authentication Service to an Authenticator. This service 143 verifies from the credentials provided by the Supplicant, the 144 claim of identity made by the Supplicant. 146 Network Access Server (NAS) 147 The device providing access to the network. 149 Service The NAS provides a service to the user, such as IEEE 802 or 150 PPP. 152 Port Access Entity (PAE) 153 The protocol entity associated with a physical or virtual 154 (802.11) Port. A given PAE may support the protocol 155 functionality associated with the Authenticator, Supplicant or 156 both. 158 Session Each service provided by the NAS to a user constitutes a 159 session, with the beginning of the session defined as the 160 point where service is first provided and the end of the 161 session defined as the point where service is ended. A user 162 may have multiple sessions in parallel or series if the NAS 163 supports that, with each session generating a separate start 164 and stop accounting record. Where the client is mobile and is 165 able to handoff between NASes, multiple related sessions may 166 be uniquely identified by the Acct-Multi-Session-Id attribute. 168 Supplicant 169 A Supplicant is an entity that is being authenticated by an 170 Authenticator. The Supplicant may be connected to the 171 Authenticator at one end of a point-to-point LAN segment or 172 802.11 wireless link. 174 1.2. Requirements language 176 In this document, several words are used to signify the requirements of 177 the specification. These words are often capitalized. The key words 178 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 179 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 180 interpreted as described in [RFC2119]. 182 2. Packet format 184 Exactly one Notify-Request, Notify-Accept or Notify-Reject packet is 185 encapsulated in the UDP Data field. For the Notify-Request packet, the 186 UDP Destination Port field is TBD. When a reply is generated, the 187 source and destination ports are reversed. 189 A summary of the data format is shown below. The fields are transmitted 190 from left to right. 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Code | Identifier | Length | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | 198 | Authenticator | 199 | | 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Attributes ... 203 +-+-+-+-+-+-+-+-+-+-+-+-+- 204 Code 206 The Code field is one octet, and identifies the type of RADIUS 207 packet. When a packet is received with an invalid Code field, it is 208 silently discarded. RADIUS codes (decimal) for this extension are 209 assigned as follows: 211 TBD - Notify-Request 212 TBD - Notify-Accept 213 TBD - Notify-Reject 215 Identifier 217 The Identifier field is one octet, and aids in matching requests and 218 replies. The RADIUS server can detect a duplicate request if it has 219 the same client source IP address and source UDP port and Identifier 220 within a short span of time. 222 Length 224 The Length field is two octets. It indicates the length of the 225 packet including the Code, Identifier, Length, Authenticator and 226 Attribute fields. Octets outside the range of the Length field MUST 227 be treated as padding and ignored on reception. If the packet is 228 shorter than the Length field indicates, it MUST be silently 229 discarded. The minimum length is 20 and maximum length is 4096. 231 Authenticator 233 The Authenticator field is sixteen (16) octets. The most significant 234 octet is transmitted first. This value is used to authenticate the 235 messages between the client and RADIUS server. 237 Request Authenticator 239 In Notify-Request Packets, the Authenticator value is a 16 octet MD5 240 [RFC1321] checksum, called the Request Authenticator. The Request 241 Authenticator is calculated the same way as for an Accounting- 242 Request, specified in [RFC2866]. 244 Note that the Request Authenticator of an Notify-Request can not be 245 done the same way as the Request Authenticator of a RADIUS Access- 246 Request, because there is no User-Password attribute in an Notify- 247 Request. 249 Response Authenticator 251 The Authenticator field in a Notify-Accept or Notify-Reject packet is 252 called the Response Authenticator, and contains a one-way MD5 hash 253 calculated over a stream of octets consisting of the Notify-Response 254 Code, Identifier, Length, the Request Authenticator field from the 255 Notify-Request packet being replied to, and the response attributes 256 if any, followed by the shared secret. The resulting 16 octet MD5 257 hash value is stored in the Authenticator field of the Notify-Accept 258 or Notify-Reject packet. 260 Attributes 262 Attributes may have multiple instances, in such a case the order of 263 attributes of the same type SHOULD be preserved. The order of 264 attributes of different types is not required to be preserved. 266 2.1. Notify-Request 268 Description 270 A Notify-Request packet is sent by the RADIUS server to the NAS to 271 notify it of the potential handoff of a specified session. 273 Code 275 TBD - Notify-Request 277 Identifier 279 The Identifier field MUST be changed whenever the content of the 280 Attributes field changes, and whenever a valid reply has been 281 received for a previous request. For retransmissions where the 282 contents are identical, the Identifier MUST remain unchanged. 284 Note that if the Event-Timestamp attribute is included the Notify- 285 Request then the Event-Timestamp value will be updated when the 286 packet is retransmitted, changing the content of the Attributes field 287 and requiring a new Identifier and Request Authenticator. 289 Request Authenticator 291 The Request Authenticator of an Accounting-Request contains a 292 16-octet MD5 hash value calculated according to the method described 293 in "Request Authenticator" in Section 2. 295 Attributes 297 The Attribute field is variable in length, and contains a list of 298 Attributes. Within the Notify-Request, Attributes are used to 299 uniquely identify the user session that may potentially be handed off 300 to the NAS, and to describe the services expected to be provided. 301 Where RADIUS is not protected by IPsec, the Event-Timestamp attribute 302 MUST be included so as to protect against replay attacks. Section 303 3.4 provides more detail on the attributes permitted within the 304 Notify-Request packet. 306 2.2. Notify-Accept 308 Description 310 The NAS responds to the Notify-Request with a Notify-Accept if the 311 NAS agrees to to prepare for a handoff of the specified session. 313 Code 315 TBD - Notify-Accept 317 Identifier 319 The Identifier field is a copy of the Identifier field of the Notify- 320 Request which caused this Notify-Accept. 322 Response Authenticator 324 The Response Authenticator of a Notify-Accept contains a 16-octet MD5 325 hash value calculated according to the method described in "Response 326 Authenticator" in Section 2. 328 Attributes 330 The Attribute field is variable in length, and contains a list of 331 Attributes. Within the Notify-Accept, attributes are used to provide 332 the RADIUS server with the session identifiers that will be used by 333 the NAS in subsequent Access-Request and Accounting-Request packets. 334 This includes the User-Name and Acct-Multi-Session-Id attributes 335 originally provided by the RADIUS server in the Notify-Request, as 336 well as an Acct-Session-Id allocated by the NAS for the handoff, 337 should it occur. The Idle-Timeout attribute, when included in the 338 Notify-Accept, provides the RADIUS server with the time that the NAS 339 is willing to reserve resources for the handoff. Where RADIUS is not 340 protected by IPsec, the Event-Timestamp attribute MUST be included so 341 as to protect against replay attacks. Section 3.4 provides more 342 detail on the attributes permitted within the Notify-Accept packet. 344 2.3. Notify-Reject 346 Description 347 The NAS responds to the Notify-Request with a Notify-Reject if the 348 NAS does not have the resources to make the required handoff 349 preparations, or wishes to decline for any other reason. 351 Code 353 TBD - Notify-Reject 355 Identifier 357 The Identifier field is a copy of the Identifier field of the Notify- 358 Request which caused this Notify-Reject. 360 Response Authenticator 362 The Response Authenticator of a Notify-Accept contains a 16-octet MD5 363 hash value calculated according to the method described in "Response 364 Authenticator" in Section 2. 366 Attributes 368 The Attribute field is variable in length, and contains a list of 369 Attributes. Within the Notify-Reject, attributes are used to provide 370 the RADIUS server with the reason why the Notify-Request could not be 371 honored. If the NAS is configured so as not to support the Handoff 372 extension, then an Acct-Terminate-Cause attribute with a value of 373 Admin Reset (5) is included. If the service described in the Notify- 374 Request is not supported, then an Acct-Terminate-Cause attribute with 375 a value of Service Unavailable (15) is included. If resources are not 376 available, then an Acct-Terminate-Cause of Port Preempted (13) is 377 included. Where RADIUS is not protected by IPsec, the Event- 378 Timestamp attribute MUST be included so as to protect against replay 379 attacks. Section 3.4 provides more detail on the attributes 380 permitted within the Notify-Reject packet. 382 3. Attributes 384 3.1. Previous-Called-Station-Id 386 Description 388 This Attribute allows the RADIUS server to send in the Notify-Request 389 packet the link layer address of the NAS that the user last connected 390 to. For IEEE 802.1X Authenticators, this attribute is used to store 391 the bridge or Access Point MAC address in ASCII format, with octet 392 values separated by a "-". Example: "00-10-A4-23-19-C0". In IEEE 393 802.11, where the SSID is known, it SHOULD be appended to the Access 394 Point MAC address, separated from the MAC address with a ":". 396 Example "00-10-A4-23-19-C0:AP1". In the case of a dialup network, 397 this would be the phone number that the user called, using Dialed 398 Number Identification (DNIS) or similar technology. It is only used 399 in Notify-Request packets. 401 A summary of the Previous-Called-Station-Id Attribute format is shown 402 below. The fields are transmitted from left to right. 404 0 1 2 405 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 407 | Type | Length | String ... 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 410 Type 412 TBD 414 Length 416 >=3 418 String 420 The String field is one or more octets, containing the link layer 421 address that the user session last connected to. The actual format 422 of the information is site or application specific. A robust 423 implementation SHOULD support the field as undistinguished octets. 425 The codification of the range of allowed usage of this field is 426 outside the scope of this specification. 428 3.2. Table of Attributes 430 The following table provides a guide to which attributes may be found in 431 which kinds of packets, and in what quantity. If an attribute is not 432 mentioned in this table, then it is not permitted in Notify-Request, 433 Notify-Accept or Notify-Reject packets. 435 Notify Notify Notify 436 Request Accept Reject # Attribute 437 0-1 0-1 0 1 User-Name [Note 1] 438 0-1 0 0 4 NAS-IP-Address [Note 2] 439 1 0 0 6 Service-Type [Note 10,11] 440 0-1 0 0 7 Framed-Protocol [Note 10] 441 0-1 0-1 0 28 Idle-Timeout [Note 3] 442 0-1 0 0 30 Called-Station-Id [Note 4] 443 0-1 0 0 31 Calling-Station-Id [Note 1] 444 0-1 0 0 32 NAS-Identifier [Note 2] 445 0+ 0+ 0+ 33 Proxy-State 446 0 0-1 0 44 Acct-Session-Id [Note 7] 447 0 0 0-1 49 Acct-Terminate-Cause [Note 8] 448 0-1 0-1 0 50 Acct-Multi-Session-Id [Note 6] 449 1 1 1 55 Event-Timestamp [Note 9] 450 1 0 0 61 NAS-Port-Type [Note 10] 451 0-1 0 0 TBD Previous-Called-Station-Id [Note 5] 452 Notify Notify Notify 453 Request Accept Reject # Attribute 455 [Note 1] The User-Name attribute, if provided in the Notify-Request 456 MUST be echoed in the Notify-Accept, and subsequent Access-Request 457 packets. If the User-Name attribute is not provided, then it is 458 assumed that the identity is provided by the Calling-Station-Id field, 459 which MUST be present. 461 [Note 2] A Notify-Request MUST contain either a NAS-IP-Address or a 462 NAS-Identifier (or both). 464 [Note 3] Within a Notify-Request, the Idle-Timeout attribute provides 465 a suggested amount of time for which the NAS may reserve resources for 466 a potential handoff. If an Idle-Timeout attribute is included within 467 the Notify-Request, then if the NAS is unable to reserve resources 468 for this period of time, then it MUST include an Idle-Timeout attribute 469 in the Notify-Accept, if sent, specifying the time it is willing to 470 commit to. The RADIUS server should assume that the resources have 471 been released at time Event-Timestamp + Idle-Timeout. 473 [Note 4] Within a Notify-Request, the Called-Station-Id refers to the 474 NAS to which the Notify-Request is sent. If it this does not match 475 the actual value of the NAS Called-Station-Id, then a Notify-Reject 476 MUST be sent. 478 [Note 5] Within a Notify-Request, the Previous-Called-Station-Id refers 479 to the 480 NAS from which the handoff is expected to occur. If the handoff does 481 not occur from that NAS, then the NAS receiving the handoff MAY reject 482 access. In the case where NAS-Port-Type = 802.11, and the 483 Previous-Called-Station-Id contains an SSID, then if the handoff occurs, 484 the client MUST be granted access only to this SSID. If the 485 attempts to connect to another SSID, then the NAS MUST deny network 486 access to the client. If the SSID field is omitted, then a value of ANY 487 is assumed. 489 [Note 6] Within a Notify-Request, the Acct-Multi-Session-Id provides a 490 unique identifier for the client sessions during handoffs between 491 NASes. The Acct-Multi-Session-Id is echoed in subsequent Access-Request 492 and Accounting-Request packets. 494 [Note 7] The Acct-Session-Id, if present in Notify-Accept packets, 495 denotes 496 the accounting session id allocated by the NAS for the prospective 497 handoff, 498 should it occur. The Acct-Session-Id is echoed in subsequent 499 Access-Request 500 and Accounting-Request packets. 502 [Note 8] The Acct-Terminate-Cause is present only in Notify-Reject 503 packets, 504 and specifies the reason for the rejection. 506 [Note 9] When RADIUS is not protected by IPsec, the 507 Event-Timestamp attribute MUST be present in all packets in order to 508 prevent replay attacks. This is discussed in Section 4. 510 [Note 10] The Service-Type, NAS-Port-Type and Framed-Protocol 511 attributes are used to specify the services that are 512 to be provided to the handed off session. 513 The Service-Type and NAS-Port-Type attributes 514 MUST be present in the Notify-Request; when used with 802.11, 515 it is expected that a NAS-Port-Type=802.11 and a Service-Type=Handoff 516 will be included. The Service-Type is echoed in the subsequent 517 Access-Request. If the NAS is not able to provide 518 the specified service, then it MUST send a Notify-Reject. 520 [Note 11] The Service-Type value of Handoff, when used by the NAS in an 521 Access-Request packet, indicates that a handoff request is 522 being anticipated and that the RADIUS server should send back an 523 Access-Accept to allow the prospective handoff to occur, or an 524 Access-Reject to deny the prospective handoff. The decision is 525 typically based on the User-Name, Called-Station-Id or 526 Calling-Station-Id. As with a normal Access-Request, the 527 User-Name attribute is expected to be filled in. Note that the 528 service provided when Service-Type=Handof differs from 529 that provided when Service-Type=Call Check. 531 With Handoff, the NAS MUST authenticate the user during 532 the handoff prior to allowing access, using credentials provided 533 by the RADIUS server, whereas with a Service-Type=Call Check, 534 the authentication is implicit and access is permitted or denied 535 purely based on the Called-Station-Id or Calling-Station-Id. 537 The following table defines the meaning of the above table entries. 539 0 This attribute MUST NOT be present in packet. 540 0+ Zero or more instances of this attribute MAY be present in packet. 541 0-1 Zero or one instance of this attribute MAY be present in packet. 542 1 Exactly one instance of this attribute MUST be present in packet. 544 4. Security considerations 546 4.1. IPsec usage guidelines 548 Implementations of this specification SHOULD support IPsec [RFC2401] 549 along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with 550 non-null transform, and per-packet authentication, integrity and replay 551 protection SHOULD be used, along with IKE for key management. 553 Within RADIUS [RFC2865], a shared secret is used for hiding of 554 attributes such as User-Password, as well as in computation of the 555 Response Authenticator. In RADIUS accounting [RFC2866], the shared 556 secret is used in computation of both the Request Authenticator and the 557 Response Authenticator. 559 Since in RADIUS a shared secret is used to provide confidentiality as 560 well as integrity protection and authentication, only use of IPsec ESP 561 with a non-null transform can provide security services sufficient to 562 substitute for RADIUS application-layer security. Therefore, where 563 IPSEC AH or ESP null is used, it will typically still be necessary to 564 configure a RADIUS shared secret. 566 Where RADIUS is run over IPsec ESP with a non-null transform, the secret 567 shared between the NAS and the RADIUS server may not be configured. In 568 this case, a shared secret of zero length MUST be assumed. However, a 569 RADIUS server that cannot know whether incoming traffic is IPsec- 570 protected MUST be configured with a non-null RADIUS shared secret. When 571 IPsec ESP is used with RADIUS, DES-CBC SHOULD NOT be used as the 572 encryption transform, and per-packet authentication, integrity and 573 replay protection MUST be used. 575 A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate 576 IPsec, from me to any, destination port UDP 1812". This causes an IPsec 577 SA to be set up by the RADIUS client prior to sending RADIUS traffic to 578 any RADIUS server. If some RADIUS servers contacted by the client do not 579 support IPsec, then a more granular policy will be required. 581 For a client implementing this specification the policy would be "Accept 582 IPsec, from any to me, destination port UDP TBD". This causes the RADIUS 583 client to accept (but not require) use of IPsec. It may not be 584 appropriate to require IPsec for all RADIUS servers connecting to an 585 IPsec-enabled RADIUS client, since some RADIUS servers may not support 586 IPsec. 588 For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept 589 IPsec, from any to me, destination port 1812". This causes the RADIUS 590 server to accept (but not require) use of IPsec. It may not be 591 appropriate to require IPsec for all RADIUS clients connecting to an 592 IPsec-enabled RADIUS server, since some RADIUS clients may not support 593 IPsec. 595 For servers implementing this specification, the policy would be 596 "Initiate IPsec, from me to any, destination port UDP TBD". This causes 597 the RADIUS server to initiate IPsec when sending RADIUS extension 598 traffic to any RADIUS client. If some RADIUS clients contacted by the 599 server do not support IPsec, then a more granular policy will be 600 required. 602 Where IPsec is used for security, and no RADIUS shared secret is 603 configured, it is important that trust be demonstrated between the 604 RADIUS client and RADIUS server by some means. For example, before 605 enabling an IKE-authenticated host to act as a RADIUS client, the RADIUS 606 server should check whether the host is authorized to provide network 607 access. For example, the RADIUS server can be configured with the IP 608 addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for 609 certificate authentication) of RADIUS clients. 611 Alternatively, if a separate CA exists for RADIUS clients, then the 612 RADIUS server can configure this CA as a trusted root for use with 613 IPsec. However, unlike SSL/TLS, IKE does not permit certificate policies 614 to be set on a per-port basis, such a policy would need to apply to all 615 uses of IPsec on RADIUS clients and servers. Assuming that only 616 certificate authentication is supported in the deployment, a management 617 station initiating an IPsec-protected telnet session to the RADIUS 618 server would need to obtain a certificate chaining to the RADIUS client 619 CA. Issuing such a certificate might not be appropriate if the 620 management station was not authorized as a RADIUS client. 622 Where RADIUS clients may obtain their IP address dynamically (such as an 623 Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409] 624 SHOULD NOT be used, since this requires use of a group pre-shared key; 625 instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses 626 are statically assigned either Aggressive Mode or Main Mode MAY be used. 628 With certificate authentication, Main Mode SHOULD be used. 630 Care needs to be taken with IKE Phase 1 Identity Payload selection in 631 order to enable mapping of identities to pre-shared keys even with 632 Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity 633 Payloads are used and addresses are dynamically assigned, mapping of 634 identities to keys is not possible, so that group pre-shared keys are 635 still a practical necessity. As a result, the ID_FQDN identity payload 636 SHOULD be employed in situations where Aggressive mode is utilized along 637 with pre-shared keys and IP addresses are dynamically assigned. This 638 approach also has other advantages, since it allows the RADIUS server 639 and client to configure themselves based on the fully qualified domain 640 name of their peers. 642 Note that with IPsec, security services are negotiated at the 643 granularity of an IPsec SA, so that RADIUS exchanges requiring a set of 644 security services different from those negotiated with existing IPsec 645 SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also 646 advisable where quality of service considerations dictate different 647 handling RADIUS conversations. Attempting to apply different quality of 648 service to connections handled by the same IPsec SA can result in 649 reordering, and falling outside the replay window. For a discussion of 650 the issues, see [RFC2983]. 652 4.2. Replay protection 654 Since this specification utilizes the Request Authenticator field for 655 integrity protection and authentication, rather than as a nonce, no 656 liveness or protection against replay is provided by the RADIUS header. 658 Where IPsec is not used, in order to provide replay protection, the 659 Event-Timestamp (55) attribute, described in [RFC2869] MUST be included. 660 When this attribute is present, the RADIUS server MUST check that the 661 Event-Timestamp is current within an acceptable time window. This 662 implies the need for time synchronization within the network, which can 663 be achieved via a variety of mechanisms, including secure NTP, as 664 described in [NTPAuth]. A default time window of 300 seconds is 665 recommended. 667 5. IANA Considerations 669 This specification requires assignment a UDP port, in addition to RADIUS 670 Type codes for Notify-Request, Notify-Accept, and Notify-Reject. 671 Assignment of Attribute Type codes are also required for the following 672 attributes: Previous-Called-Station-Id. A new value is requested to be 673 allocated for the Service-Type attribute for Handoff. 675 6. Normative references 677 [RFC1305] Mills, D. L., "Network Time Protocol (version 3) 678 Specification, Implementation and Analysis, RFC 1305 679 March, 1992. 681 [RFC1321] Rivest, R., Dusse, S., "The MD5 Message-Digest 682 Algorithm", RFC 1321, April 1992. 684 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 685 Requirement Levels", RFC 2119, March, 1997. 687 [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., 688 "Remote Authentication Dial In User Service (RADIUS)", 689 RFC 2865, June 2000. 691 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 693 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS 694 Extensions", RFC 2869, June 2000. 696 [RFC3162] Aboba, B., Zorn, G., Mitton, D.,"RADIUS and IPv6", RFC 697 3162, August 2001. 699 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 700 Port based Network Access Control, IEEE Std 802.1X-2001, 701 June 2001. 703 [Congdon] Congdon, P., et al., "IEEE 802.1X RADIUS Usage 704 Guidelines", Internet draft (work in progress), draft- 705 congdon-radius-8021x-21.txt, January 2003. 707 [DynAuth] Chiba, M., et. al., "Dynamic Authorization Extensions to 708 Remote Authentication Dial-in User Service (RADIUS)", 709 Internet draft (work in progress), draft-chiba-radius- 710 dynamic-authorization-05.txt, August 2002. 712 7. Informative references 714 [Mishra] Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K., 715 "Experimental Neighbor Graph Creation and Maintenance", 716 Internet draft (work in progress), draft-irtf-aaaarch- 717 neighbor-graph-00.txt. 719 [RFC2104] Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed- 720 Hashing for Message Authentication", RFC 2104, February 721 1997 723 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 724 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 725 October 1998. 727 [RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy 728 Implementation in Roaming", RFC 2607, June 1999. 730 [RFC2716] Aboba, B., Simon, D., "PPP EAP TLS Authentication 731 Protocol", RFC 2716, October 1999. 733 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 734 Overview and Architecture, ANSI/IEEE Std 802, 1990. 736 [IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: 737 Draft Standard for Virtual Bridged Local Area Networks, 738 P802.1Q, January 1998. 740 [IEEE-02-758] Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K., 741 "Proactive Caching Strategies for IAPP Latency 742 Improvement during 802.11 Handoff", IEEE 802.11 Working 743 Group, IEEE-02-758r1-F, November 2002. 745 [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I., Jang, K., 746 "Proactive Key Distribution to support fast and secure 747 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 749 http://www.ieee802.org/11/Documents/DocumentHolder/3-084.zip, 750 January 2003. 752 [8021XHandoff] Pack, S., Choi, Y., "Pre-Authenticated Fast Handoff in a 753 Public Wireless LAN Based on IEEE 802.1X Model", School 754 of Computer Science and Engineering, Seoul National 755 University, Seoul, Korea, 2002. 757 [IEEE8023] ISO/IEC 8802-3 Information technology - 758 Telecommunications and information exchange between 759 systems - Local and metropolitan area networks - Common 760 specifications - Part 3: Carrier Sense Multiple Access 761 with Collision Detection (CSMA/CD) Access Method and 762 Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 763 1996), 1996. 765 [IEEE80211] Information technology - Telecommunications and 766 information exchange between systems - Local and 767 metropolitan area networks - Specific Requirements Part 768 11: Wireless LAN Medium Access Control (MAC) and 769 Physical Layer (PHY) Specifications, IEEE Std. 770 802.11-1999, 1999. 772 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack." 773 CryptoBytes Vol.2 No.2, Summer 1996. 775 [NTPAuth] Mills, D., "Public Key Cryptography for the Network Time 776 Protocol", Internet draft (work in progress), draft-ietf- 777 stime-ntpauth-05.txt, November 2002. 779 Acknowledgments 781 The authors would like to acknowledge the following people for 782 contributions on this document: Tim Moore (Microsoft), Min-ho Shin 783 (University of Maryland), Nick Petroni (University of Maryland), Adam 784 Sulmicki (University of Maryland), Insun Lee (Samsung Electronics), 785 Kyunghun Jang (Samsung Electronics). 787 Authors' Addresses 789 William A. Arbaugh 790 Department of Computer Science 791 University of Maryland, College Park 792 A.V. Williams Building 793 College Park, MD 20742 795 EMail: waa@cs.umd.edu 796 Phone: +1 301 405 2774 798 Intellectual Property Statement 800 The IETF takes no position regarding the validity or scope of any 801 intellectual property or other rights that might be claimed to pertain 802 to the implementation or use of the technology described in this 803 document or the extent to which any license under such rights might or 804 might not be available; neither does it represent that it has made any 805 effort to identify any such rights. Information on the IETF's 806 procedures with respect to rights in standards-track and standards- 807 related documentation can be found in BCP-11. Copies of claims of 808 rights made available for publication and any assurances of licenses to 809 be made available, or the result of an attempt made to obtain a general 810 license or permission for the use of such proprietary rights by 811 implementors or users of this specification can be obtained from the 812 IETF Secretariat. 814 The IETF invites any interested party to bring to its attention any 815 copyrights, patents or patent applications, or other proprietary rights 816 which may cover technology that may be required to practice this 817 standard. Please address the information to the IETF Executive 818 Director. 820 Full Copyright Statement 822 Copyright (C) The Internet Society (2003). All Rights Reserved. 823 This document and translations of it may be copied and furnished to 824 others, and derivative works that comment on or otherwise explain it or 825 assist in its implementation may be prepared, copied, published and 826 distributed, in whole or in part, without restriction of any kind, 827 provided that the above copyright notice and this paragraph are included 828 on all such copies and derivative works. However, this document itself 829 may not be modified in any way, such as by removing the copyright notice 830 or references to the Internet Society or other Internet organizations, 831 except as needed for the purpose of developing Internet standards in 832 which case the procedures for copyrights defined in the Internet 833 Standards process must be followed, or as required to translate it into 834 languages other than English. The limited permissions granted above are 835 perpetual and will not be revoked by the Internet Society or its 836 successors or assigns. This document and the information contained 837 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 838 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 839 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 840 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 841 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 842 Expiration Date 844 This memo is filed as , and expires 845 August 22, 2003.