idnits 2.17.1 draft-irtf-aaaarch-handoff-02.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 21 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 22 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 578 has weird spacing: '...t realm are t...' == Line 713 has weird spacing: '...e might not b...' == Line 947 has weird spacing: '...imed to perta...' == Line 991 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 (20 May 2003) is 7637 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Chiba' is mentioned on line 528, but not defined == Missing Reference: 'Note 1' is mentioned on line 469, but not defined == Missing Reference: 'Note 2' is mentioned on line 473, but not defined == Missing Reference: 'Note 5' is mentioned on line 494, but not defined == Missing Reference: 'Note 10' is mentioned on line 516, but not defined -- Looks like a reference, but probably isn't: '11' on line 450 == Missing Reference: 'Note 12' is mentioned on line 536, but not defined == Missing Reference: 'Note 3' is mentioned on line 476, but not defined == Missing Reference: 'Note 4' is mentioned on line 485, but not defined == Missing Reference: 'Note 7' is mentioned on line 503, but not defined == Missing Reference: 'Note 6' is mentioned on line 498, but not defined == Missing Reference: 'Note 9' is mentioned on line 512, but not defined == Missing Reference: 'Note 8' is mentioned on line 508, but not defined == Missing Reference: 'Note 11' is mentioned on line 526, but not defined == Missing Reference: 'RFC2486' is mentioned on line 576, but not defined ** Obsolete undefined reference: RFC 2486 (Obsoleted by RFC 4282) == Missing Reference: 'RFC2401' is mentioned on line 624, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'RFC2409' is mentioned on line 717, but not defined ** Obsolete undefined reference: RFC 2409 (Obsoleted by RFC 4306) == Missing Reference: 'RFC2406' is mentioned on line 625, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'RFC3280' is mentioned on line 698, but not defined ** Obsolete undefined reference: RFC 3280 (Obsoleted by RFC 5280) == Missing Reference: 'NTPAUTH' is mentioned on line 758, but not defined == Unused Reference: 'RFC1305' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'RFC3162' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'IEEE8021X' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'RFC2607' is defined on line 846, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'IEEE8021Q' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'IEEE8023' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'NASREQ' is defined on line 908, but no explicit reference was found in the text == Unused Reference: 'NTPAuth' is defined on line 912, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) -- 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) == Outdated reference: A later version (-17) exists of draft-ietf-aaa-diameter-nasreq-11 -- 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: 9 errors (**), 0 flaws (~~), 39 warnings (==), 8 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 Bernard Aboba 5 Microsoft 6 20 May 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 that enables an accounting server to notify a NAS 37 of a prospective handoff. This enables the NAS to reserve resources and 38 obtain the session parameters prior to arrival of the client, 39 potentially reducing handoff times. The extension described in this 40 document may potentially be useful in enabling handoffs across access 41 technologies and providers. However, whether the approach described in 42 this document is effective, deployable or secure is the subject of 43 current research. It is offered for RADIUS primarily because source 44 code for RADIUS client and server implementations is readily available 45 for research purposes. Given that this extension represents research 46 work in progress, implementation of this specification for purposes 47 other than research is not recommended. 49 Table of Contents 51 1. Introduction .......................................... 3 52 1.1 Terminology ..................................... 5 53 1.2 Requirements language ........................... 5 54 2. Packet format ......................................... 6 55 2.1 Notify-Request .................................. 8 56 2.2 Notify-Accept ................................... 9 57 2.3 Notify-Reject ................................... 10 58 3. Table of Attributes ................................... 10 59 4. Security considerations ............................... 13 60 4.1 Authorization issues ............................ 13 61 4.2 Impersonation ................................... 13 62 4.3 IPsec usage guidelines .......................... 14 63 4.4 Replay protection ............................... 17 64 4.5 Spoofing and hijacking .......................... 17 65 5. IANA considerations ................................... 18 66 6. Normative references .................................. 18 67 7. Informative references ................................ 19 68 ACKNOWLEDGMENTS .............................................. 20 69 AUTHORS' ADDRESSES ........................................... 21 70 Intellectual Property Statement .............................. 21 71 Full Copyright Statement ..................................... 22 72 1. Introduction 74 In wireless networks such as IEEE 802.11, described in [IEEE80211], it 75 may be desirable to improve the speed at which handoff can be completed. 76 Where RADIUS Accounting [RFC2866] is implemented, RADIUS Accounting 77 packets will be generated each time the client connects to a NAS. 78 Accounting packets from a single session, across multiple NASes, are 79 uniquely identified by the Acct-Multi-Session-Id Attribute, described in 80 [RFC2866] and [Congdon]. 82 The sequence of NASes contacted by clients as they move creates a graph 83 representing the mobility paths of the clients. We call this graph a 84 neighbor graph with NASes as the vertices and the mobility paths between 85 the NASes as the edges. Thus, the number of neighbors for a given NAS 86 is given by the degree function applied to the vertex representing the 87 given NAS, e.g. for NAS_A the number of neighbors would be given by 88 deg(v_A) where deg is the degree function deg: V -> int. Through 89 knowledge of the neighbor graph, it is possible for a RADIUS server to 90 anticipate client movements and provide advance notice of a potential 91 handoff to the NAS. This advance notice, known as a Notify-Request in 92 this specification, allows the NAS to reserve resources and obtain the 93 session authorization parameters prior to arrival of the client. This 94 removes the latency of the RADIUS exchange from the critical path for 95 processing a handoff, decreasing handoff latency substantially, as 96 described in [IEEE-02-758, IEEE-03-084]. Assuming that the coverage 97 area is overlapping, this technique can support handoffs at vehicular 98 velocities. The creation and maintenance of neighbor graphs at an 99 authentication server is described in [Mishra]. An alternate approach 100 to using neighbor graphs uses a matrix of probabilities and is described 101 in [8021XHandoff]. 103 By nature, client behavior is not completely predictable, so that the 104 handoff advance notice is only advisory. The client identified in the 105 advance notice may never contact the NAS, or may contact it long after 106 the initial notice is received. As a result, the NAS will typically 107 free reserved resources after a suitable waiting period, known as the 108 Reservation-Lifetime. In situations where resources are at a premium, 109 it may be desirable to minimize resources reserved for clients that are 110 no longer likely to attempt to connect to a given NAS. To accomplish 111 this, the reservation period can be shortened, or alternatively, the 112 RADIUS server can remove resource reservations using the Disconnect- 113 Request, specified in [DynAuth]. A client contacting the NAS after the 114 Reservation-Lifetime has expired or a resource reservation has been 115 removed will be unable to complete a handoff, and will need to do a fast 116 resume, such as is supported in EAP TLS [RFC2716]. 118 The extension described in this document enables a RADIUS Server to send 119 Notify-Requests to NASes, and to receive Notify-Responses. The Notify- 120 Request identifies the session to be handed off and the NAS on which it 121 currently resides. Attributes included within the Notify-Request are 122 described in Section 2.1. 124 If the NAS has resources available to reserve, and if it is enabled to 125 support this handoff extension, then it will respond with a Notify- 126 Accept. If resources are not available (such as when previous resource 127 commitments leave insufficient resources remaining), or if the NAS does 128 not wish to support the prospective handoff for any other reason, the 129 NAS will respond with a Notify-Reject, specifying the reason why the 130 requested handoff reservation could not be carried out, using the Error- 131 Cause Attribute, specified in [DynAuth]. 133 After the NAS responds with a Notify-Accept, it will typically issue an 134 Access-Request to the RADIUS server. This allows the NAS to obtain the 135 authorizations for the session before it is contacted by the client. 136 The contents of the Access-Request sent by the NAS will depend on the 137 form of access it is providing, so that it cannot be specified in detail 138 here. However, for use with IEEE 802.11, it is expected that an Access- 139 Request will be sent with a NAS-Port-Type Attribute with value "802.11" 140 and a Service-Type Attribute with value "Authorize Only", as defined in 141 [Chiba]. For other access methods, a different NAS-Port-Type value might 142 be sent, perhaps with a different value for Service-Type. 144 Since the extension defined in this document supports multiple access 145 methods and service types, and leverages the conventional RADIUS Access- 146 Request/Response exchange, it can be used to enable handoffs between any 147 access technology compatible with RADIUS. For example, using this 148 extension, it is possible to enable a handoff between 802.11 and 149 cellular technologies such as GPRS or CDMA 1X-RTT. When this extension 150 is used to enable handoff between heterogeneous technologies, the 151 "correctness" issues described in [Context] do not arise, since the 152 RADIUS server provides the authorizations appropriate for each NAS and 153 access mechanism. 155 This extension can also enable handoffs between providers that do not 156 establish mutual trust, as would be required when using a context 157 transfer approach, such as [IEEE80211f]. All that is necessary is that 158 each NAS be able to reach the home RADIUS server through an appropriate 159 path. Of course, where handoffs occur across different providers and 160 access media, it is unlikely that session continuity can be preserved, 161 since the client will be likely to change its IP address. 163 1.1. Terminology 165 This document uses the following terms: 167 Authenticator 168 An Authenticator is an entity that require authentication from 169 the Supplicant. The Authenticator may be connected to the 170 Supplicant at the other end of a point-to-point LAN segment or 171 802.11 wireless link. 173 authentication server 174 An authentication server is an entity that provides an 175 Authentication Service to an Authenticator. This service 176 verifies from the credentials provided by the Supplicant, the 177 claim of identity made by the Supplicant. 179 Network Access Server (NAS) 180 The device providing access to the network. 182 Service The NAS provides a service to the user, such as IEEE 802 or 183 PPP. 185 Port Access Entity (PAE) 186 The protocol entity associated with a physical or virtual 187 (802.11) Port. A given PAE may support the protocol 188 functionality associated with the Authenticator, Supplicant or 189 both. 191 Session Each service provided by the NAS to a user constitutes a 192 session, with the beginning of the session defined as the 193 point where service is first provided and the end of the 194 session defined as the point where service is ended. A user 195 may have multiple sessions in parallel or series if the NAS 196 supports that, with each session generating a separate start 197 and stop accounting record. Where the client is mobile and is 198 able to handoff between NASes, multiple related sessions may 199 be uniquely identified by the Acct-Multi-Session-Id Attribute. 201 Supplicant 202 A Supplicant is an entity that is being authenticated by an 203 Authenticator. The Supplicant may be connected to the 204 Authenticator at one end of a point-to-point LAN segment or 205 802.11 wireless link. 207 1.2. Requirements language 209 In this document, several words are used to signify the requirements of 210 the specification. These words are often capitalized. The key words 211 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 212 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 213 interpreted as described in [RFC2119]. 215 2. Packet format 217 Exactly one Notify-Request, Notify-Accept or Notify-Reject packet is 218 encapsulated in the UDP Data field. For the Notify-Request packet, the 219 UDP Destination Port field is TBD. When a reply is generated, the 220 source and destination ports are reversed. 222 A summary of the data format is shown below. The fields are transmitted 223 from left to right. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Code | Identifier | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 | Authenticator | 232 | | 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Attributes ... 236 +-+-+-+-+-+-+-+-+-+-+-+-+- 238 Code 240 The Code field is one octet, and identifies the type of RADIUS 241 packet. When a packet is received with an invalid Code field, it is 242 silently discarded. RADIUS codes (decimal) for this extension are 243 assigned as follows: 245 TBD - Notify-Request 246 TBD - Notify-Accept 247 TBD - Notify-Reject 249 Identifier 251 The Identifier field is one octet, and aids in matching requests and 252 replies. The RADIUS server can detect a duplicate request if it has 253 the same client source IP address and source UDP port and Identifier 254 within a short span of time. 256 Length 258 The Length field is two octets. It indicates the length of the 259 packet including the Code, Identifier, Length, Authenticator and 260 Attribute fields. Octets outside the range of the Length field MUST 261 be treated as padding and ignored on reception. If the packet is 262 shorter than the Length field indicates, it MUST be silently 263 discarded. The minimum length is 20 and maximum length is 4096. 265 Authenticator 267 The Authenticator field is sixteen (16) octets. The most significant 268 octet is transmitted first. This value is used to authenticate the 269 messages between the client and RADIUS server. 271 Request Authenticator 273 In Notify-Request Packets, the Authenticator value is a 16 octet MD5 274 [RFC1321] checksum, called the Request Authenticator. The Request 275 Authenticator is calculated the same way as for an Accounting- 276 Request, specified in [RFC2866]. 278 Note that the Request Authenticator of an Notify-Request can not be 279 done the same way as the Request Authenticator of a RADIUS Access- 280 Request, because there is no User-Password Attribute in an Notify- 281 Request. 283 Response Authenticator 285 The Authenticator field in a Notify-Accept or Notify-Reject packet is 286 called the Response Authenticator, and contains a one-way MD5 hash 287 calculated over a stream of octets consisting of the Notify-Response 288 Code, Identifier, Length, the Request Authenticator field from the 289 Notify-Request packet being replied to, and the response Attributes 290 if any, followed by the shared secret. The resulting 16 octet MD5 291 hash value is stored in the Authenticator field of the Notify-Accept 292 or Notify-Reject packet. 294 Attributes 296 In Notify-Request messages, all Attributes are treated as mandatory. 297 A NAS MUST respond to a Notify-Request containing one or more 298 unsupported Attributes with a Notify-Reject. A Notify-Reject MUST NOT 299 result in resources being reserved on the NAS. Attributes beyond 300 those specified in Section 3 SHOULD NOT be included within Notify- 301 Request messages, since this could produce unpredictable results. 303 When using a forwarding proxy, the proxy must be able to alter the 304 packet as it passes through in each direction. When the proxy 305 forwards a Notify-Request, it MAY add a Proxy-State Attribute, and 306 when the proxy forwards a response, it MUST remove its Proxy-State 307 Attribute if it added one. Proxy-State is always added or removed 308 after any other Proxy-States, but no other assumptions regarding its 309 location within the list of Attributes can be made. Since Notify 310 responses are authenticated on the entire packet contents, the 311 stripping of the Proxy-State Attribute invalidates the integrity 312 check - so the proxy needs to recompute it. A forwarding proxy MUST 313 NOT modify existing Proxy-State, State, or Class Attributes present 314 in the packet. 316 If there are any Proxy-State Attributes in a Notify-Request received 317 from the server, the forwarding proxy MUST include those Proxy-State 318 Attributes in its response to the server. The forwarding proxy MAY 319 include the Proxy-State Attributes in the Notify-Request when it 320 forwards the request, or it MAY omit them in the forwarded request. 321 If the forwarding proxy omits the Proxy-State Attributes in the 322 request, it MUST attach them to the response before sending it to the 323 server. 325 2.1. Notify-Request 327 Description 329 A Notify-Request packet is sent by the RADIUS server to the NAS to 330 notify it of the potential handoff of a specified session. 332 Code 334 TBD - Notify-Request 336 Identifier 338 The Identifier field MUST be changed whenever the content of the 339 Attributes field changes, and whenever a valid reply has been 340 received for a previous request. For retransmissions where the 341 contents are identical, the Identifier MUST remain unchanged. 343 Note that if the Event-Timestamp Attribute is included the Notify- 344 Request then the Event-Timestamp value will be updated when the 345 packet is retransmitted, changing the content of the Attributes field 346 and requiring a new Identifier and Request Authenticator. 348 Request Authenticator 350 The Request Authenticator of an Accounting-Request contains a 351 16-octet MD5 hash value calculated according to the method described 352 in "Request Authenticator" in Section 2. 354 Attributes 355 The Attribute field is variable in length, and contains a list of 356 Attributes. In Notify-Request packets, certain Attributes are used 357 to uniquely identify the NAS as well as a potential user session on 358 the NAS, and to describe the services to be provided. All NAS 359 identification Attributes included in a Notify-Request message MUST 360 match in order for a Notify-Accept to be sent; otherwise a Notify- 361 Reject MUST be sent. 362 To address security concerns described in Section 4.1, the User-Name 363 Attributes MUST be present in Notify-Request packets. To address 364 security concerns described in Section 4.2, the NAS-IP-Address and/or 365 NAS-IPv6-Address Attributes SHOULD be present in Notify-Request 366 packets; the NAS-Identifier Attribute MAY be present in addition. 367 Details of the Attributes which may be included in Notify-Request 368 packets are provided in Section 3. 370 2.2. Notify-Accept 372 Description 374 The NAS responds to the Notify-Request with a Notify-Accept if the 375 NAS agrees to to prepare for a handoff of the specified session. 377 Code 379 TBD - Notify-Accept 381 Identifier 383 The Identifier field is a copy of the Identifier field of the Notify- 384 Request which caused this Notify-Accept. 386 Response Authenticator 388 The Response Authenticator of a Notify-Accept contains a 16-octet MD5 389 hash value calculated according to the method described in "Response 390 Authenticator" in Section 2. 392 Attributes 394 The Attribute field is variable in length, and contains a list of 395 Attributes. Within the Notify-Accept, Attributes are used to provide 396 the RADIUS server with the session identifiers that will be used by 397 the NAS in subsequent Access-Request and Accounting-Request packets. 398 This includes session identification Attributes, such as the User- 399 Name and Acct-Multi-Session-Id Attributes provided by the RADIUS 400 server in the Notify-Request, as well as an Acct-Session-Id allocated 401 by the NAS for the handoff, should it occur. The Idle-Timeout 402 Attribute, when included in the Notify-Accept, provides the RADIUS 403 server with the time that the NAS is willing to reserve resources for 404 the handoff. Section 3 provides more detail on the Attributes 405 permitted within the Notify-Accept packet. 407 2.3. Notify-Reject 409 Description 411 The NAS responds to the Notify-Request with a Notify-Reject if the 412 NAS does not have the resources to make the required handoff 413 preparations, or wishes to decline for any other reason. 415 Code 417 TBD - Notify-Reject 419 Identifier 421 The Identifier field is a copy of the Identifier field of the Notify- 422 Request which caused this Notify-Reject. 424 Response Authenticator 426 The Response Authenticator of a Notify-Accept contains a 16-octet MD5 427 hash value calculated according to the method described in "Response 428 Authenticator" in Section 2. 430 Attributes 432 The Attribute field is variable in length, and contains a list of 433 Attributes. Within the Notify-Reject, the Error-Cause Attribute 434 provides the RADIUS server with the reason why the Notify-Request 435 could not be honored. Values of the Error-Cause Attribute, and their 436 corresponding meanings are described in [DynAuth], Section 3.1. 438 3. Table of Attributes 440 The following table provides a guide to which Attributes may be found in 441 which kinds of packets, and in what quantity. If an Attribute is not 442 mentioned in this table, then it SHOULD NOT be included in Notify- 443 Request, Notify-Accept or Notify-Reject packets. 445 Notify Notify Notify 446 Request Accept Reject # Attribute 447 1 1 0 1 User-Name [Note 1] 448 0-1 0 0 4 NAS-IP-Address [Note 2] 449 0-1 0 0 5 NAS-Port [Note 5] 450 1 0 0 6 Service-Type [Note 10,11] 451 0-1 0 0 7 Framed-Protocol [Note 10] 452 0-1 0-1 0-1 24 State [Note 12] 453 0-1 0-1 0 28 Idle-Timeout [Note 3] 454 0-1 0 0 30 Called-Station-Id [Note 4] 455 0-1 0 0 31 Calling-Station-Id [Note 1] 456 0-1 0 0 32 NAS-Identifier [Note 2] 457 0+ 0+ 0+ 33 Proxy-State 458 0 0-1 0 44 Acct-Session-Id [Note 7] 459 0-1 0-1 0 50 Acct-Multi-Session-Id [Note 6] 460 0-1 0-1 0-1 55 Event-Timestamp [Note 9] 461 1 0 0 61 NAS-Port-Type [Note 10] 462 0-1 0 0 87 NAS-Port-Id [Note 5] 463 0-1 0 0 94 Originating-Line-Info [Note 5] 464 0-1 0 0 95 NAS-IPv6-Address [Note 2] 465 0 0 0-1 TBD Error-Cause [Note 8] 466 Notify Notify Notify 467 Request Accept Reject # Attribute 469 [Note 1] The User-Name Attribute MUST be provided in the Notify-Request 470 and MUST be echoed in the Notify-Accept, and subsequent Access-Request 471 packets. 473 [Note 2] A Notify-Request MUST contain a NAS-IP-Address, NAS- 474 IPv6-Address or NAS-Identifier Attribute (or some combination of these). 476 [Note 3] Within a Notify-Request, the Idle-Timeout Attribute provides a 477 suggested amount of time for which the NAS may reserve resources for a 478 potential handoff. If an Idle-Timeout Attribute is included within the 479 Notify-Request, then if the NAS is unable to reserve resources for this 480 period of time, then it MUST include an Idle-Timeout Attribute in the 481 Notify-Accept, if sent, specifying the time it is willing to commit to. 482 The RADIUS server should assume that the resources have been released at 483 time Event-Timestamp + Idle-Timeout. 485 [Note 4] Within a Notify-Request, Called-Station-Id refers to the NAS 486 from which the handoff is expected to occur. If the handoff does not 487 occur from that NAS referred to in Called-Station-Id, then the NAS MAY 488 refuse the handoff. In the case where NAS-Port-Type = 802.11, and the 489 Called-Station-Id contains an SSID, then if the handoff occurs, the 490 client MUST be granted access only to this SSID. If the attempts to 491 connect to another SSID, then the NAS MUST deny network access to the 492 client. If the SSID field is omitted, then a value of ANY is assumed. 494 [Note 5] The NAS-Port and NAS-Port-Id Attributes, if present, refer to 495 the NAS port from which the handoff is expected to occur. Originating- 496 Line-Info provides information on how the session originated. 498 [Note 6] Within a Notify-Request, the Acct-Multi-Session-Id provides a 499 unique identifier for user sessions during handoffs between NASes. The 500 Acct-Multi-Session-Id is echoed in subsequent Access-Request and 501 Accounting-Request packets. 503 [Note 7] The Acct-Session-Id, if present in Notify-Accept packets, 504 denotes the accounting session id allocated by the NAS for the 505 prospective handoff, should it occur. The Acct-Session-Id is echoed in 506 subsequent Access-Request and Accounting-Request packets. 508 [Note 8] The Error-Cause Attribute is present only in Notify-Reject 509 packets, and specifies the reason for the rejection. It is defined in 510 [DynAuth], Section 3.1. 512 [Note 9] When IPsec replay protection is not used, the Event-Timestamp 513 Attribute MUST be present in all packets in order to prevent replay 514 attacks. This is discussed in Section 4. 516 [Note 10] The Service-Type, NAS-Port-Type, and Framed-Protocol 517 Attributes are used to specify the services that are to be provided to 518 the handed off session. The Service-Type and NAS-Port-Type Attributes 519 MUST be present in the Notify-Request; when used with 802.11, it is 520 expected that a NAS-Port-Type Attribute with value "802.11" and a 521 Service-Type Attribute with a value of "Authorize Only" will be 522 included. The Service-Type is echoed in the subsequent Access-Request. 523 If the NAS is not able to provide the specified service, then it MUST 524 send a Notify-Reject. 526 [Note 11] The Service-Type Attribute is included with a value of 527 "Authorize Only" within a RADIUS Access-Request in order to indicate 528 that only authorization is being requested, as defined in [Chiba]. 529 Where used in concert with this specification, such an Access-Request 530 indicates that a handoff request is being anticipated and that the 531 RADIUS server should send back an Access-Accept to allow the prospective 532 handoff to occur, or an Access-Reject to deny the prospective handoff. 533 The decision is typically based on the User-Name, Called-Station-Id, 534 Calling-Station-Id, and State attributes. 536 [Note 12] The State Attribute is available to be sent by the RADIUS 537 server to the NAS in a Notify-Request message and MUST be sent 538 unmodified from the NAS to the RADIUS server in subsequent Notify- 539 Accept, Notify-Reject or Access-Request messages. The NAS MUST NOT 540 interpret the State Attribute locally. A Notify-Request, Notify-Accept 541 or Notify-Reject packet must have only zero or one State Attribute. 543 Usage of the State Attribute is implementation dependent. If the RADIUS 544 server does not recognize the State Attribute in the Access-Request, 545 then it MUST send an Access-Reject. 547 The following table defines the meaning of the above table entries. 549 0 This Attribute MUST NOT be present in packet. 550 0+ Zero or more instances of this Attribute MAY be present in packet. 551 0-1 Zero or one instance of this Attribute MAY be present in packet. 552 1 Exactly one instance of this Attribute MUST be present in packet. 554 4. Security considerations 556 4.1. Authorization issues 558 Where a NAS is shared by multiple providers, it is undesirable for one 559 provider to be able to send Notify-Requests relating to sessions of 560 another provider. 562 To prevent this, the RADIUS proxy SHOULD perform a "reverse path 563 forwarding" (RPF) check to verify that a Notify-Request is originating 564 from an authorized RADIUS server. In a network model where a proxy is 565 employed to forward Notify-Request messages, the NAS MUST accept these 566 messages only from proxies that it is configured to trust. Requests 567 from untrusted sources MUST be silently discarded. 569 To perform the RPF check, the proxy uses the session identification 570 Attributes included in Notify-Request messages, in order to determine 571 the RADIUS server(s) to which an equivalent Access-Request would be 572 routed. If this matches the source address of the Notify-Request, then 573 the Request is forwarded; otherwise it SHOULD be silently discarded. 575 Typically the proxy will extract the realm from the Network Access 576 Identifier [RFC2486] included within the User-Name Attribute, and 577 determine the corresponding RADIUS servers in the proxy routing tables. 578 The RADIUS servers for that realm are then compared against the source 579 address of the packet. Where no RADIUS proxy is present, the RPF check 580 will need to be performed by the NAS itself. 582 Since authorization to send a Notify-Request is determined based on the 583 source address and the corresponding shared secret, the NASes or proxies 584 SHOULD configure a different shared secret for each RADIUS server. 586 4.2. Impersonation 588 [RFC2865] Section 3 states: 590 A RADIUS server MUST use the source IP address of the RADIUS 591 UDP packet to decide which shared secret to use, so that 592 RADIUS requests can be proxied. 594 When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or 595 NAS-IPv6-Address Attributes will typically not match the source address 596 observed by the RADIUS server. Since the NAS-Identifier Attribute need 597 not contain an FQDN, this Attribute may not be resolvable to the source 598 address observed by the RADIUS server, even when no proxy is present. 600 As a result, the authenticity check performed by a RADIUS server or 601 proxy does not verify the correctness of NAS identification Attributes. 602 This makes it possible for a rogue NAS to forge NAS-IP-Address, NAS- 603 IPv6-Address or NAS-Identifier Attributes within a RADIUS Access-Request 604 in order to impersonate another NAS. It is also possible for a rogue 605 NAS to forge session identification Attributes such as the Called- 606 Station-Id, Calling-Station-Id, or Originating-Line-Info. This could 607 fool the RADIUS server into sending Notify-Request messages containing 608 forged session identification Attributes to a NAS targeted by an 609 attacker. 611 To address these vulnerabilities RADIUS proxies SHOULD check whether NAS 612 identification Attributes match the source address of packets 613 originating from the NAS. Where one or more Attributes do not match, 614 Notify-Request messages SHOULD be silently discarded. 616 Such a check may not always be possible. Since the NAS-Identifier 617 Attribute need not correspond to an FQDN, it may not be resolvable to an 618 IP address to be matched against the source address. Also, where a NAT 619 exists between the RADIUS client and proxy, checking the NAS-IP-Address 620 or NAS-IPv6-Address Attributes may not be feasible. 622 4.3. IPsec usage guidelines 624 Implementations of this specification SHOULD support IPsec [RFC2401] 625 along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with 626 non-null transform SHOULD be supported, and IPsec ESP with a non-null 627 encryption transform and authentication support SHOULD be used to 628 provide per-packet confidentiality, authentication, integrity and replay 629 protection. IKE SHOULD be used for key management. 631 Within RADIUS [RFC2865], a shared secret is used for hiding of 632 Attributes such as User-Password, as well as in computation of the 633 Response Authenticator. In RADIUS accounting [RFC2866], the shared 634 secret is used in computation of both the Request Authenticator and the 635 Response Authenticator. 637 Since in RADIUS a shared secret is used to provide confidentiality as 638 well as integrity protection and authentication, only use of IPsec ESP 639 with a non-null transform can provide security services sufficient to 640 substitute for RADIUS application-layer security. Therefore, where 641 IPsec AH or ESP null is used, it will typically still be necessary to 642 configure a RADIUS shared secret. 644 Where RADIUS is run over IPsec ESP with a non-null transform, the secret 645 shared between the NAS and the RADIUS server MAY NOT be configured. In 646 this case, a shared secret of zero length MUST be assumed. However, a 647 RADIUS server that cannot know whether incoming traffic is IPsec- 648 protected MUST be configured with a non-null RADIUS shared secret. 650 When IPsec ESP is used with RADIUS, per-packet authentication, integrity 651 and replay protection MUST be used. 3DES-CBC MUST be supported as an 652 encryption transform and AES-CBC SHOULD be supported. AES-CBC SHOULD be 653 offered as a preferred encryption transform if supported. HMAC-SHA1-96 654 MUST be supported as an authentication transform. DES-CBC SHOULD NOT be 655 used as the encryption transform. 657 A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate 658 IPsec, from me to any destination port UDP 1812". This causes an IPsec 659 SA to be set up by the RADIUS client prior to sending RADIUS traffic. 660 If some RADIUS servers contacted by the client do not support IPsec, 661 then a more granular policy will be required: "Initiate IPsec, from me 662 to IPsec-Capable-RADIUS-Server, destination port UDP 1812". 664 For a client implementing this specification the policy would be "Accept 665 IPsec, from any to me, destination port UDP TBD". This causes the 666 RADIUS client to accept (but not require) use of IPsec. It may not be 667 appropriate to require IPsec for all RADIUS servers connecting to an 668 IPsec-enabled RADIUS client, since some RADIUS servers may not support 669 IPsec. 671 For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept 672 IPsec, from any to me, destination port 1812". This causes the RADIUS 673 server to accept (but not require) use of IPsec. It may not be 674 appropriate to require IPsec for all RADIUS clients connecting to an 675 IPsec-enabled RADIUS server, since some RADIUS clients may not support 676 IPsec. 678 For servers implementing this specification, the policy would be 679 "Initiate IPsec, from me to any, destination port UDP TBD". This causes 680 the RADIUS server to initiate IPsec when sending RADIUS extension 681 traffic to any RADIUS client. If some RADIUS clients contacted by the 682 server do not support IPsec, then a more granular policy will be 683 required, such as "Initiate IPsec, from me to IPsec-capable-RADIUS- 684 client, destination port UDP TBD". 686 Where IPsec is used for security, and no RADIUS shared secret is 687 configured, it is important that the RADIUS client and server perform an 688 authorization check. Before enabling a host to act as a RADIUS client, 689 the RADIUS server SHOULD check whether the host is authorized to provide 690 network access. Similarly, before enabling a host to act as a RADIUS 691 server, the RADIUS client SHOULD check whether the host is authorized 692 for that role. 694 RADIUS servers can be configured with the IP addresses (for IKE 695 Aggressive Mode with pre-shared keys) or FQDNs (for certificate 696 authentication) of RADIUS clients. Alternatively, if a separate 697 Certification Authority (CA) exists for RADIUS clients, then the RADIUS 698 server can configure this CA as a trust anchor [RFC3280] for use with 699 IPsec. 701 Similarly, RADIUS clients can be configured with the IP addresses (for 702 IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate 703 authentication) of RADIUS servers. Alternatively, if a separate CA 704 exists for RADIUS servers, then the RADIUS client can configure this CA 705 as a trust anchor for use with IPsec. 707 Since unlike SSL/TLS, IKE does not permit certificate policies to be set 708 on a per-port basis, certificate policies need to apply to all uses of 709 IPsec on RADIUS clients and servers. In IPsec deployment supporting 710 only certificate authentication, a management station initiating an 711 IPsec-protected telnet session to the RADIUS server would need to obtain 712 a certificate chaining to the RADIUS client CA. Issuing such a 713 certificate might not be appropriate if the management station was not 714 authorized as a RADIUS client. 716 Where RADIUS clients may obtain their IP address dynamically (such as an 717 Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409] 718 SHOULD NOT be used, since this requires use of a group pre-shared key; 719 instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses 720 are statically assigned either Aggressive Mode or Main Mode MAY be used. 721 With certificate authentication, Main Mode SHOULD be used. 723 Care needs to be taken with IKE Phase 1 Identity Payload selection in 724 order to enable mapping of identities to pre-shared keys even with 725 Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity 726 Payloads are used and addresses are dynamically assigned, mapping of 727 identities to keys is not possible, so that group pre-shared keys are 728 still a practical necessity. As a result, the ID_FQDN identity payload 729 SHOULD be employed in situations where Aggressive mode is utilized along 730 with pre-shared keys and IP addresses are dynamically assigned. This 731 approach also has other advantages, since it allows the RADIUS server 732 and client to configure themselves based on the fully qualified domain 733 name of their peers. 735 Note that with IPsec, security services are negotiated at the 736 granularity of an IPsec SA, so that RADIUS exchanges requiring a set of 737 security services different from those negotiated with existing IPsec 738 SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also 739 advisable where quality of service considerations dictate different 740 handling RADIUS conversations. Attempting to apply different quality of 741 service to connections handled by the same IPsec SA can result in 742 reordering, and falling outside the replay window. For a discussion of 743 the issues, see [RFC2983]. 745 4.4. Replay protection 747 Since this specification utilizes the Request Authenticator field for 748 integrity protection and authentication, rather than as a nonce, no 749 liveness or protection against replay is provided by the RADIUS header. 751 Where IPsec replay protection is not used, the Event-Timestamp (55) 752 Attribute [RFC2869] MUST be included within all messages. When this 753 attribute is present, both the NAS and the RADIUS server MUST check that 754 the Event-Timestamp Attribute is current within an acceptable time 755 window. If the Event-Timestamp Attribute is not current, then the 756 message MUST be silently discarded. This implies the need for time 757 synchronization within the network, which can be achieved by a variety 758 of means, including secure NTP, as described in [NTPAUTH]. 760 Both the NAS and the RADIUS server SHOULD be configurable to silently 761 discard messages lacking an Event-Timestamp Attribute. A default time 762 window of 300 seconds is recommended. 764 4.5. Spoofing and hijacking 766 Access-Request packets with a User-Password Attribute establish the 767 identity of both the user and the NAS sending the Access-Request, 768 because of the way the shared secret between the NAS and RADIUS server 769 is used. Access-Request packets with CHAP-Password or EAP-Message 770 Attributes do not have a User-Password Attribute. As a result, the 771 Message-Authenticator Attribute SHOULD be used in Access-Request packets 772 that do not have a User-Password Attribute, in order to establish the 773 identity of the NAS sending the request. This includes Access-Request 774 packets with a Service-Type Attribute with a value of "Authorize Only". 776 An attacker may attempt to inject packets into the conversation between 777 the NAS and the RADIUS server. RADIUS [RFC2865] does not support 778 encryption other than Attribute hiding. As described in [RFC2865], only 779 Access-Reply and Access-Challenge packets are authenticated and 780 integrity protected. Moreover, the per-packet authentication and 781 integrity protection mechanism described in this specification has known 782 weaknesses [MD5Attack], making it a tempting target for attackers. 784 To provide stronger security, implementations of this specification 785 SHOULD use IPsec ESP with non-null transform and per-packet encryption, 786 authentication, integrity and replay protection, as specified in Section 787 4.3. 789 5. IANA Considerations 791 This specification requires assignment of a UDP port, in addition to 792 RADIUS Type codes for Notify-Request, Notify-Accept, and Notify-Reject. 794 6. Normative references 796 [RFC1305] Mills, D. L., "Network Time Protocol (version 3) 797 Specification, Implementation and Analysis, RFC 1305 798 March, 1992. 800 [RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest 801 Algorithm", RFC 1321, April 1992. 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", RFC 2119, March, 1997. 806 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 807 "Remote Authentication Dial In User Service (RADIUS)", 808 RFC 2865, June 2000. 810 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 812 [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS 813 Extensions", RFC 2869, June 2000. 815 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 816 3162, August 2001. 818 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 819 Port based Network Access Control, IEEE Std 802.1X-2001, 820 June 2001. 822 [Congdon] Congdon, P., et al., "IEEE 802.1X RADIUS Usage 823 Guidelines", Internet draft (work in progress), draft- 824 congdon-radius-8021x-29.txt, April 2003. 826 [DynAuth] Chiba, M., et. al., "Dynamic Authorization Extensions to 827 Remote Authentication Dial-in User Service (RADIUS)", 828 Internet draft (work in progress), draft-chiba-radius- 829 dynamic-authorization-20.txt, May 2003. 831 7. Informative references 833 [Mishra] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 834 "Experimental Neighbor Graph Creation and Maintenance", 835 Internet draft (work in progress), draft-irtf-aaaarch- 836 neighbor-graph-00.txt. 838 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 839 Hashing for Message Authentication", RFC 2104, February 840 1997. 842 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 843 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 844 October 1998. 846 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 847 Implementation in Roaming", RFC 2607, June 1999. 849 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 850 Protocol", RFC 2716, October 1999. 852 [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 853 2983, October 2000. 855 [Context] Aboba, B. and T. Moore, "A Model for Context Transfer in 856 IEEE 802", draft-aboba-802-context-02.txt, Internet draft 857 (work in progress), April 2002. 859 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 860 Overview and Architecture, ANSI/IEEE Std 802, 1990. 862 [IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: 863 Draft Standard for Virtual Bridged Local Area Networks, 864 P802.1Q, January 1998. 866 [IEEE-02-758] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 867 "Proactive Caching Strategies for IAPP Latency 868 Improvement during 802.11 Handoff", IEEE 802.11 Working 869 Group, IEEE-02-758r1-F, November 2002. 871 [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, 872 "Proactive Key Distribution to support fast and secure 873 roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, 874 http://www.ieee802.org/11/Documents/DocumentHolder/ 875 3-084.zip, January 2003. 877 [8021XHandoff] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in 878 a Public Wireless LAN Based on IEEE 802.1X Model", School 879 of Computer Science and Engineering, Seoul National 880 University, Seoul, Korea, 2002. 882 [IEEE8023] ISO/IEC 8802-3 Information technology - 883 Telecommunications and information exchange between 884 systems - Local and metropolitan area networks - Common 885 specifications - Part 3: Carrier Sense Multiple Access 886 with Collision Detection (CSMA/CD) Access Method and 887 Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 888 1996), 1996. 890 [IEEE80211] Information technology - Telecommunications and 891 information exchange between systems - Local and 892 metropolitan area networks - Specific Requirements Part 893 11: Wireless LAN Medium Access Control (MAC) and 894 Physical Layer (PHY) Specifications, IEEE Std. 895 802.11-1999, 1999. 897 [IEEE80211f] Information technology - Telecommunications and 898 information exchange between systems - Local and 899 metropolitan area networks - Specific Requirements Part 900 11: Recommended Practice for Multi-Vendor Access Point 901 Interoperability via an Inter-Access Point Protocol 902 Across Distribution Systems Supporting IEEE 802.11 903 Operation, IEEE Draft 802.11f/D5, January 2003. 905 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack." 906 CryptoBytes Vol.2 No.2, Summer 1996. 908 [NASREQ] Calhoun, P., et al., "Diameter Network Access Server 909 Application", draft-ietf-aaa-diameter-nasreq-11.txt, 910 Internet draft (work in progress), February 2003. 912 [NTPAuth] Mills, D., "Public Key Cryptography for the Network Time 913 Protocol", Internet draft (work in progress), draft-ietf- 914 stime-ntpauth-05.txt, November 2002. 916 Acknowledgments 918 The authors would like to acknowledge the following people for 919 contributions to this document: Tim Moore (Microsoft), Min-ho Shin 920 (University of Maryland), Nick Petroni (University of Maryland), Adam 921 Sulmicki (University of Maryland), Insun Lee (Samsung Electronics), 922 Kyunghun Jang (Samsung Electronics). 924 Authors' Addresses 926 William A. Arbaugh 927 Department of Computer Science 928 University of Maryland, College Park 929 A.V. Williams Building 930 College Park, MD 20742 932 EMail: waa@cs.umd.edu 933 Phone: +1 301 405 2774 935 Bernard Aboba 936 Microsoft Corporation 937 One Microsoft Way 938 Redmond, WA 98052 940 EMail: bernarda@microsoft.com 941 Phone: +1 425 706 6605 942 Fax: +1 425 936 7329 944 Intellectual Property Statement 946 The IETF takes no position regarding the validity or scope of any 947 intellectual property or other rights that might be claimed to pertain 948 to the implementation or use of the technology described in this 949 document or the extent to which any license under such rights might or 950 might not be available; neither does it represent that it has made any 951 effort to identify any such rights. Information on the IETF's 952 procedures with respect to rights in standards-track and standards- 953 related documentation can be found in BCP-11. Copies of claims of 954 rights made available for publication and any assurances of licenses to 955 be made available, or the result of an attempt made to obtain a general 956 license or permission for the use of such proprietary rights by 957 implementors or users of this specification can be obtained from the 958 IETF Secretariat. 960 The IETF invites any interested party to bring to its attention any 961 copyrights, patents or patent applications, or other proprietary rights 962 which may cover technology that may be required to practice this 963 standard. Please address the information to the IETF Executive 964 Director. 966 Full Copyright Statement 968 Copyright (C) The Internet Society (2003). All Rights Reserved. 969 This document and translations of it may be copied and furnished to 970 others, and derivative works that comment on or otherwise explain it or 971 assist in its implementation may be prepared, copied, published and 972 distributed, in whole or in part, without restriction of any kind, 973 provided that the above copyright notice and this paragraph are included 974 on all such copies and derivative works. However, this document itself 975 may not be modified in any way, such as by removing the copyright notice 976 or references to the Internet Society or other Internet organizations, 977 except as needed for the purpose of developing Internet standards in 978 which case the procedures for copyrights defined in the Internet 979 Standards process must be followed, or as required to translate it into 980 languages other than English. The limited permissions granted above are 981 perpetual and will not be revoked by the Internet Society or its 982 successors or assigns. This document and the information contained 983 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 984 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 985 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 986 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 987 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 989 Expiration Date 991 This memo is filed as , and expires 992 November 22, 2003.