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