Networking Working Group                                Paul Congdon
   INTERNET-DRAFT                                      Mauricio Sanchez
   <draft-congdon-radext-ieee802-03.txt>        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        <redir_addr|redir_URL>

               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       <etype[:val]|ipprot|ip|http>

               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    <address/mask> [ports]

               For MAC filter rules, <address/mask> 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 <address/mask> 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:

         <flush>

         A NAS-Filter-Rule expressing an Ethernet filter rule MUST
         follow the syntax:

         <permit|deny> <in|out> <etype[:val]> from <address/mask> to
         <address/mask>

         A NAS-Filter-Rule expressing an IP redirect or filter rule MUST
         follow the syntax:

         <permit|deny|redirect <redir_addr>> <in|out> <ip|ip_proto> from
         <address/mask> to <address/mask> [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

         <permit|deny|redirect> <URL> <in|out> from <address/mask> to
         <address/mask>

      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]