rfc3579.txt

radius服务器

   String

      The String field contains an EAP packet, as defined in [RFC2284].
      If multiple EAP-Message attributes are present in a packet their
      values should be concatenated; this allows EAP packets longer than
      253 octets to be transported by RADIUS.

3.2.  Message-Authenticator

   Description

      This attribute MAY be used to authenticate and integrity-protect
      Access-Requests in order to prevent spoofing.  It MAY be used in
      any Access-Request.  It MUST be used in any Access-Request,
      Access-Accept, Access-Reject or Access-Challenge that includes an
      EAP-Message attribute.

      A RADIUS server receiving an Access-Request with a
      Message-Authenticator attribute present MUST calculate the correct
      value of the Message-Authenticator and silently discard the packet
      if it does not match the value sent.






Aboba & Calhoun              Informational                     [Page 16]

RFC 3579                      RADIUS & EAP                September 2003


      A RADIUS client receiving an Access-Accept, Access-Reject or
      Access-Challenge with a Message-Authenticator attribute present
      MUST calculate the correct value of the Message-Authenticator and
      silently discard the packet if it does not match the value sent.

      This attribute is not required in Access-Requests which include
      the User-Password attribute, but is useful for preventing attacks
      on other types of authentication.  This attribute is intended to
      thwart attempts by an attacker to setup a "rogue" NAS, and perform
      online dictionary attacks against the RADIUS server.  It does not
      afford protection against "offline" attacks where the attacker
      intercepts packets containing (for example) CHAP challenge and
      response, and performs a dictionary attack against those packets
      offline.

      A summary of the Message-Authenticator attribute format is shown
      below.  The fields are transmitted from left to right.

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |     String...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      80 for Message-Authenticator

   Length

      18

   String

      When present in an Access-Request packet, Message-Authenticator is
      an HMAC-MD5 [RFC2104] hash of the entire Access-Request packet,
      including Type, ID, Length and Authenticator, using the shared
      secret as the key, as follows.

      Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
      Request Authenticator, Attributes)

      When the message integrity check is calculated the signature
      string should be considered to be sixteen octets of zero.







Aboba & Calhoun              Informational                     [Page 17]

RFC 3579                      RADIUS & EAP                September 2003


      For Access-Challenge, Access-Accept, and Access-Reject packets,
      the Message-Authenticator is calculated as follows, using the
      Request-Authenticator from the Access-Request this packet is in
      reply to:

      Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
      Request Authenticator, Attributes)

      When the message integrity check is calculated the signature
      string should be considered to be sixteen octets of zero.  The
      shared secret is used as the key for the HMAC-MD5 message
      integrity check.  The Message-Authenticator is calculated and
      inserted in the packet before the Response Authenticator is
      calculated.

3.3.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in packets including EAP-Message attribute(s), and in what quantity.
   The EAP-Message and Message-Authenticator attributes specified in
   this document MUST NOT be present in an Accounting-Request.  If a
   table entry is omitted, the values found in [RFC2548], [RFC2865],
   [RFC2868], [RFC2869] and [RFC3162] should be assumed.

Request  Accept  Reject  Challenge   #    Attribute
0-1      0-1     0       0            1   User-Name
0        0       0       0            2   User-Password [Note 1]
0        0       0       0            3   CHAP-Password [Note 1]
0        0       0       0           18   Reply-Message
0        0       0       0           60   CHAP-Challenge
0        0       0       0           70   ARAP-Password [Note 1]
0        0       0       0           75   Password-Retry
1+       1+      1+      1+          79   EAP-Message [Note 1]
1        1       1       1           80   Message-Authenticator [Note 1]
0-1      0       0       0           94   Originating-Line-Info [Note 3]
0        0       0-1     0-1        101   Error-Cause [Note 2]
Request  Accept  Reject  Challenge   #    Attribute

   [Note 1] An Access-Request that contains either a User-Password or
   CHAP-Password or ARAP-Password or one or more EAP-Message attributes
   MUST NOT contain more than one type of those four attributes.  If it
   does not contain any of those four attributes, it SHOULD contain a
   Message-Authenticator.  If any packet type contains an EAP-Message
   attribute it MUST also contain a Message-Authenticator.  A RADIUS
   server receiving an Access-Request not containing any of those four
   attributes and also not containing a Message-Authenticator attribute
   SHOULD silently discard it.




Aboba & Calhoun              Informational                     [Page 18]

RFC 3579                      RADIUS & EAP                September 2003


   [Note 2] The Error-Cause attribute is defined in [RFC3576].

   [Note 3] The Originating-Line-Info attribute is defined in [NASREQ].

   The following table defines the meaning of the above table entries.

   0     This attribute MUST NOT be present.
   0+    Zero or more instances of this attribute MAY be present.
   0-1   Zero or one instance of this attribute MAY be present.
   1     Exactly one instance of this attribute MUST be present.
   1+    One or more of these attributes MUST be present.

