Network Working Group William A. Arbaugh INTERNET-DRAFT University of Maryland CATEGORY: Informational Bernard Aboba <draft-irtf-aaaarch-handoff-04.txt> Microsoft Corporation 26 October 2003 Handoff Extension to RADIUS This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract In order to decrease handoff latency, this specification describes an extension to the RADIUS protocol that enables an accounting server to notify a NAS of a prospective handoff. This enables the NAS to reserve resources and obtain the session parameters prior to arrival of the client, potentially reducing handoff times. The extension described in this document is useful across a range of access technologies and is capable of enabling handoffs between providers. Recent implementation experience in 802.11 networks indicates that this extension is capable of reducing handoff times to levels suitable for use with Voice over IP (VOIP), even in cases where clients are travelling at vehicular velocities. Arbaugh & Aboba Informational [Page 1]
INTERNET-DRAFT Handoff Extension 26 October 2003 Table of Contents 1. Introduction .......................................... 3 1.1 Terminology ..................................... 5 1.2 Requirements language ........................... 6 2. Packet format ......................................... 6 2.1 Notify-Request .................................. 8 2.2 Notify-Accept ................................... 9 2.3 Notify-Reject ................................... 10 3. Table of Attributes ................................... 10 4. Security considerations ............................... 13 4.1 Authorize-Only messages ......................... 13 4.2 State removal ................................... 14 4.3 Authorization issues ............................ 14 4.4 Impersonation ................................... 15 4.5 IPsec usage guidelines .......................... 15 4.6 Replay protection ............................... 18 4.7 Spoofing and hijacking .......................... 19 5. IANA considerations ................................... 19 6. References ............................................ 19 6.1 Normative references ............................ 19 6.2 Informative references .......................... 20 ACKNOWLEDGMENTS .............................................. 22 AUTHORS' ADDRESSES ........................................... 23 Intellectual Property Statement .............................. 23 Full Copyright Statement ..................................... 24 Arbaugh & Aboba Informational [Page 2]
INTERNET-DRAFT Handoff Extension 26 October 2003 1. Introduction In wireless networks such as IEEE 802.11, described in [IEEE80211], it may be desirable to improve the speed at which handoff can be completed. Where RADIUS Accounting [RFC2866] is implemented, RADIUS Accounting packets will be generated each time the client connects to a NAS. Accounting packets from a single session, across multiple NASes, are uniquely identified by the Acct-Multi-Session-Id Attribute, described in [RFC2866] and [RFC3580]. The sequence of NASes contacted by clients as they move creates a graph representing the mobility paths of the clients. We call this graph a neighbor graph with NASes as the vertices and the mobility paths between the NASes as the edges. Thus, the number of neighbors for a given NAS is given by the degree function applied to the vertex representing the given NAS, e.g. for NAS_A the number of neighbors would be given by deg(v_A) where deg is the degree function deg: V -> int. Through knowledge of the neighbor graph, it is possible for a RADIUS server to anticipate client movements and provide advance notice of a potential handoff to the NAS. This advance notice, known as a Notify-Request in this specification, allows the NAS to reserve resources and obtain the session authorization parameters prior to arrival of the client. This removes the latency of the RADIUS exchange from the critical path for processing a handoff, decreasing handoff latency substantially, as described in [IEEE-02-758, IEEE-03-084]. Assuming that the coverage area is overlapping, this technique can support handoffs at vehicular velocities. The creation and maintenance of neighbor graphs at an authentication server is described in [IEEE-03-084]. An alternate approach to using neighbor graphs uses a matrix of probabilities and is described in [8021XHandoff]. By nature, client behavior is not completely predictable, so that the handoff advance notice is only advisory. The client identified in the advance notice may never contact the NAS, or may contact it long after the initial notice is received. As a result, the NAS will typically free reserved resources after a suitable waiting period, known as the Reservation-Lifetime. In situations where resources are at a premium, it may be desirable to minimize resources reserved for clients that are no longer likely to attempt to connect to a given NAS. To accomplish this, the reservation period can be shortened, or alternatively, the RADIUS server can remove resource reservations using the Disconnect- Request, specified in [RFC3576]. A client contacting the NAS after the Reservation-Lifetime has expired or a resource reservation has been removed will be unable to complete a handoff, and will need to do a fast resume, such as is supported in EAP TLS [RFC2716]. The extension described in this document enables a RADIUS Server to send Notify-Requests to NASes, and to receive Notify-Responses. The Notify- Arbaugh & Aboba Informational [Page 3]
INTERNET-DRAFT Handoff Extension 26 October 2003 Request identifies the session to be handed off and the NAS on which it currently resides. Attributes included within the Notify-Request are described in Section 2.1. If the NAS has resources available to reserve, and if it is enabled to support this handoff extension, then it will respond with a Notify- Accept. If resources are not available (such as when previous resource commitments leave insufficient resources remaining), or if the NAS does not wish to support the prospective handoff for any other reason, the NAS will respond with a Notify-Reject, specifying the reason why the requested handoff reservation could not be carried out, using the Error- Cause Attribute, specified in [RFC3576]. After the NAS responds with a Notify-Accept, it will typically issue an Access-Request to the RADIUS server. This allows the NAS to obtain the authorizations for the session before it is contacted by the client. The contents of the Access-Request sent by the NAS will depend on the form of access it is providing, so that it cannot be specified in detail here. However, for use with IEEE 802.11, it is expected that an Access- Request will be sent with a NAS-Port-Type Attribute with value "802.11" and a Service-Type Attribute with value "Authorize Only", as defined in [RFC3576]. For other access methods, a different NAS-Port-Type value might be sent, perhaps with a different value for Service-Type. Since the extension defined in this document supports multiple access methods and service types, and leverages the conventional RADIUS Access- Request/Response exchange, it can be used to enable handoffs between any acess technology compatible with RADIUS. For example, using this extension, it is possible to enable a handoff between 802.11 and cellular technologies such as GPRS or CDMA 1X-RTT. When this extension is used to enable handoff between heterogeneous technologies, the "correctness" issues described in [Context] do not arise, since the RADIUS server provides the authorizations appropriate for each NAS and access mechanism. This extension can also enable handoffs between providers that do not establish mutual trust, as would be required when using a context transfer approach, such as [IEEE80211f]. All that is necessary is that each NAS be able to reach the home RADIUS server through an appropriate path. Of course, where handoffs occur across different providers and access media, it is unlikely that session continuity can be preserved, since the client will be likely to change its IP address. In response to receiving a Notify-Request, a NAS that does not support these Extensions will typically respond with an ICMP Port Unreachable message. Since this extension utilizes the same UDP port (3799) as the Dynamic Authorization Extensions to RADIUS described in [RFC3576], it is possible that a Notify-Request may be sent to a NAS that while listening Arbaugh & Aboba Informational [Page 4]
INTERNET-DRAFT Handoff Extension 26 October 2003 on the port, does not support the extensions specified in this document. In this case, the NAS will silently discard the Notify-Request. In order to confirm that the NAS is listening on port 3799 but does not support the Handoff Extensions, the RADIUS server may send one or more test dynamic authorization message as described in [RFC3576], in order to determine the NAS capabilities. 1.1. Terminology This document uses the following terms: Authenticator An Authenticator is an entity that require authentication from the Supplicant. The Authenticator may be connected to the Supplicant at the other end of a point-to-point LAN segment or 802.11 wireless link. authentication server An authentication server is an entity that provides an Authentication Service to an Authenticator. This service verifies from the credentials provided by the Supplicant, the claim of identity made by the Supplicant. Network Access Server (NAS) The device providing access to the network. Service The NAS provides a service to the user, such as IEEE 802 or PPP. Port Access Entity (PAE) The protocol entity associated with a physical or virtual (802.11) Port. A given PAE may support the protocol functionality associated with the Authenticator, Supplicant or both. Session Each service provided by the NAS to a user constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service is ended. A user may have multiple sessions in parallel or series if the NAS supports that, with each session generating a separate start and stop accounting record. Where the client is mobile and is able to handoff between NASes, multiple related sessions may be uniquely identified by the Acct-Multi-Session-Id Attribute. Supplicant A Supplicant is an entity that is being authenticated by an Authenticator. The Supplicant may be connected to the Arbaugh & Aboba Informational [Page 5]
INTERNET-DRAFT Handoff Extension 26 October 2003 Authenticator at one end of a point-to-point LAN segment or 802.11 wireless link. 1.2. Requirements language In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Packet format Exactly one Notify-Request, Notify-Accept or Notify-Reject packet is encapsulated in the UDP Data field. For the Notify-Request packet, the UDP Destination Port is 3799. When a reply is generated, the source and destination ports are reversed. A summary of the data format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code The Code field is one octet, and identifies the type of RADIUS packet. When a packet is received with an unsupported Code field, it is silently discarded. RADIUS codes (decimal) for this extension are assigned as follows: TBD - Notify-Request TBD - Notify-Accept TBD - Notify-Reject Identifier The Identifier field is one octet, and aids in matching requests and Arbaugh & Aboba Informational [Page 6]
INTERNET-DRAFT Handoff Extension 26 October 2003 replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time. Length The Length field is two octets. It indicates the length of the packet including the Code, Identifier, Length, Authenticator and Attribute fields. Octets outside the range of the Length field MUST be treated as padding and ignored on reception. If the packet is shorter than the Length field indicates, it MUST be silently discarded. The minimum length is 20 and maximum length is 4096. Authenticator The Authenticator field is sixteen (16) octets. The most significant octet is transmitted first. This value is used to authenticate the messages between the client and RADIUS server. Request Authenticator In Notify-Request Packets, the Authenticator value is a 16 octet MD5 [RFC1321] checksum, called the Request Authenticator. The Request Authenticator is calculated the same way as for an Accounting- Request, specified in [RFC2866]. Note that the Request Authenticator of an Notify-Request can not be done the same way as the Request Authenticator of a RADIUS Access- Request, because there is no User-Password Attribute in an Notify- Request. Response Authenticator The Authenticator field in a Notify-Accept or Notify-Reject packet is called the Response Authenticator, and contains a one-way MD5 hash calculated over a stream of octets consisting of the Notify-Response Code, Identifier, Length, the Request Authenticator field from the Notify-Request packet being replied to, and the response Attributes if any, followed by the shared secret. The resulting 16 octet MD5 hash value is stored in the Authenticator field of the Notify-Accept or Notify-Reject packet. Attributes In Notify-Request messages, all Attributes are treated as mandatory. A NAS supporting this extension MUST respond to a Notify-Request containing one or more unsupported Attributes with a Notify-Reject. A Notify-Reject MUST NOT result in resources being reserved on the Arbaugh & Aboba Informational [Page 7]
INTERNET-DRAFT Handoff Extension 26 October 2003 NAS. Attributes beyond those specified in Section 3 SHOULD NOT be included within Notify-Request messages, since this could produce unpredictable results. When using a forwarding proxy, the proxy must be able to alter the packet as it passes through in each direction. When the proxy forwards a Notify-Request, it MAY add a Proxy-State Attribute, and when the proxy forwards a response, it MUST remove its Proxy-State Attribute if it added one. Proxy-State is always added or removed after any other Proxy-States, but no other assumptions regarding its location within the list of Attributes can be made. Since Notify responses are authenticated on the entire packet contents, the stripping of the Proxy-State Attribute invalidates the integrity check - so the proxy needs to recompute it. A forwarding proxy MUST NOT modify existing Proxy-State, State, or Class Attributes present in the packet. If there are any Proxy-State Attributes in a Notify-Request received from the server, the forwarding proxy MUST include those Proxy-State Attributes in its response to the server. The forwarding proxy MAY include the Proxy-State Attributes in the Notify-Request when it forwards the request, or it MAY omit them in the forwarded request. If the forwarding proxy omits the Proxy-State Attributes in the request, it MUST attach them to the response before sending it to the server. 2.1. Notify-Request Description A Notify-Request packet is sent by the RADIUS server to the NAS to notify it of the potential handoff of a specified session. Code TBD - Notify-Request Identifier The Identifier field MUST be changed whenever the content of the Attributes field changes, and whenever a valid reply has been received for a previous request. For retransmissions where the contents are identical, the Identifier MUST remain unchanged. Note that if the Event-Timestamp Attribute is included the Notify- Request then the Event-Timestamp value will be updated when the packet is retransmitted, changing the content of the Attributes field and requiring a new Identifier and Request Authenticator. Arbaugh & Aboba Informational [Page 8]
INTERNET-DRAFT Handoff Extension 26 October 2003 Request Authenticator The Request Authenticator of an Accounting-Request contains a 16-octet MD5 hash value calculated according to the method described in "Request Authenticator" in Section 2. Attributes The Attribute field is variable in length, and contains a list of Attributes. In Notify-Request packets, certain Attributes are used to uniquely identify the NAS as well as a potential user session on the NAS, and to describe the services to be provided. All NAS identification Attributes included in a Notify-Request message MUST match in order for a Notify-Accept to be sent; otherwise a Notify- Reject MUST be sent. To address security concerns described in Section 4.1, the User-Name Attributes MUST be present in Notify-Request packets. To address security concerns described in Section 4.2, the NAS-IP-Address and/or NAS-IPv6-Address Attributes SHOULD be present in Notify-Request packets; the NAS-Identifier Attribute MAY be present in addition. Details of the Attributes which may be included in Notify-Request packets are provided in Section 3. 2.2. Notify-Accept Description The NAS responds to the Notify-Request with a Notify-Accept if the NAS agrees to to prepare for a handoff of the specified session. Code TBD - Notify-Accept Identifier The Identifier field is a copy of the Identifier field of the Notify- Request which caused this Notify-Accept. Response Authenticator The Response Authenticator of a Notify-Accept contains a 16-octet MD5 hash value calculated according to the method described in "Response Authenticator" in Section 2. Attributes The Attribute field is variable in length, and contains a list of Arbaugh & Aboba Informational [Page 9]
INTERNET-DRAFT Handoff Extension 26 October 2003 Attributes. Within the Notify-Accept, Attributes are used to provide the RADIUS server with the session identifiers that will be used by the NAS in subsequent Access-Request and Accounting-Request packets. This includes session identification Attributes, such as the User- Name and Acct-Multi-Session-Id Attributes provided by the RADIUS server in the Notify-Request, as well as an Acct-Session-Id allocated by the NAS for the handoff, should it occur. The Idle-Timeout Attribute, when included in the Notify-Accept, provides the RADIUS server with the time that the NAS is willing to reserve resources for the handoff. Section 3 provides more detail on the Attributes permitted within the Notify-Accept packet. 2.3. Notify-Reject Description The NAS responds to the Notify-Request with a Notify-Reject if the NAS does not have the resources to make the required handoff preparations, or wishes to decline for any other reason. Code TBD - Notify-Reject Identifier The Identifier field is a copy of the Identifier field of the Notify- Request which caused this Notify-Reject. Response Authenticator The Response Authenticator of a Notify-Accept contains a 16-octet MD5 hash value calculated according to the method described in "Response Authenticator" in Section 2. Attributes The Attribute field is variable in length, and contains a list of Attributes. Within the Notify-Reject, the Error-Cause Attribute provides the RADIUS server with the reason why the Notify-Request could not be honored. Values of the Error-Cause Attribute, and their corresponding meanings are described in [RFC3576], Section 3.1. 3. Table of Attributes The following table provides a guide to which Attributes may be found in which kinds of packets, and in what quantity. If an Attribute is not mentioned in this table, then it SHOULD NOT be included in Notify- Arbaugh & Aboba Informational [Page 10]
INTERNET-DRAFT Handoff Extension 26 October 2003 Request, Notify-Accept or Notify-Reject packets. Notify Notify Notify Request Accept Reject # Attribute 1 1 0 1 User-Name [Note 1] 0-1 0 0 4 NAS-IP-Address [Note 2] 0-1 0 0 5 NAS-Port [Note 5] 1 0 0 6 Service-Type [Note 10,11] 0-1 0 0 7 Framed-Protocol [Note 10] 0-1 0-1 0-1 24 State [Note 12] 0-1 0-1 0 28 Idle-Timeout [Note 3] 0-1 0 0 30 Called-Station-Id [Note 4] 0-1 0 0 31 Calling-Station-Id [Note 1] 0-1 0 0 32 NAS-Identifier [Note 2] 0+ 0+ 0+ 33 Proxy-State 0 0-1 0 44 Acct-Session-Id [Note 7] 0-1 0-1 0 50 Acct-Multi-Session-Id [Note 6] 0-1 0-1 0-1 55 Event-Timestamp [Note 9] 1 0 0 61 NAS-Port-Type [Note 10] 0-1 0 0 87 NAS-Port-Id [Note 5] 0-1 0 0 94 Originating-Line-Info [Note 5] 0-1 0 0 95 NAS-IPv6-Address [Note 2] 0 0 0-1 101 Error-Cause [Note 8] Notify Notify Notify Request Accept Reject # Attribute The following table defines the meaning of the above table entries. 0 This Attribute MUST NOT be present in packet. 0+ Zero or more instances of this Attribute MAY be present in packet. 0-1 Zero or one instance of this Attribute MAY be present in packet. 1 Exactly one instance of this Attribute MUST be present in packet. [Note 1] The User-Name Attribute MUST be provided in the Notify-Request and MUST be echoed in the Notify-Accept, and subsequent Access-Request packets. [Note 2] A Notify-Request MUST contain a NAS-IP-Address, NAS- IPv6-Address or NAS-Identifier Attribute (or some combination of these). [Note 3] Within a Notify-Request, the Idle-Timeout Attribute provides a suggested amount of time for which the NAS may reserve resources for a potential handoff. If an Idle-Timeout Attribute is included within the Notify-Request, then if the NAS is unable to reserve resources for this period of time, then it MUST include an Idle-Timeout Attribute in the Notify-Accept, if sent, specifying the time it is willing to commit to. The RADIUS server should assume that the resources have been released at time Event-Timestamp + Idle-Timeout. Arbaugh & Aboba Informational [Page 11]
INTERNET-DRAFT Handoff Extension 26 October 2003 [Note 4] Within a Notify-Request, Called-Station-Id refers to the NAS from which the handoff is expected to occur. If the handoff does not occur from that NAS referred to in Called-Station-Id, then the NAS MAY refuse the handoff. In the case where NAS-Port-Type = 802.11, and the Called-Station-Id contains an SSID, then if the handoff occurs, the client MUST be granted access only to this SSID. If the attempts to connect to another SSID, then the NAS MUST deny network access to the client. If the SSID field is omitted, then a value of ANY is assumed. [Note 5] The NAS-Port and NAS-Port-Id Attributes, if present, refer to the NAS port from which the handoff is expected to occur. Originating- Line-Info provides information on how the session originated. [Note 6] Within a Notify-Request, the Acct-Multi-Session-Id provides a unique identifier for user sessions during handoffs between NASes. The Acct-Multi-Session-Id is echoed in subsequent Access-Request and Accounting-Request packets. [Note 7] The Acct-Session-Id, if present in Notify-Accept packets, denotes the accounting session id allocated by the NAS for the prospective handoff, should it occur. The Acct-Session-Id is echoed in subsequent Access-Request and Accounting-Request packets. [Note 8] The Error-Cause Attribute is present only in Notify-Reject packets, and specifies the reason for the rejection. It is defined in [RFC3576], Section 3.1. [Note 9] When IPsec replay protection is not used, the Event-Timestamp Attribute MUST be present in all packets in order to prevent replay attacks. This is discussed in Section 4. [Note 10] The Service-Type, NAS-Port-Type, and Framed-Protocol Attributes are used to specify the services that are to be provided to the handed off session. The Service-Type and NAS-Port-Type Attributes MUST be present in the Notify-Request; when used with 802.11, it is expected that a NAS-Port-Type Attribute with value "802.11" and a Service-Type Attribute with a value of "Authorize Only" will be included. The Service-Type is echoed in the subsequent Access-Request. If the NAS is not able to provide the specified service, then it MUST send a Notify-Reject. [Note 11] The Service-Type Attribute is included with a value of "Authorize Only" within a RADIUS Access-Request in order to indicate that only authorization is being requested, as defined in [RFC3576]. Where used in concert with this specification, such an Access-Request indicates that a handoff request is being anticipated and that the RADIUS server should send back an Access-Accept to allow the prospective handoff to occur, or an Access-Reject to deny the prospective handoff. Arbaugh & Aboba Informational [Page 12]
INTERNET-DRAFT Handoff Extension 26 October 2003 The decision is typically based on the User-Name, Called-Station-Id, Calling-Station-Id, and State attributes. [Note 12] The State Attribute is available to be sent by the RADIUS server to the NAS in a Notify-Request message and MUST be sent unmodified from the NAS to the RADIUS server in subsequent Notify- Accept, Notify-Reject or Access-Request messages. The NAS MUST NOT interpret the State Attribute locally. A Notify-Request, Notify-Accept or Notify-Reject packet must have only zero or one State Attribute. Usage of the State Attribute is implementation dependent. If the RADIUS server does not recognize the State Attribute in the Access-Request, then it MUST send an Access-Reject. 4. Security considerations 4.1. Authorize-Only messages After receipt of a Notify-Request, a NAS supporting this specification will respond with a Notify-Response, and if the Response is a Notify- Accept, the NAS will then send an Access-Request to the RADIUS server with a Service-Type value of "Authorize Only". In some cases, the NAS MAY send an Access-Request with a Service-Type value of "Authorize Only" even if it had not previously received a Notify-Request packet. This could occur, for example, in the case of an IEEE 802.11 Access Point (AP) receiving a Reassociation-Request frame from a Station. In order to avoid a complete EAP authentication as described in [RFC2284bis], it may be desirable for the AP to instead retrieve suitable keying material in order to complete a proof-of-possession exchange with the Station, as described in [IEEE80211i]. A RADIUS server SHOULD NOT respond to an Access-Request with a Service- Type value of "Authorize Only" unless a Message-Authenticator attribute is present, since otherwise the Access-Request will be unauthenticated. Even when a Message-Authenticator attribute is present, a RADIUS server MAY choose not to respond to "Authorize Only" Access-Requests unless certain conditions are met. For example, a RADIUS server MAY only respond to NAS devices to which a Notify-Request has previously been sent. Alternatively a RADIUS server MAY only respond to "Authorize Only" Access-Requests in situations where the user will subsequently authenticate to the NAS device. For example, IEEE 802.11 APs supporting WPA or RSN carry out a proof-of-possession exchange with the station, ensuring that only stations with access to appropriate keying material can gain access to the network. Arbaugh & Aboba Informational [Page 13]
INTERNET-DRAFT Handoff Extension 26 October 2003 4.2. State removal By responding to an Access-Request with an Access-Accept and suitable keying material, the RADIUS server installs state on the NAS, as described in [Keyframe]. While the NAS will typically remove unused state at a suitable interval, there may be circumstances in which it is desirable for the server to initiate removal of the state. For example, if a user account were to become compromised, it may be necessary not only to disable the account, but to remove state associated with the user on all NASes. State removal can be accomplished by use of Disconnect messages, as described in [RFC3576]. To request that a NAS remove state associated with a given user, the RADIUS server can send a Disconnect-Request to the NAS containing session identification attributes describing the state to be removed. Typically this will include a User-Name attribute, but other attributes could be included as well. If the user session is not active on the NAS, but the NAS is able to remove the state associated with the user, it will respond with a Disconnect-NAK containing an Error-Cause Attribute with a value of "Residual Session Context Removed". If the NAS is not able to remove the state, it will respond with a Disconnect-NAK containing an Error- Cause Attribute with a value of "Session Context Not Removable" or "Session Context Not Found". See Section 3.1 of [RFC3576] for more details. 4.3. Authorization issues A NAS or RADIUS proxy MUST silently discard Notify-Request packets from untrusted sources. By default, a RADIUS proxy SHOULD perform a "reverse path forwarding" (RPF) check to verify that a Notify-Request originates from an authorized RADIUS server. In addition, it SHOULD be possible to explicitly authorize additional sources of Notify-Request packets relating to certain classes of sessions. For example, a particular source can be explicitly authorized to send Notify-Request messages relating to users within a set of realms. To perform the RPF check, the proxy uses the session identification attributes included in Notify-Request packets, in order to determine the RADIUS server(s) to which an equivalent Access-Request could be routed. If the source address of the Notify-Request is within this set, then the Request is forwarded; otherwise it MUST be silently discarded. Typically the proxy will extract the realm from the Network Access Identifier [RFC2486] included within the User-Name Attribute, and determine the corresponding RADIUS servers in the proxy routing tables. The RADIUS servers for that realm are then compared against the source Arbaugh & Aboba Informational [Page 14]
INTERNET-DRAFT Handoff Extension 26 October 2003 address of the packet. Where no RADIUS proxy is present, the RPF check will need to be performed by the NAS itself. Since authorization to send a Notify-Request is determined based on the source address and the corresponding shared secret, the NASes or proxies SHOULD configure a different shared secret for each RADIUS server. 4.4. Impersonation [RFC2865] Section 3 states: A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied. When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address Attributes will typically not match the source address observed by the RADIUS server. Since the NAS-Identifier Attribute need not contain an FQDN, this Attribute may not be resolvable to the source address observed by the RADIUS server, even when no proxy is present. As a result, the authenticity check performed by a RADIUS server or proxy does not verify the correctness of NAS identification Attributes. This makes it possible for a rogue NAS to forge NAS-IP-Address, NAS- IPv6-Address or NAS-Identifier Attributes within a RADIUS Access-Request in order to impersonate another NAS. It is also possible for a rogue NAS to forge session identification Attributes such as the Called- Station-Id, Calling-Station-Id, or Originating-Line-Info [NASREQ]. This could fool the RADIUS server into sending Notify-Request messages containing forged session identification Attributes to a NAS targeted by an attacker. To address these vulnerabilities RADIUS proxies SHOULD check whether NAS identification Attributes match the source address of packets originating from the NAS. Where one or more Attributes do not match, Notify-Request messages SHOULD be silently discarded. Such a check may not always be possible. Since the NAS-Identifier Attribute need not correspond to an FQDN, it may not be resolvable to an IP address to be matched against the source address. Also, where a NAT exists between the RADIUS client and proxy, checking the NAS-IP-Address or NAS-IPv6-Address Attributes may not be feasible. 4.5. IPsec usage guidelines In addition to security vulnerabilities unique to Notify messages, the protocol exchanges described in this document are susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is RECOMMENDED that IPsec Arbaugh & Aboba Informational [Page 15]
INTERNET-DRAFT Handoff Extension 26 October 2003 be employed to afford better security. Implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with a non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management. Within RADIUS [RFC2865], a shared secret is used for hiding Attributes such as User-Password, as well as used in computation of the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computation of both the Request Authenticator and the Response Authenticator. Since in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication, only use of IPsec ESP with a non-null transform can provide security services sufficient to substitute for RADIUS application-layer security. Therefore, where IPsec AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret. 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. When IPsec ESP is used with RADIUS, per-packet authentication, integrity and replay protection MUST be used. 3DES-CBC MUST be supported as an encryption transform and AES-CBC SHOULD be supported. AES-CBC SHOULD be offered as a preferred encryption transform if supported. HMAC-SHA1-96 MUST be supported as an authentication transform. DES-CBC SHOULD NOT be used as the encryption transform. A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate IPsec, from me to any destination port UDP 1812". This IPsec policy causes an IPsec SA to be set up by the RADIUS client prior to sending RADIUS traffic. If some RADIUS servers contacted by the client do not support IPsec, then a more granular policy will be required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812". For a client implementing this specification the policy would be "Accept IPsec, from any to me, destination port UDP 3799". This causes the RADIUS client to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS servers connecting to an IPsec-enabled RADIUS client, since some RADIUS servers may not support Arbaugh & Aboba Informational [Page 16]
INTERNET-DRAFT Handoff Extension 26 October 2003 IPsec. For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept IPsec, from any to me, destination port 1812". This causes the RADIUS server to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS clients connecting to an IPsec-enabled RADIUS server, since some RADIUS clients may not support IPsec. For servers implementing this specification, the policy would be "Initiate IPsec, from me to any, destination port UDP 3799". This causes the RADIUS server to initiate IPsec when sending RADIUS handoff extension traffic to any RADIUS client. If some RADIUS clients contacted by the server do not support IPsec, then a more granular policy will be required, such as "Initiate IPsec, from me to IPsec- capable-RADIUS-client, destination port UDP 3799". Where IPsec is used for security, and no RADIUS shared secret is configured, it is important that the RADIUS client and server perform an authorization check. Before enabling a host to act as a RADIUS client, the RADIUS server SHOULD check whether the host is authorized to provide network access. Similarly, before enabling a host to act as a RADIUS server, the RADIUS client SHOULD check whether the host is authorized for that role. RADIUS servers can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS clients. Alternatively, if a separate Certification Authority (CA) exists for RADIUS clients, then the RADIUS server can configure this CA as a trust anchor [RFC3280] for use with IPsec. Similarly, RADIUS clients can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS servers. Alternatively, if a separate CA exists for RADIUS servers, then the RADIUS client can configure this CA as a trust anchor for use with IPsec. Since unlike SSL/TLS, IKE does not permit certificate policies to be set on a per-port basis, certificate policies need to apply to all uses of IPsec on RADIUS clients and servers. In IPsec deployment supporting only certificate authentication, a management station initiating an IPsec-protected telnet session to the RADIUS server would need to obtain a certificate chaining to the RADIUS client CA. Issuing such a certificate might not be appropriate if the management station was not authorized as a RADIUS client. Arbaugh & Aboba Informational [Page 17]
INTERNET-DRAFT Handoff Extension 26 October 2003 Where RADIUS clients may obtain their IP address dynamically (such as an Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this requires use of a group pre-shared key; instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses are statically assigned either Aggressive Mode or Main Mode MAY be used. With certificate authentication, Main Mode SHOULD be used. Care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, mapping of identities to keys is not possible, so that group pre-shared keys are still a practical necessity. As a result, the ID_FQDN identity payload SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. This approach also has other advantages, since it allows the RADIUS server and client to configure themselves based on the fully qualified domain name of their peers. Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so that RADIUS exchanges requiring a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also advisable where quality of service considerations dictate different handling RADIUS conversations. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983]. 4.6. Replay protection Since this specification utilizes the Request Authenticator field for integrity protection and authentication, rather than as a nonce, no liveness or protection against replay is provided by the RADIUS header. Where IPsec replay protection is not used, the Event-Timestamp (55) Attribute [RFC2869] SHOULD be included within all messages. When this attribute is present, both the NAS and the RADIUS server MUST check that the Event-Timestamp Attribute is current within an acceptable time window. If the Event-Timestamp Attribute is not current, then the message MUST be silently discarded. This implies the need for time synchronization within the network, which can be achieved by a variety of means, including secure NTP, as described in [NTPAUTH]. Both the NAS and the RADIUS server SHOULD be configurable to silently discard messages lacking an Event-Timestamp Attribute. A default time window of 300 seconds is recommended. Arbaugh & Aboba Informational [Page 18]
INTERNET-DRAFT Handoff Extension 26 October 2003 4.7. Spoofing and hijacking Access-Request packets with a User-Password Attribute establish the identity of both the user and the NAS sending the Access-Request, because of the way the shared secret between the NAS and RADIUS server is used. Access-Request packets with CHAP-Password or EAP-Message Attributes do not have a User-Password Attribute. As a result, the Message-Authenticator Attribute SHOULD be used in Access-Request packets that do not have a User-Password Attribute, in order to establish the identity of the NAS sending the request. This includes Access-Request packets with a Service-Type Attribute with a value of "Authorize Only". An attacker may attempt to inject packets into the conversation between the NAS and the RADIUS server. RADIUS [RFC2865] does not support encryption other than Attribute hiding. As described in [RFC2865], only Access-Reply and Access-Challenge packets are authenticated and integrity protected. ??? from here until ???END lines may have been inserted/deleted Moreover, the per-packet authentication and integrity protection mechanism described in this specification has known weaknesses [MD5Attack], making it a tempting target for attackers. To provide stronger security, implementations of this specification SHOULD use IPsec ESP with non-null transform and per-packet encryption, authentication, integrity and replay protection, as specified in Section 4.3. 5. IANA Considerations This specification requires assignment of RADIUS Type codes for Notify- Request, Notify-Accept, and Notify-Reject. IANA considerations for RADIUS are described in [RFC3575]. 6. References 6.1. Normative references [RFC1305] Mills, D. L., "Network Time Protocol (version 3) Specification, Implementation and Analysis, RFC 1305 March, 1992. [RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. Arbaugh & Aboba Informational [Page 19]
INTERNET-DRAFT Handoff Extension 26 October 2003 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 2003. [RFC3576] Chiba, M., et. al., "Dynamic Authorization Extensions to Remote Authentication Dial-in User Service (RADIUS)", RFC 3576, July 2003. 6.2. Informative references [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000. [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. Arbaugh & Aboba Informational [Page 20]
INTERNET-DRAFT Handoff Extension 26 October 2003 [RFC3580] Congdon, P., et al., "IEEE 802.1X RADIUS Usage Guidelines", RFC 3580, September 2003. [Context] Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 802", draft-aboba-802-context-03.txt, Internet draft (work in progress), October 2003. [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q, January 1998. [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. [IEEE-02-758] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Caching Strategies for IAPP Latency Improvement during 802.11 Handoff", IEEE 802.11 Working Group, IEEE-02-758r1-F, November 2002. [IEEE-03-084] Mishra, A., Shin, M., Arbaugh, W., Lee, I. and K. Jang, "Proactive Key Distribution to support fast and secure roaming", IEEE 802.11 Working Group, IEEE-03-084r1-I, http://www.ieee802.org/11/Documents/DocumentHolder/ 3-084.zip, January 2003. [8021XHandoff] Pack, S. and Y. Choi, "Pre-Authenticated Fast Handoff in a Public Wireless LAN Based on IEEE 802.1X Model", School of Computer Science and Engineering, Seoul National University, Seoul, Korea, 2002. [IEEE8023] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 1996. [IEEE80211] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1999, 1999. Arbaugh & Aboba Informational [Page 21]
INTERNET-DRAFT Handoff Extension 26 October 2003 [IEEE80211f] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation, IEEE Draft 802.11f/D5, January 2003. [IEEE80211i] Institute of Electrical and Electronics Engineers, "Draft Supplement to STANDARD FOR Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security", IEEE Draft 802.11I/ D6.1, August 2003. [RFC2284bis] Blunk, L. et al., "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-06.txt, Internet draft (work in progress), September 2003. [Keyframe] Aboba, B., Simon, D. and J. Arkko, "EAP Key Management Framework", draft-ietf-eap-keying-01.txt, Internet draft (work in progress), November 2003. [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996. [NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", draft-ietf-aaa-diameter-nasreq-13.txt, Internet draft (work in progress), October 2003. [NTPAuth] Mills, D., "Public Key Cryptography for the Network Time Protocol", Internet draft (work in progress), draft-ietf- stime-ntpauth-05.txt, November 2002. Acknowledgments The authors would like to acknowledge the following people for contributions to this document: Tim Moore (Microsoft), Min-ho Shin (University of Maryland), Nick Petroni (University of Maryland), Adam Sulmicki (University of Maryland), Insun Lee (Samsung Electronics), Kyunghun Jang (Samsung Electronics). Arbaugh & Aboba Informational [Page 22]
INTERNET-DRAFT Handoff Extension 26 October 2003 Authors' Addresses William A. Arbaugh Department of Computer Science University of Maryland, College Park A.V. Williams Building College Park, MD 20742 EMail: waa@cs.umd.edu Phone: +1 301 405 2774 Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Arbaugh & Aboba Informational [Page 23]
INTERNET-DRAFT Handoff Extension 26 October 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expiration Date This memo is filed as <draft-irtf-aaaarch-handoff-04.txt>, and expires April 22, 2004. Arbaugh & Aboba Informational [Page 24]
