rfc3580.txt

radius服务器

   Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be
   used.









Congdon, et al.              Informational                     [Page 12]

RFC 3580                   IEEE 802.1X RADIUS             September 2003


3.24.  Port-Limit

   This attribute has no meaning when sent to an [IEEE8021X]
   Authenticator.

3.25.  Password-Retry

   In IEEE 802.1X, the Authenticator always transitions to the HELD
   state after an authentication failure.  Thus this attribute does not
   make sense for IEEE 802.1X.

3.26.  Connect-Info

   This attribute is sent by a bridge or Access Point to indicate the
   nature of the Supplicant's connection.  When sent in the Access-
   Request it is recommended that this attribute contain information on
   the speed of the Supplicant's connection.  For 802.11, the following
   format is recommended: "CONNECT 11Mbps 802.11b".  If sent in the
   Accounting STOP, this attribute may be used to summarize statistics
   relating to session quality.  For example, in IEEE 802.11, the
   Connect-Info attribute may contain information on the number of link
   layer retransmissions.  The exact format of this attribute is
   implementation specific.

3.27.  EAP-Message

   Since IEEE 802.1X provides for encapsulation of EAP as described in
   [RFC2284] and [IEEE8021X], the EAP-Message attribute defined in
   [RFC3579] is used to encapsulate EAP packets for transmission from
   the IEEE 802.1X Authenticator to the Authentication Server. [RFC3579]
   Section 2.2. describes how the Authentication Server handles invalid
   EAP packets passed to it by the Authenticator.

3.28.  Message-Authenticator

   As noted in [RFC3579] Section 3.1., the Message-Authenticator
   attribute MUST be used to protect packets within a RADIUS/EAP
   conversation.

3.29.  NAS-Port-Id

   This attribute is used to identify the IEEE 802.1X Authenticator port
   which authenticates the Supplicant.  The NAS-Port-Id differs from the
   NAS-Port in that it is a string of variable length whereas the NAS-
   Port is a 4 octet value.






Congdon, et al.              Informational                     [Page 13]

RFC 3580                   IEEE 802.1X RADIUS             September 2003


3.30.  Framed-Pool, Framed-IPv6-Pool

   IEEE 802.1X does not provide a mechanism for IP address assignment.
   Therefore the Framed-Pool and Framed-IPv6-Pool attributes can only be
   used by IEEE 802.1X Authenticators that support IP address assignment
   mechanisms.  Typically this capability is supported by layer 3
   devices.

3.31.  Tunnel Attributes

   Reference [RFC2868] defines RADIUS tunnel attributes used for
   authentication and authorization, and [RFC2867] defines tunnel
   attributes used for accounting.  Where the IEEE 802.1X Authenticator
   supports tunneling, a compulsory tunnel may be set up for the
   Supplicant as a result of the authentication.

   In particular, it may be desirable to allow a port to be placed into
   a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the
   result of the authentication.  This can be used, for example, to
   allow a wireless host to remain on the same VLAN as it moves within a
   campus network.

   The RADIUS server typically indicates the desired VLAN by including
   tunnel attributes within the Access-Accept.  However, the IEEE 802.1X
   Authenticator may also provide a hint as to the VLAN to be assigned
   to the Supplicant by including Tunnel attributes within the Access-
   Request.

   For use in VLAN assignment, the following tunnel attributes are used:

   Tunnel-Type=VLAN (13)
   Tunnel-Medium-Type=802
   Tunnel-Private-Group-ID=VLANID

   Note that the VLANID is 12-bits, taking a value between 1 and 4094,
   inclusive.  Since the Tunnel-Private-Group-ID is of type String as
   defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer
   value is encoded as a string.

   When Tunnel attributes are sent, it is necessary to fill in the Tag
   field.  As noted in [RFC2868], section 3.1:

      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  Valid values for this field are 0x01 through 0x1F,
      inclusive.  If the Tag field is unused, it MUST be zero (0x00).





Congdon, et al.              Informational                     [Page 14]

RFC 3580                   IEEE 802.1X RADIUS             September 2003


   For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel-
   Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or
   Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel-
   Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of
   greater than 0x1F is interpreted as the first octet of the following
   field.

   Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X
   Authenticators that may support tunneling but not VLANs), it is only
   necessary for tunnel attributes to specify a single tunnel.  As a
   result, where it is only desired to specify the VLANID, the tag field
   SHOULD be set to zero (0x00) in all tunnel attributes.  Where
   alternative tunnel types are to be provided, tag values between 0x01
   and 0x1F SHOULD be chosen.

