Networking Working Group Paul Congdon INTERNET-DRAFT Mauricio Sanchez Hewlett-Packard Company A. Lior 15 February 2005 Bridgewater Systems F. Adrangi Intel Bernard Aboba Microsoft RADIUS Extensions for IEEE 802 By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on July 15, 2005. Copyright Notice Copyright (C) The Internet Society 2004. All rights reserved. Abstract In certain network scenarios it is desirable to either filter user traffic or redirect it to a specific location. This document describes several methods that are available to be used with Remote Authentication Dial In User Service (RADIUS) Protocol and proposes additional attributes to be used by AAA clients, whether in an IEEE 802.1X or Internet Service Provider environment. Congdon, et al. Informational [Page 1] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 Table of Contents 1. Introduction .......................................... 3 1.1 Terminology ..................................... 4 1.2 Requirements Language ........................... 5 2. Overview .............................................. 5 2.1 Capability Advertisement ........................ 7 3. Traffic Redirection ................................... 8 3.1 Tunneling ....................................... 8 3.1.1 Service Initiation .............................. 8 3.1.2 Mid-session Redirection ......................... 8 3.1.3 Redirection Removal ............................. 8 3.2 IP Redirection ...................................... 9 3.2.1 Service Initiation .............................. 9 3.2.2 Mid-session IP Redirection ...................... 9 3.2.3 IP Redirection Removal .......................... 10 3.3 Application Layer Redirection ....................... 10 3.3.1 Service Initiation .............................. 10 3.3.2 Mid-session Application Layer Redirection ....... 11 3.3.3 Application Layer Redirection Removal ........... 11 3.3.4 Combination of methods .......................... 11 3.4 RADIUS Accounting ................................... 11 4. RADIUS Authentication ................................. 12 4.1 Egress-VLANID ................................... 12 4.2 Ingress-Filters ................................ 12 4.3 VLAN-Name ....................................... 13 4.4 User-Priority-Table ............................. 14 4.5 NAS-Filter-Rule ................................. 15 4.6 QoS-Filter-Rule ................................. 22 4.7 Redirect-Host ................................... 22 4.8 Origin-Realm .................................... 23 5. RADIUS Accounting ..................................... 24 5.1 Accounting-EAP-Auth-Method ...................... 24 6. Table of Attributes ................................... 24 7. Diameter Considerations ............................... 25 8. IANA Considerations ................................... 26 9. Security Considerations ............................... 27 9.1 Packet modification or forgery .................. 27 9.2 Dictionary Attacks .............................. 27 9.3 Known Plaintext Attacks ......................... 28 10. References ............................................ 28 10.1 Normative References .................................. 28 10.2 Informative References ................................ 30 Appendix A - Extended Attribute Formats ...................... 31 ACKNOWLEDGMENTS .............................................. 35 AUTHORS' ADDRESSES ........................................... 35 Intellectual Property Statement .............................. 36 Disclaimer of Validity ....................................... 36 Full Copyright Statement ..................................... 37 Congdon, et al. Informational [Page 2] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 1. Introduction IEEE 802.1X [IEEE8021X] provides "network port authentication" for IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring and 802.11 [IEEE80211i] wireless LANS. IEEE 802.1X does not require use of a backend authentication server, and thus can be deployed with stand-alone bridges or Access Points, as well as in centrally managed scenarios. As a result, support for the RADIUS [RFC2865] or Diameter [RFC3588] protocols is optional for IEEE 802.1X authenticators. In situations where it is desirable to centrally manage authentication, authorization and accounting (AAA) for IEEE 802 networks, deployment of a backend authentication and accounting server is desirable. In such situations, it is expected that IEEE 802.1X authenticators will function as AAA clients. The desire may exist to have AAA clients enforce varying levels of authorization. Within the confines AAA environments, there has been a general dearth of RADIUS attributes that allow explicit expressions of granular authorization policy. A need exists to extend RADIUS with new attributes that will allow explicit expressions of such policies. Besides IEEE 802.1X networks, there is a corollary need within Internet Service Provider (ISP) environments. From time to time an ISP requires to restrict a user's access to the Internet and redirect their traffic to an alternate location. For example, the user maybe on a prepaid plan and all the resources have been used up. In this case the ISP would block the user's access to the Internet and redirect them to a portal where the user can replenish their account. Another example where the ISP would want to restrict access and redirect a user that was involved in some fraudulent behavior. Again the ISP would want to block the user's access to the Internet and redirect to a portal where they can inform the user as to their state and allow them to inform the user of their concerns and potentially rectify the situation. In the examples above it is important to note that the ability to block and redirect user's traffic is required at service initiation and once service has been established. These capabilities must also be available across access technologies and various business scenarios. For example, the ability to block and redirect traffic is required for TCP users, cell phone users, WiFi users. As well, this capability must work whether the user is in their home network or roaming in a visited network which may or may not have a direct roaming relationship with the user's home network. Congdon, et al. Informational [Page 3] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 This document describes a protocol extension to the Remote Authentication Dial In User Service (RADIUS) Protocol [RFC2865] by which the aforementioned requirements for IEEE 802.1X and ISP environments can be addressed. To meet these needs eight new RADIUS attributes are required. Blocking and redirection of users traffic is known as hot-lining of accounts. In this document, hot-lining is used as the motivation for these attributes and an illustration of how they would be used. However, the attributes may be used together or separately to provide other features. Furthermore, this document also describes an alternative method for providing these capabilities, namely by using RADIUS attributes for tunneling protocol specified in [RFC2868]. This document describes how to provide capabilities for users traffic redirection with or without using tunnels. Finally, the document describes how to provide for these capabilities dynamically (mid- service) using the RADIUS protocol extension described in [RFC3576]. 1.1. Terminology In this document when we refer to Blocking of IP traffic we mean Filtering of IP traffic. Additionally, this document uses the following terms: Access Point (AP) A Station that provides access to the distribution services via the wireless medium for associated Stations. Association The service used to establish Access Point/Station mapping and enable Station invocation of the distribution system services. 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. Port Access Entity (PAE) Congdon, et al. Informational [Page 4] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 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. Station (STA) Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). Supplicant A supplicant is an entity that is being authenticated by an authenticator. The supplicant may be connected to the 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. 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]. An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant". 2. Overview As described in the Introduction section, it may be desirable within IEEE 802.1X and ISP environments to a control user's access to network resources (e.g. the Internet) by blocking their access and/or redirecting them to a specific location. In this section we will examine these requirements in more detail. Blocking access refers to setting up some rules at the NAS such that when the user initiates IP traffic, the NAS examines the set of rules associated with the Service granted to the user. These rules determine what traffic is allowed to proceed through the NAS and what traffic will be blocked. Today this capability is supported in RADIUS and is configurable during service establishment and mid-service via the Filter-Id(11) attribute. To use Filter-Id to control access to network resources the rules Congdon, et al. Informational [Page 5] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 need to be configured at each NAS. Filter-Id(11) is used in an Access-Accept to specify the name of the filter rule(s) to apply to this session. To effect a change mid-service (dynamically), the Filter-Id(11) is included in a Change-of-Authorization (COA) packet. Upon receiving the Filter-Id(11) the NAS start to apply the rules specified by the Filter-Id(11). As pointed out by NASREQ the use Filter-Id is not roaming friendly and it is recommended that instead one should use NAS-Filter- Rule(400) AVP. For this reason, this document introduces NAS- Filter-Rule(TBD) to RADIUS. Redirection refers to an action taken by the NAS to redirect the user's traffic to an alternate location. Redirecting traffic in mid-session will most probably break some applications. For hotlining, the purpose of redirection is not to continue to provide the service. Rather the purpose is to facilitate a mechanism whereby the user is informed of their state, and is provided for a way to rectify the situation. In some cases redirection could be used to redirect traffic to another location where service can continue. The following two examples illustrate the user's experience when being redirected. For the first example assume an IEEE 8021X environment, whereby a user connects to the enterprise LAN and initiates an authentication handshake. As part of the overall authentication process, it is also possible to pass endpoint state such as patch level, virus signature status, etc., all of which can be verified by a back-end server for policy compliancy and alter the authentication and authorization decision. In instances that an end-host is not in compliancy, the NAS may be instructed to limit network access in some fashion (i.e. quarantine) and limit network access to remediation services and a web-based information site. A user may sense degraded network performance and open a web session, which the NAS would redirect to the web-based information site for compliancy status, remediation actions, etc. For the second example assume an ISP environment, whereby a prepaid user is roaming the net in their hotel room over WiFi is to be Hot-lined because their account has no more funds. The user's Service Provider instructs the NAS to block all traffic, and redirect any port 80 traffic to the Service Provider's Prepaid Portal. Upon detecting that there is no service, the user launches his browser and regardless of which web site is being accessed the browser traffic will arrive at the Prepaid Portal which will then return a page back to the subscriber indicating that he needs to replenish his account. Congdon, et al. Informational [Page 6] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 There are several ways to redirect the user's traffic. Which method will be used depends on the capabilities available at the NAS and Service Provider's preference. User traffic can be redirected by tunneling the user's traffic to an alternate location. Tunneling can be used at layer-2 or layer-3. Tunneling will typically redirect all of the user's traffic for the Service. When tunneling is used to redirect all the traffic then blocking (or filtering) may not be necessary. Another method available for redirection is to have the NAS re- write the IP header in accordance with a redirection rule. We call this method Layer-3 Redirection. As the NAS receives packets from the user's device, if the packets match the redirection rule, the destination address and (optionally) the port is re-written causing them to arrive at the alternate location. As packets from that location arrive back at the NAS, the NAS rewrites the source address with the original destination address. This is similar to what a NAT will do. This method of redirection provides more flexibility than tunneling in that we can control which layer-3 flows are to be redirected. Another method of redirection is redirection in the application layer. In this method, the NAS is aware of application flows and redirects traffic based on an application specific method. For example, if the application is based on HTTP then an HTTP aware NAS would redirect traffic by issuing an HTTP Redirect response causing the users browser to navigate to an alternate Web Portal. Finally, redirection can be achieved by utilizing the RADIUS Framed-Route(22) attribute. Using this attribute the NAS can be instructed to route the packet over a specific path. Due to the security risks associated with Framed-Routing, the use of this attribute for redirection is discouraged and hence we will not deal with this method in this document. 2.1 Capability Advertisement For these usage scenarios to practically work the home network needs to know what Redirection and Filtering features are supported by the NAS and whether or not the NAS supports RADIUS dynamic operations. As per [TBD], A NAS that supports filtering and redirection capabilities should transmit the following capability attribute to advertise its capability: TBD. Congdon, et al. Informational [Page 7] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 3. Traffic Redirection In this section we present the various methods used for redirecting user traffic, which are: 1) Tunneling; 2) IP Redirection; and 3) HTTP Redirection For each method, we describe how redirection is done at service initiation and mid-sesssion. We also describe how redirection is removed when it is no longer desired. 3.1 Tunneling When tunneling is used it will typically be used to redirect the entire traffic associated with the Service. Therefore, blocking (or filtering) will not be necessary at the NAS. As discussed above, tunneling can be used to redirect traffic at either layer-2 or layer-3. Regardless, the message flows presented in the following sections are the same. Note that not all tunneling methods will work all the time. While we don't restrict the methods the operator must choose which tunneling method to deploy. 3.1.1 Service Initiation Redirect using tunnels at service initiation requires that the RADIUS server send the appropriate tunnel attributes to the NAS. The tunnel attributes will describe the tunnel endpoint and the type of tunnel to construct. The operation is as specified in [RFC2868]. 3.1.2 Mid-session Redirection Redirection of traffic using tunnels mid-session involves sending the tunnel attributes as per RFC2868 [5] to the NAS using Change- of-Authorization (COA) packet. The operation is described in [RFC3576]. Careful attention should be paid to the security issues in [RFC3576]. Note that if the session is already tunneled (eg. Mobile-IP) then the COA packet with a new tunnel specification can be sent to the NAS or alternatively the redirection can occur at the tunnel endpoint (the Home Agent) using any one of these methods. 3.1.3 Redirection Removal Congdon, et al. Informational [Page 8] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 If the normal mode for the session was to tunnel the session and redirection was sent to the NAS, the RADIUS Server can send the original tunnel attributes to the NAS in a COA packet. The NAS will tear down the tunnel and establish a connection back to the original tunnel endpoint. However, if the normal mode for the session is not to use tunneling then we have a problem because RADIUS does not have a mechanism where by it can de-tunnel. Receiving a COA message without tunnel attributes would not have an effect on an existing tunnel. In order to de-tunnel the session, the RADIUS server has to send the NAS a COA message with Service-Type(6) set to "Authorize-Only" causing the NAS to perform a re-Authorization. In response to the re-Authorization, the RADIUS server will send an Access-Accept packet without the tunneling information. Upon receiving the corresponding Access-Accept packet the NAS MUST apply the new authorization attributes. If these do not contain tunnel attributes, then the NAS MUST tear down the tunnel. 3.2 IP Redirection This document proposes a method to convey redirection rules at the IP layer via usage of the NAS-Filter-Rule(TBD) attribute. IP Redirection may require the use of blocking. If only some of the flows are redirected then the other flows will have to be blocked. In this case, the RADIUS server MUST communicate to the NAS the blocking rules. Blocking rules can be conveyed to the NAS using filtering rules within the NAS-Filter-Rule(TBD) attribute. These rules will be carried along side the redirection rules within a given NAS-Filter-Rule(TBD) attribute. 3.2.1 Service Initiation If redirection is required during service initiation then the RADIUS server will send the redirection rules and optionally the blocking rules within the NAS-Filter-Rule attribute in the Access- Accept. The NAS will then start the service as usual with the traffic redirected and blocked as per the received redirection and blocking rules. If the NAS advertised support for the redirection and it receives a NAS-Filter-Rule(TBD) that it does not recognize, the NAS MUST interpret the Access-Accept message as an Access-Reject message. 3.2.2 Mid-session IP Redirection If IP redirection is required to be applied to a service that has already been started then the RADIUS server can push the Congdon, et al. Informational [Page 9] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 redirection rules, and optionally the filter rules, to the NAS within a NAS-Filter-Rule attribute using a COA packet. The NAS will then commence to apply the redirecting rules and/or the filter rules. If the NAS receives a COA message that contains an NAS-Filter- Rule(TBD) that it does not recognize it MUST generate a COA-NAK packet with ERROR-CAUSE(101) set to "Invalid Request"(404). Alternatively, the RADIUS server can request that the NAS re- authorize the session using the procedures defined in [RFC3576]. The RADIUS server responds with an Access-Accept message (with Service-Type(6) set to "Authorize Only" that will contain the redirection and optionally filtering rules within a NAS-Filter- Rule(TBD). If the NAS receives an Access-Accept message that contains a NAS- Filter-Rule that it doesn't recognize it MUST treat the Access- Accept as an Access-Reject and terminate the session. 3.2.3 IP Redirection Removal The RADIUS server can turn redirection off mid-session in two ways. It can push new redirection attributes and filter attributes to the NAS using a COA packet or it can send the NAS a COA packet requesting it to re-authorize. When using COA message to return the redirection and filtering back to "normal". There needs to be either a filter rule(or filter-id) or redirection rule that corresponds to the "normal" state. If normally the session did not have any filter and or redirection rules applied then RADIUS can send a NAS-Filter- Rule(TBD) with the action of "flush" in the COA. This action will cause all the filter rules and redirection rules previously assigned to the session to be removed. If the NAS receives a NAS-Filter-Rule in the COA packet that it does not recognize then the NAS MUST respond with a COA-NAK with Error-Cause(101) set to "Invalid Request"(404). If the NAS receives an Access-Accept message sent in response to its Authorize-Only Access-Request, that contains an unrecognizable NAS-Filter-Rule(TBD), then the NAS MUST treat the Access-Accept as an Access-Reject and terminate the session immediately. 3.3 Application Layer Redirection The call flow associated with performing redirection at the application layer is very similar with the call flow associated with redirection done at the IP layer. What is different here is the number of different possible applications that must be Congdon, et al. Informational [Page 10] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 considered. Fortunately, the most common application (and the one that we will consider here) is HTTP based applications, or browser based application. The same NAS-Filter-Rule(TBD) attribute redirection described above is used to convey the redirection rules to use for Application Layer Redirection. HTTP redirection rules within the NAS-Filter-Rule attribute supports the encoding of a redirection URL to apply when a rule is matched. 3.3.1 Service Initiation As with previous call flows, the RADIUS MAY send multiple HTTP redirect or filtering rules within a NAS-Filter-Rule(TBD) attribute to the NAS in the Access-Accept message. If the NAS receives an HTTP redirect or filtering rule, which it does not understand, then the NAS MUST treat the Access-Accept as an Access-Reject packet. 3.3.2 Mid-session Application Layer Redirection Mid-session initiated Application Layer Redirection is similar to the call flows of IP-based redirection method discussed above, except HTTP redirect rules are used instead. 3.3.3 Application Layer Redirection Removal Redirection removal based on Application Based Redirection is similar to the call flows of IP-based redirection method discussed above. 3.3.4 Combination of methods It is possible to combine the above methods. For example, HTTP- redirection can be combined with layer-3 redirection where HTTP- Redirection can be used to contain browser traffic and IP- Redirection-Rule can be used to contain other IP traffic. 3.4 Accounting Every time a session is redirected and every time the redirection is reverted back a new session is created and the old one is terminated. Therefore the NAS MUST generate and Accounting- Request(Stop) for the old session and an Accounting-Request(Start) for the new session. As described above, when the NAS receives redirection attributes that it does not understand in an Access-Accept packet it MUST terminate the session and MUST generate an Accounting- Request(Stop) packet. Note, in the case where it receives Congdon, et al. Informational [Page 11] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 redirection/filtering attributes in a COA packet that it does not understand, then it responds with a COA-NAK packet and does not terminate the session and therefore it MUST NOT generate an Accounting-Request(Stop) packet. 4. RADIUS Authentication This specification introduces eight new RADIUS authentication attributes. 4.1. Egress-VLANID Description The Egress-VLANID attribute represents an allowed IEEE 802 Egress VLANID for this port. The Egress-VLANID contains two parts: the first part is the VLANID, the second part indicates if this VLANID is allowed for tagged or untagged packets. Multiple Egress-VLANID attributes can be delivered in an authentication response; each attribute adds the specified VLAN to the list of allowed egress VLANs for the port. This is an Extended RADIUS attribute. Code TBD Length 8 Data-Type Integer32 Integer32 The values include: 1 = Tagged 2 = Untagged 4.2. Ingress-Filters Description 802.1Q clause 8.4.5 describes the Ingress Filter variable per port. The Ingress-Filters attribute corresponds to Ingress Congdon, et al. Informational [Page 12] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 Filter per-port variable defined in IEEE 802.1Q clause 8.4.5. When the attribute has the value "Enabled", the set of VLANs that are allowed to ingress a port must match the set of VLANs that are allowed to egress a port. By default, where the Ingress-Filter attribute is not set, the value "Disabled" should be assumed. Only a single Ingress-Filters attribute MAY be sent within an Access-Accept or CoA-Request; this attribute MUST NOT be sent within an Access-Request, Access-Challenge, Access-Reject, or Disconnect-Request. This attribute is defined as an Extended RADIUS attribute. Code TBD Length 8 Data-Type UInt32 UInt32 1 - Enabled 2 - Disabled 4.3. VLAN-Name Description 802.1Q-2003 clause 12.10.2.1.3 (a) describes the administratively assigned VLAN Name associated with a VLAN ID defined within an 802.1Q bridge. The VLAN-Name attribute represents an allowed VLAN for this port. It works similar to the Egress-VLANID attribute except that the VLAN-ID itself is not specified or known, rather the VLAN name is used to identify the VLAN within the system. The VLAN-Name attribute contains two parts; the first part is the VLAN name, the second part indicates if frames on the VLAN for this port are to be represented in tagged or untagged format. Multiple VLAN-Name attributes can be delivered in an authentication response; each attribute adds the named VLAN to the list of allowed egress VLANs for the port. This attribute is defined as an Extended RADIUS attribute. Congdon, et al. Informational [Page 13] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 Code TBD Length >=9 Data-Type TBD - to be assigned by IANA - VLAN-Name String The String field contains the VLAN Name as defined in 802.1Q- 2003 clause 12.10.2.1.3 (a). UTF-8 encoded 10646 characters are recommended, but a robust implementation SHOULD support the field as undistinguished octets. Integer32 1 = Tagged 2 = Untagged 4.4. User-Priority-Table Description IEEE 802.1D clause 7.5.1 discusses how to regenerate (or re- map) user priority on frames received at a port. This per-port configuration enables a bridge to cause the priority or received traffic at a port to be mapped to a particular priority. The management variables are described in clause 14.6.2.2. This attribute represents the IEEE 802 prioritization that will be applied to packets arriving at this port. There are eight possible user priorities, according to the IEEE 802 standard. This attribute is defined as an Extended RADIUS attribute. Code TBD Length 12 Congdon, et al. Informational [Page 14] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 Data-Type UInt64 UInt64 The table, expressed as a unsigned 64-bit integer, maps the incoming priority (if one exists - the default is 0) into one of seven regenerated priorities. The format of this attribute is an eight byte octet string, where the first octet maps to incoming priority 0, the second octet to incoming priority 1, etc. The values in each octet represent the regenerated priority of the packet. It is thus possible to either remap incoming priorities to more appropriate values; or to honor the incoming priorities; or to override any incoming priorities, forcing them to all map to a single chosen priority. The IEEE 802.1D specification, Annex G, provides a useful description of traffic type - traffic class mappings. For mapping of the priority to quality of service at the IP layer, it is assumed that the LAN Edge Device has been provided a table with device-wide mappings of this user priority to the appropriate DiffServ code points. That table and its configuration are outside the scope of this document. 4.5. NAS-Filter-Rule Description The NAS-Filter-Rule attribute is derived from the Diameter IPFilterRule and enables the provisioning of Ethernet (Layer 2), Internet Protocol (Layer 3-4), and HTTP (Layer7) filter rules and Internet Protocol and HTTP redirect rules on the NAS by the RADIUS server. This attribute is defined as an Extended RADIUS attribute. When specifying an Ethernet filter rule, NAS-Filter-Rule processes packets based on the following information that is associated with it: Direction (in or out) Ethernet type Source and destination MAC address (possibly masked) When specifying an Internet Protocol filter or redirect rule, NAS-Filter-Rule processes packets based on the following information that is associated with it: Congdon, et al. Informational [Page 15] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options ICMP types When specifying an HTTP filter or redirect rule, NAS-Filter- Rule process packets based on the following information that is associated with it: HTTP URL Source and destination IP address (possibly masked) As per the requirements of RFC 2865, Section 2.3, if multiple NAS-Filter-Rule attributes are contained within an Access- Request or Access-Accept packet, they MUST be maintained in order. The attributes MUST be consecutive attributes in the packet. RADIUS proxies MUST NOT reorder NAS-Filter-Rule attributes. The RADIUS server can return multiple NAS-Filter-Rule attributes in an Access-Accept packet. Where more than one NAS- Filter-Rule attribute is included, it is assumed that the attributes are to be concatenated to form a single filter list. Furthermore, the concatenated filter list must abide to the following rules of precedence: 1) Ethernet filter rules MUST appear before all other rule types. 2) IP redirect rules MUST appear after any Ethernet filter rules and before HTTP redirect, IP filter, and/or HTTP filter rules. 3) HTTP redirect rules MUST appear after any IP redirect rules and before any IP filter and/or HTTP filter rules. 4) IP filter rules MUST appear after any HTTP redirect rules and before any HTTP filter rules. 5) HTTP filter rules MUST appear after any other rules. Rules are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, then packet is dropped (implicit deny all). When an HTTP redirect rule matches, the NAS shall reply to the HTTP request with an HTTP redirect in accordance with RFC redirecting traffic to specific URL. Congdon, et al. Informational [Page 16] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 Filter-ID (11) and NAS-Filter-Rule both define how filters are to be applied in the NAS. They both should not appear in the same message and only one of them should be processed. If Filter-ID is present, it should take precedence. Furthermore, multiple Filter-ID attributes may appear in the same Radius message. It is unclear how implementations should process these multiple attributes. Some implementation may append them to one another; others may select only a single attribute to process. The NAS-Filter-Rule attribute is shown below. The fields are transmitted from left to right: +---------------------------------------------------------------+ | 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| +---------------+---------------+-------------------------------+ | Type (TBD) | Length | Text | +---------------+---------------+-------------------------------+ | Text +---------------+---------------+---------------+---------------+ Type TBD for NAS-Filter-Rule. Length >= 2 Text The text conforms to the following specification: NAS-Filter-Rule MUST follow the general format: action [args] dir proto from src to dst [options] action permit - Allow packets that match the rule. deny - Drop packets that match the rule. redirect - Redirect packets that match the rule. flush - Remove all previously assigned filter rules. Congdon, et al. Informational [Page 17] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 When flush is specified no other attributes are specified. args For IP redirect rules: redir_addr An IPv4 or IPv6 number in dotted-quad or canonical IPv6 form. When the redirect rule matches (src/dst), traffic is redirected to redir_addr address rather than allowing traffic continue to original destination (dst) address For HTTP redirect rules: redir_URL An HTTP URL. When the redirect rule matches (src/dst), HTTP requests are redirected to redir_URL address in accordance with RFC redirection traffic to specific URL. dir "in" is from the terminal, "out" is to the terminal. proto For Ethernet filter rules: "etype" keyword means any Ethernet type will match etype:val Used to specify an Ethernet type by hexadecimal number, whereby "val" is replaced by desired number. Example: "etype:0x800" for IP ethertype (0x0800). For IP filter or redirect rules: "ip" keyword means any IP protocol will match. ipprot An IP protocol specified by number. For HTTP filter or redirect rules: "http" keyword used to designate rule as of http type. src, dst
[ports] For MAC filter rules,
may be specified as: macaddr An Ethernet MAC address with octet values separated by a "-". Example: "00-10-A4-23- 19-C0". macaddr/mask An Ethernet number as above with a mask width of the form "00-10-A4-23-19-C0/24". Congdon, et al. Informational [Page 18] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 In this case, all MAC addresses from 00- 10-A4-00-00-00 to 00-10-A4-FF-FF-FF will match. The MAC address MUST NOT have bits set beyond the mask. The keyword "any" is 00-00-00-00-00-00/0. The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. Note: [ports] optional argument not valid for MAC filter rules. For IP filter or redirect rules, the
may be specified as: ipno An IPv4 or IPv6 number in dotted-quad or canonical IPv6 form. Only this exact IP number will match the rule. ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask. For a match to occur, the same IP version MUST be present in the packet that was used in describing the IP address. To test for a particular IP version, the bits part can be set to zero. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. For IPv4, a typical first rule is often "deny in ip! assigned" The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. This does not affect the selection of port numbers. With the TCP, UDP and SCTP protocols, optional ports may be specified as: {port/port-port}[,ports[,...]] The '-' notation specifies a range of ports (including boundaries). Fragmented packets that have a non-zero offset (i.e., not the first Congdon, et al. Informational [Page 19] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 fragment) will never match a rule that has one or more port specifications. See the frag option for details on matching fragmented packets. options For IP filter or redirect rules, there are several optional arguments that can be specified: frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications. ipoptions spec Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts(timestamp). The absence of a particular option may be denoted with a '!'. tcpoptions spec Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are: mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a '!'. established TCP packets only. Match packets that have the RST or ACK bits set. setup TCP packets only. Match packets that have the SYN bit set but no ACK bit. tcpflags spec TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are: Congdon, et al. Informational [Page 20] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset. See the frag option for details on matching fragmented packets. icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. Both the numeric values and the symbolic values listed below can be used. The supported ICMP types are: echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request(8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18) Concise syntax statements for each rule type follow: A NAS-Filter-Rule expressing a flush of all rules MUST follow the syntax: A NAS-Filter-Rule expressing an Ethernet filter rule MUST follow the syntax: from
to
A NAS-Filter-Rule expressing an IP redirect or filter rule MUST follow the syntax: > from
to
[ports] [options] A NAS-Filter-Rule expressing a HTTP redirect or filter rule MUST follow the syntax: Congdon, et al. Informational [Page 21] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 from
to
A NAS that is unable to interpret or apply a deny rule MUST terminate the session. A NAS that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. A NAS MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations. 4.6. QoS-Filter-Rule Description The QoS-Filter-Rule attribute enables the provisioning of QoS filters on the NAS by the RADIUS server. This attribute is defined as an Extended RADIUS attribute. The QoS-Filter-Rule attribute is defined as follows: Code 407 Length >=5 Data-Type QoSFilterRule QoSFilterRule The QoSFilterRule field contains a QoS filter, utilizing the syntax defined for the QoSFilterRule derived data type defined in [RFC3588], Section 4.3. Note that this definition contained an error, so that the complete syntax is described in the definition of the QoS-Filter-Rule AVP, defined in [NASREQ] Section ?. 4.7. Redirect-Host Description Congdon, et al. Informational [Page 22] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 The Redirect-Host attribute provides support for Redirect functionality, as described in [RFC3588], Section 6.12. This attribute is defined as an Extended RADIUS attribute. Code ? - Defined in [RFC3588] Length =4 (REQUIRED in an Access-Request) >=5 (REQUIRED in an Access-Accept) Data Type String String The String field is one or more octets, containing the full qualified domain name of the server to which the NAS should be redirected. This attribute MUST only be sent in an Access- Accept if a null Redirect-Host attribute (Length = 4) is included in an Access-Request. 4.8. Origin-Realm Description The Origin-Realm attribute contains the realm of the originator of a message, as described in [RFC3588], Section 6.4. Code 296 Length >=5 (Short Form) Data Type String String The String field contains the fully qualified domain name(FQDN) representing the realm. Congdon, et al. Informational [Page 23] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 5. RADIUS Accounting 5.1. Accounting-EAP-Auth-Method Description Accounting-EAP-Auth-Method enables a RADIUS client to include the EAP method utilized within an accounting packet. The semantics of this attribute are identical to that of the Accounting-EAP-Auth-Method AVP defined in [DiamEAP], Section 4.1.5. This is a standard RADIUS attribute. The Accounting-EAP-Auth-Method attribute 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 10 Value The Value field is eight octets. In case of expanded types defined in [RFC3748] Section 5.7, the least significant 32 bits contain the Vendor-Type field, and the next 24 bits contain the Vendor-Id field. 6. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Access- Access- Access- Access- CoA- Request Accept Reject Challenge Req # Attribute 0+ 0+ 0+ 0+ 0+ TBD Extended 0 0+ 0 0 0+ TBD Egress-VLANID [a] Congdon, et al. Informational [Page 24] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 0 0-1 0 0 0-1 TBD Ingress-Filters [a] 0 0-1 0 0 0-1 TBD User-Priority-Table [a] 0 0+ 0 0 0+ TBD NAS-Filter-Rule [a] 0 0+ 0 0 0+ 407 QoS-Filter-Rule [a] 0-1 0 0 0+ 0 TBD Redirect-Host 0-1 0 0 0 0 296 Origin-Realm Actng- Actng- Request Response # Attribute 0-1 0 TBD Accounting-EAP-Auth-Method 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 the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet. Notes ------ [a] This attribute MAY only be included in a COA-Request if the NAS indicates in the Access-Request that it supports Extended attributes. Otherwise, this attribute MUST NOT be sent in a COA- Request. 7. Diameter Considerations As described in Appendix A, the Extended attributes described in this specification are defined in both RADIUS and Diameter, and utilize the Data Types defined in [RFC3588]. Attributes already defined within Diameter, and defined as Extended RADIUS attributes within this specification include: NAS-IPFilter-Rule [NASREQ], QoS-Filter-Rule [NASREQ], EAP-Master-Session-Key [DiamEAP], EAP- Key-Name [DiamEAP], Redirect-Host [RFC3588] and Origin-Realm [RFC3588]. Extended attributes defined within both RADIUS and Diameter include Egress-VLANID, Ingress-Filters, User-Priority-Table, Allowed-SSID, and Allowed-Called-Station-Id. Attributes solely defined within RADIUS include the Extended attribute (used to encapsulate Diameter-compatible RADIUS attributes), as well as the Accounting-EAP-Auth-Method attribute, defined within [DiamEAP]. In order to translate RADIUS Extended attributes to Diameter AVPs, a RADIUS/Diameter gateway must first concatenate all RADIUS Congdon, et al. Informational [Page 25] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 attributes of type Extended, and then parse the included sub- attributes. The sub-attributes are then encapsulated within the Diameter AVP format as folows: a. The Code, Length, and Mandatory fields as well as the attribute data are copied directly from the Extended RADIUS attribute to the Diameter AVP. b. If the RADIUS "short form" Extended format is used, then the 'V' bit always set to zero in the Diameter AVP. c. If the RADIUS "long form" Extended format is used, then the 'V' bit and Vendor-Id is copies from the Extended RADIUS attribute to the Diameter AVP. In translating from Diameter to RADIUS, the gateway encapsulates Diameter AVPs within Extended RADIUS attributes as follows: a. If the 'V' bit is set to one (1), or the Diameter AVP Code is larger than 16384, then the "Long Form" Extended RADIUS attribute format MUST be used. Otherwise, the "Short Form" attribute format SHOULD be used. b. The Code, Length, and Mandatory fields as well as the attribute data are copied directly from the Diameter AVP to the Extended RADIUS attribute. c. If the 'V' bit is set to one (1), then the 'V' bit as well as the Vendor-Id fields are copies from the Diameter AVP to the Extended RADIUS attribute. d. Once the Extended RADIUS attributes have been encoded, they are encapsulated within RADIUS attributes of type Extended. Note that automated translation may not be on an initial Access- Request, since this packet must contain an empty Extended attribute in order to negotiate use of the Extended attribute format. 8. IANA Considerations This specification does not create any new registries. This specification requires assignment of a RADIUS attribute type for the Extended attribute. In addition, this specification requires assignment of the following Diameter Code values: AVP Code Congdon, et al. Informational [Page 26] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 ========= ==== Egress-VLANID TBD Ingress-Filter-Enable TBD User-Priority-Table TBD Allowed-SSID TBD Allowed-Called-Station-Id TBD 9. Security Considerations Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in IEEE 802.1X- enabled networks, it is vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3576], [RFC3579], and [RFC3580]. Vulnerabilities include: Packet modification or forgery Dictionary attacks Known plaintext attacks Key management issues 9.1. Packet Modification or Forgery As noted in [RFC3580], when used with IEEE 802.1X, all RADIUS packets MUST be authenticated and integrity protected. In addition, as described in [RFC3579], Section 4.2: To address the security vulnerabilities of RADIUS/EAP, implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with 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. 9.2. Dictionary Attacks As discussed in [RFC3579] Section 4.3.3, the RADIUS shared secret is vulnerable to offline dictionary attack, based on capture of the Response Authenticator or Message-Authenticator attribute. In order to decrease the level of vulnerability, [RFC2865], Section 3 recommends: The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well- Congdon, et al. Informational [Page 27] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 chosen password. It is preferred that the secret be at least 16 octets. In addition, the risk of an offline dictionary attack can be further mitigated by employing IPsec ESP with non-null transform in order to encrypt the RADIUS conversation, as described in [RFC3579], Section 4.2. 9.3. Known Plaintext Attacks Since IEEE 802.1X is based on EAP, which does not support PAP, the RADIUS User-Password attribute is not used to carry hidden user passwords. The hiding mechanism utilizes MD5, defined in [RFC1321], in order to generate a key stream based on the RADIUS shared secret and the Request Authenticator. Where PAP is in use, it is possible to collect key streams corresponding to a given Request Authenticator value, by capturing RADIUS conversations corresponding to a PAP authentication attempt using a known password. Since the User-Password is known, the key stream corresponding to a given Request Authenticator can be determined and stored. The vulnerability is described in detail in [RFC3579], Section 4.3.4. Even though IEEE 802.1X Authenticators do not support PAP authentication, a security vulnerability can still exist where the same RADIUS shared secret is used for hiding User-Password as well as other attributes. This can occur, for example, if the same RADIUS proxy handles authentication requests for both IEEE 802.1X (which may hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE- Recv-Key attributes) and GPRS (which may hide the User-Password attribute). The threat can be mitigated by protecting RADIUS with IPsec ESP with non-null transform, as described in [RFC3579], Section 4.2. In addition, the same RADIUS shared secret MUST NOT used for both IEEE 802.1X authentication and PAP authentication. 10. References 10.1. Normative references [RFC1321] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. Congdon, et al. Informational [Page 28] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 [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. [RFC2867] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [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., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,"Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, J., "Diameter Base Protocol", RFC 3588, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004, August 2004. [IEEE802.11i] Institute of Electrical and Electronics Engineers, Congdon, et al. Informational [Page 29] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 "Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", June 2004. [Arkko] Arkko, J., "Object Identifier and Type Spaces in a Rationalized RADIUS Data Model", post to the RADEXT WG Mailing list, June 9, 2004, http://ops.ietf.org/lists/radiusext/2004/msg00441.html 10.2. Informative references [Calhoun] Calhoun, P., "Diameter Network Access Server Application". [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [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. [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996. [Housley56] Housley, R., "Key Management in AAA", Presentation to the AAA WG at IETF 56, http://www.ietf.org/proceedings/03mar/slides/aaa- 5/index.html, March 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, Congdon, et al. Informational [Page 30] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 P802.1Q, January 1998. [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. [KEYFRAME] Aboba, B., Simon, D., Arkko, J., Eronen, P. and H. Levkowetz, "EAP Key Management Framework", draft-ietf-eap- keying-03.txt, July 2004. Appendix A - Extended Attribute Formats The use of a Diameter-compatible Extended attribute format within RADIUS was first proposed in [Arkko]. This Appendix describes a potential definition of the Extended attribute, based on a modified version of that proposal. The proposed definition provides support for Diameter-compatibility as well as sub- attributes, and support for a more efficient "short form" encoding. The Extended attribute, RADIUS attribute type TBD, enables the encoding of Extended RADIUS attributes. If multiple Extended attributes are present in a packet their values should be concatenated; this allows attributes longer than 253 octets to be transported by the Extended attribute format. Multiple sub- attributes MAY be encoded within a single Extended attribute, although they do not have to be. Note: for the purposes of this appendix, allocation of a new RADIUS Type value is assumed. However, on the RADEXT WG mailing list, there has also been discussion of utilizing type 26 (Vendor- Specific) along with a Vendor-Id of zero(0). For the purposes of this specification either format would be work equally well. Extended attributes MUST only be used when both the RADIUS client and server support them. A RADIUS client supporting the Extended attribute format MUST include an Extended attribute with a Length Congdon, et al. Informational [Page 31] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 value of two (2) within the initial Access-Request of a session. A RADIUS server receiving an empty Extended attribute within an Access-Request MAY utilize Extended attributes within messages sent to the client, including Access-Reject, Access-Challenge, Access-Accept, CoA-Request and Disconnect-Request messages. A RADIUS server not receiving an empty Extended attribute within an initial Access-Request MUST NOT include Extended attributes in any RADIUS message sent to the client, including Access-Reject, Access-Challenge, Access-Accept, CoA-Request or Disconnect-Request messages. A.1 - Full Diameter AVP Format The full Extended attribute format is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |S| Code +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code (opt) | Length2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Vendor-Id (opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id(opt)| Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD - Allocated by IANA from within the RADIUS attribute space. Length The length of the attribute in octets, including the Type, Length, S, Code, Length2, Flags, Vendor-Id and Data fields. S 0 - Full Diameter AVP format 1 - Short Form Code Where the S bit is clear, the "full Diameter AVP" format is used, and the Code field is 31 bits, encoding the 31 least significant bits of the Diameter AVP format defined in [RFC3588]. Congdon, et al. Informational [Page 32] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 Where the S bit is set, the "Short Form" Extended format is used, and the Code field is 14 bits, encoding the 14 least significant bits of the Diameter AVP format, defined in [RFC3588]. Length2 The Length of the sub-attribute in octets, including the S, M, Code, Length2 and Data fields. Flags The Flags field is a single octet, defined as follows: +-+-+-+-+-+-+-+-+ |V|M|r|r|r|r|r|r| +-+-+-+-+-+-+-+-+ V 0 = IETF standard 1 = Vendor Specific M The 'M' Bit, known as the Mandatory bit, indicates whether support of the attribute is required. If an attribute with the 'M' bit set is received and either the attribute or its value is unrecognized, the message MUST be silently discarded. Attributes with the 'M' bit cleared are informational only and a receiver that receives a message with such an attribute that is not supported, or whose value is not supported, MAY simply ignore the attribute. r The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent specifications MAY define additional bits within the header, and an unrecognized bit SHOULD be considered an error. Vendor-Id The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order. Data Congdon, et al. Informational [Page 33] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 The Data field is zero or more octets and contains information specific to the attribute. The format and length of the Data field is determined by the Code and Length2 fields. The format of the Data field MUST be one of the data types defined in [RFC3588] or a data type derived from the base data types. A.2 - Short Form In order to enable Extended attributes to be encoded more economically, a "Short Form" of the Extended attribute format is proposed. The Short Form can be used to encode any Diameter AVP that meets the following constraints: [a] An IETF standard attribute (not Vendor-Specific) [b] Diameter Code between 0 and 16384 (all existing attributes) [c] No flag bits other than the Mandatory bit. The short form Extended attribute format is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |S|M| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length2 | Data.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD - Allocated by IANA from the RADIUS attribute space. Length The length of the attribute in octets, including the Type, Length, S, M, Code, Length2 and Data fields. S 1 - Short Form M 0 - Optional 1 - Mandatory Code The 14 least significant bits of the Diameter AVP Code field, as defined in [RFC3588]. Length2 Congdon, et al. Informational [Page 34] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 The Length of the sub-attribute in octets, including the S, M, Code, Length2 and Data fields. Data The Data field is zero or more octets and contains information specific to the attribute. The format and length of the Data field is determined by the Code and Length2 fields. The format of the Data field MUST be one of the data types defined in [RFC3588] or a data type derived from the base data types. Acknowledgments The authors would like to acknowledge Dorothy Stanley of Agere, Joseph Salowey of Cisco, David Nelson of Enterasys, Chuck Black of Hewlett Packard, and Ashwin Palekar of Microsoft. Authors' Addresses Paul Congdon Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747 EMail: paul.congdon@hp.com Phone: +1 916 785 5753 Fax: +1 916 785 8478 Mauricio Sanchez Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5559 Roseville, CA 95747 EMail: mauricio.sanchez@hp.com Phone: +1 916 785 1910 Fax: +1 916 785 1815 Avi Lior Bridgewater Systems Corporation 303 Terry Fox Drive Suite 100 Ottawa, Ontario K2K 3J1 Canada Phone: (613) 591-6655 EMail: avi@bridgewatersystems.com URI: TCP://.bridgewatersystems.com/ Congdon, et al. Informational [Page 35] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 Farid Adrangi Intel Corporation 2111 North East 25th Hillsboro, Oregon 97124 United States Phone: (503) 712-1791 EMail: farid.adrangi@intel.com 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO Congdon, et al. Informational [Page 36] INTERNET-DRAFT RADIUS Extensions for IEEE 802 15 February 2005 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Congdon, et al. Informational [Page 37]