4.  Security Considerations

4.1.  Security Requirements

   RADIUS/EAP is used in order to provide authentication and
   authorization for network access.  As a result, both the RADIUS and
   EAP portions of the conversation are potential targets of an attack.
   Threats are discussed in [RFC2607], [RFC2865], and [RFC3162].
   Examples include:

   [1]  An adversary may attempt to acquire confidential data and
        identities by snooping RADIUS packets.

   [2]  An adversary may attempt to modify packets containing RADIUS
        messages.

   [3]  An adversary may attempt to inject packets into a RADIUS
        conversation.

   [4]  An adversary may launch a dictionary attack against the RADIUS
        shared secret.

   [5]  An adversary may launch a known plaintext attack, hoping to
        recover the key stream corresponding to a Request Authenticator.

   [6]  An adversary may attempt to replay a RADIUS exchange.

   [7]  An adversary may attempt to disrupt the EAP negotiation, in
        order to weaken the authentication, or gain access to peer
        passwords.

   [8]  An authenticated NAS may attempt to forge NAS or session
        identification attributes,

   [9]  A rogue (unauthenticated) NAS may attempt to impersonate a
        legitimate NAS.



Aboba & Calhoun              Informational                     [Page 19]

RFC 3579                      RADIUS & EAP                September 2003


   [10] An attacker may attempt to act as a man-in-the-middle.

   To address these threats, it is necessary to support confidentiality,
   data origin authentication, integrity, and replay protection on a
   per-packet basis.  Bi-directional authentication between the RADIUS
   client and server also needs to be provided.  There is no requirement
   that the identities of RADIUS clients and servers be kept
   confidential (e.g., from a passive eavesdropper).

4.2.  Security Protocol

   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.

   Within RADIUS [RFC2865], a shared secret is used for hiding of
   attributes such as User-Password, as well as in computation of the
   Response Authenticator.  In RADIUS accounting [RFC2866], the shared
   secret is used in computation of both the Request Authenticator and
   the Response Authenticator.

   Since in RADIUS a shared secret is used to provide confidentiality as
   well as integrity protection and authentication, only use of IPsec
   ESP with a non-null transform can provide security services
   sufficient to substitute for RADIUS application-layer security.
   Therefore, where IPSEC AH or ESP null is used, it will typically
   still be necessary to configure a RADIUS shared secret.

   Where RADIUS is run over IPsec ESP with a non-null transform, the
   secret shared between the NAS and the RADIUS server MAY NOT be
   configured.  In this case, a shared secret of zero length MUST be
   assumed.  However, a RADIUS server that cannot know whether incoming
   traffic is IPsec-protected MUST be configured with a non-null RADIUS
   shared secret.

   When IPsec ESP is used with RADIUS, per-packet authentication,
   integrity and replay protection MUST be used.  3DES-CBC MUST be
   supported as an encryption transform and AES-CBC SHOULD be supported.
   AES-CBC SHOULD be offered as a preferred encryption transform if
   supported.  HMAC-SHA1-96 MUST be supported as an authentication
   transform.  DES-CBC SHOULD NOT be used as the encryption transform.






Aboba & Calhoun              Informational                     [Page 20]

RFC 3579                      RADIUS & EAP                September 2003


   A typical IPsec policy for an IPsec-capable RADIUS client is
   "Initiate IPsec, from me to any destination port UDP 1812".  This
   causes an IPsec SA to be set up by the RADIUS client prior to sending
   RADIUS traffic.  If some RADIUS servers contacted by the client do
   not support IPsec, then a more granular policy will be required:
   "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination
   port UDP 1812".

   For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
   IPsec, from any to me, destination port 1812".  This causes the
   RADIUS server to accept (but not require) use of IPsec.  It may not
   be appropriate to require IPsec for all RADIUS clients connecting to
   an IPsec-enabled RADIUS server, since some RADIUS clients may not
   support IPsec.

   Where IPsec is used for security, and no RADIUS shared secret is
   configured, it is important that the RADIUS client and server perform
   an authorization check.  Before enabling a host to act as a RADIUS
   client, the RADIUS server SHOULD check whether the host is authorized
   to provide network access.  Similarly, before enabling a host to act
   as a RADIUS server, the RADIUS client SHOULD check whether the host
   is authorized for that role.

   RADIUS servers can be configured with the IP addresses (for IKE
   Aggressive Mode with pre-shared keys) or FQDNs (for certificate
   authentication) of RADIUS clients.  Alternatively, if a separate
   Certification Authority (CA) exists for RADIUS clients, then the
   RADIUS server can configure this CA as a trust anchor [RFC3280] for
   use with IPsec.

   Similarly, RADIUS clients can be configured with the IP addresses
   (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for
   certificate authentication) of RADIUS servers.  Alternatively, if a
   separate CA exists for RADIUS servers, then the RADIUS client can