4.  RC4 EAPOL-Key Frame

   The RC4 EAPOL-Key frame is created and transmitted by the
   Authenticator in order to provide media specific key information.
   For example, within 802.11 the RC4 EAPOL-Key frame can be used to
   distribute multicast/broadcast ("default") keys, or unicast ("key
   mapping") keys.  The "default" key is the same for all Stations
   within a broadcast domain.

   The RC4 EAPOL-Key frame is not acknowledged and therefore the
   Authenticator does not know whether the Supplicant has received it.
   If it is lost, then the Supplicant and Authenticator will not have
   the same keying material, and communication will fail.  If this
   occurs, the problem is typically addressed by re-running the
   authentication.

   The RC4 EAPOL-Key frame is sent from the Authenticator to the
   Supplicant in order to provision the "default" key, and subsequently
   in order to refresh the "default" key.  It may also be used to
   refresh the key-mapping key.  Rekey is typically only required with
   weak ciphersuites such as WEP, defined in [IEEE80211].

   Where keys are required, an EAP method that derives keys is typically
   selected.  Therefore the initial "key mapping" keys can be derived
   from EAP keying material, without requiring the Authenticator to send
   an RC4 EAPOL-Key frame to the Supplicant.  An example of how EAP
   keying material can be derived and used is presented in [RFC2716].









Congdon, et al.              Informational                     [Page 15]

RFC 3580                   IEEE 802.1X RADIUS             September 2003


   While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more
   complete description is provided on the next page.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |  Packet Type  |  Packet Body Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |          Key  Length          |Replay Counter...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Replay Counter...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Replay Counter    |   Key IV...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Key IV...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Key IV...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Key IV...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Key IV...         |F| Key Index   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Key Signature...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Key Signature...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Key Signature...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Key Signature...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Key...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version
      The Version field is one octet.  For IEEE 802.1X, it contains the
      value 0x01.

   Packet Type
      The Packet Type field is one octet, and determines the type of
      packet being transmitted.  For an EAPOL-Key Descriptor, the Packet
      Type field contains 0x03.

   Packet Body Length
      The Packet Body Length is two octets, and contains the length of
      the EAPOL-Key descriptor in octets, not including the Version,
      Packet Type and Packet Body Length fields.





Congdon, et al.              Informational                     [Page 16]

RFC 3580                   IEEE 802.1X RADIUS             September 2003


   Type
      The Type field is a single octet.  The Key descriptor is defined
      differently for each Type; this specification documents only the
      RC4 Key Descriptor (Type = 0x01).

   Key Length
      The Key Length field is two octets.  If Packet Body Length = 44 +
      Key Length, then the Key Field contains the key in encrypted form,
      of length Key Length.  This is 5 octets (40 bits) for WEP, and 13
      octets (104 bits) for WEP-128.  If Packet Body Length = 44, then
      the Key field is absent, and Key Length represents the number of
      least significant octets from the MS-MPPE-Send-Key attribute
      [RFC2548] to be used as the keying material.  Note that the MS-
      MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the
      point of view of the Authenticator.  From the Supplicant point of
      reference, the terms are reversed.  Thus the MS-MPPE-Recv-Key on
      the Supplicant corresponds to the MS-MPPE-Send-Key on the
      Authenticator, and the MS-MPPE-Send-Key on the Supplicant
      corresponds to the MS-MPPE-Recv-Key on the Authenticator.

   Replay Counter
      The Replay Counter field is 8 octets.  It does not repeat within
      the life of the keying material used to encrypt the Key field and
      compute the Key Signature field.  A 64-bit NTP timestamp MAY be
      used as the Replay Counter.

   Key IV
      The Key IV field is 16 octets and includes a 128-bit
      cryptographically random number.

   F
      The Key flag (F) is a single bit, describing the type of key that
      is included in the Key field.  Values are:

      0 = for broadcast (default key)
      1 = for unicast (key mapping key)

   Key Index
      The Key Index is 7 bits.

   Key Signature
      The Key Signature field is 16 octets.  It contains an HMAC-MD5
      message integrity check computed over the EAPOL-Key descriptor,
      starting from the Version field, with the Key field filled in if
      present, but with the Key Signature field set to zero.  For the
      computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is
      used as the HMAC-MD5 key.




Congdon, et al.              Informational                     [Page 17]

RFC 3580                   IEEE 802.1X RADIUS             September 2003


   Key
      If Packet Body Length = 44 + Key Length, then the Key Field
      contains the key in encrypted form, of length Key Length.  If
      Packet Body Length = 44, then the Key field is absent, and the
      least significant Key Length octets from the MS-MPPE-Send-Key
      attribute is used as the keying material.  Where the Key field is
      encrypted using RC4, the RC4 encryption key used to encrypt this
      field is formed by concatenating the 16 octet (128 bit) Key-IV
      field with the 32 octet MS-MPPE-Recv-Key attribute.  This yields a
      48 octet RC4 key (384 bits).

5.  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], [RFC3579], and [RFC3576].

   Vulnerabilities include:

      Packet modification or forgery
      Dictionary attacks
      Known plaintext attacks
      Replay
      Outcome mismatches
      802.11 integration
      Key management issues

5.1.  Packet Modification or Forgery

   RADIUS, defined in [RFC2865], does not require all Access-Requests to
   be authenticated or integrity protected.  However, IEEE 802.1X is
   based on EAP.  As described in [3579], Section 3.1.: