rfc3579.txt

radius服务器

   server.  Authentication-specific code can then reside on a security
   server instead.

   In the case where RADIUS-encapsulated EAP is used in a conversation
   between a RADIUS server and a security server, the security server
   will typically return an Access-Accept message without inclusion of
   the expected attributes currently returned in an Access-Accept.  This
   means that the RADIUS server MUST add these attributes prior to
   sending an Access-Accept message to the NAS.

2.6.  Usage Guidelines

2.6.1.  Identifier Space

   In EAP, each session has its own unique Identifier space.  RADIUS
   server implementations MUST be able to distinguish between EAP
   packets with the same Identifier existing within distinct sessions,
   originating on the same NAS.  For this purpose, sessions can be
   distinguished based on NAS and session identification attributes.
   NAS identification attributes include NAS-Identifier,
   NAS-IPv6-Address and NAS-IPv4-Address.  Session identification
   attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id,
   Called-Station-Id, Calling-Station-Id and Originating-Line-Info.

2.6.2.  Role Reversal

   Since EAP is a peer-to-peer protocol, an independent and simultaneous
   authentication may take place in the reverse direction.  Both peers
   may act as authenticators and authenticatees at the same time.

   However, role reversal is not supported by this specification.  A
   RADIUS server MUST respond to an Access-Request encapsulating an
   EAP-Request with an Access-Reject.  In order to avoid retransmissions




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


   by the peer, the Access-Reject SHOULD include an EAP-Response/Nak
   packet indicating no preferred method, encapsulated within
   EAP-Message attribute(s).

2.6.3.  Conflicting Messages

   The NAS MUST make its access control decision based solely on the
   RADIUS Packet Type (Access-Accept/Access-Reject).  The access control
   decision MUST NOT be based on the contents of the EAP packet
   encapsulated in one or more EAP-Message attributes, if present.

   Access-Accept packets SHOULD have only one EAP-Message attribute in
   them, containing EAP Success; similarly, Access-Reject packets SHOULD
   have only one EAP-Message attribute in them, containing EAP Failure.

   Where the encapsulated EAP packet does not match the result implied
   by the RADIUS Packet Type, the combination is likely to cause
   confusion, because the NAS and peer will arrive at different
   conclusions as to the outcome of the authentication.

   For example, if the NAS receives an Access-Reject with an
   encapsulated EAP Success, it will not grant access to the peer.
   However, on receiving the EAP Success, the peer will be lead to
   believe that it authenticated successfully.

   If the NAS receives an Access-Accept with an encapsulated EAP
   Failure, it will grant access to the peer.  However, on receiving an
   EAP Failure, the peer will be lead to believe that it failed
   authentication.  If no EAP-Message attribute is included within an
   Access-Accept or Access-Reject, then the peer may not be informed as
   to the outcome of the authentication, while the NAS will take action
   to allow or deny access.

   As described in [RFC2284], the EAP Success and Failure packets are
   not acknowledged, and these packets terminate the EAP conversation.
   As a result, if these packets are encapsulated within an
   Access-Challenge, no response will be received, and therefore the NAS
   will send no further Access-Requests to the RADIUS server for the
   session.  As a result, the RADIUS server will not indicate to the NAS
   whether to allow or deny access, while the peer will be informed as
   to the outcome of the authentication.










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


   To avoid these conflicts, the following combinations SHOULD NOT be
   sent by a RADIUS server:

      Access-Accept/EAP-Message/EAP Failure
      Access-Accept/no EAP-Message attribute
      Access-Accept/EAP-Start
      Access-Reject/EAP-Message/EAP Success
      Access-Reject/no EAP-Message attribute
      Access-Reject/EAP-Start
      Access-Challenge/EAP-Message/EAP Success
      Access-Challenge/EAP-Message/EAP Failure
      Access-Challenge/no EAP-Message attribute
      Access-Challenge/EAP-Start

   Since the responsibility for avoiding conflicts lies with the RADIUS
   server, the NAS MUST NOT "manufacture" EAP packets in order to
   correct contradictory messages that it receives.  This behavior,
   originally mandated within [IEEE8021X], will be deprecated in the
   future.

2.6.4.  Priority

   A RADIUS Access-Accept or Access-Reject packet may contain EAP-
   Message attribute(s). In order to ensure the correct processing of
   RADIUS packets, the NAS MUST first process the attributes, including
   the EAP-Message attribute(s), prior to processing the Accept/Reject
   indication.

2.6.5.  Displayable Messages

   The Reply-Message attribute, defined in [RFC2865], Section 5.18,
   indicates text which may be displayed to the peer.  This is similar
   in concept to EAP Notification, defined in [RFC2284].  When sending a
   displayable message to a NAS during an EAP conversation, the RADIUS
   server MUST encapsulate displayable messages within
   EAP-Message/EAP-Request/Notification attribute(s).  Reply-Message
   attribute(s) MUST NOT be included in any RADIUS message containing an
   EAP-Message attribute.  An EAP-Message/EAP-Request/Notification
   SHOULD NOT be included within an Access-Accept or Access-Reject
   packet.

   In some existing implementations, a NAS receiving Reply-Message
   attribute(s) copies the Text field(s) into the Type-Data field of an
   EAP-Request/Notification packet, fills in the Identifier field, and
   sends this to the peer.  However, several issues arise from this:






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


   [1]  Unexpected Responses.  On receiving an EAP-Request/Notification,
        the peer will send an EAP-Response/Notification, and the NAS
        will pass this on to the RADIUS server, encapsulated within
        EAP-Message attribute(s).  However, the RADIUS server may not be
        expecting an Access-Request containing an
        EAP-Message/EAP-Response/Notification attribute.

        For example, consider what happens when a Reply-Message is
        included within an Access-Accept or Access-Reject packet with no
        EAP-Message attribute(s) present.  If the value of the
        Reply-Message attribute is copied into the Type-Data of an
        EAP-Request/Notification and sent to the peer, this will result
        in an Access-Request containing an
        EAP-Message/EAP-Response/Notification attribute being sent by
        the NAS to the RADIUS server.  Since an Access-Accept or
        Access-Reject packet terminates the RADIUS conversation, such an
        Access-Request would not be expected, and could be interpreted
        as the start of another conversation.

   [2]  Identifier conflicts.  While the EAP-Request/Notification is an
        EAP packet containing an Identifier field, the Reply-Message
        attribute does not contain an Identifier field.  As a result, a
        NAS receiving a Reply-Message attribute and wishing to translate
        this to an EAP-Request/Notification will need to choose an
        Identifier value.  It is possible that the chosen Identifier
        value will conflict with a value chosen by the RADIUS server for
        another packet within the EAP conversation, potentially causing
        confusion between a new packet and a retransmission.

   To avoid these problems, a NAS receiving a Reply-Message attribute
   from the RADIUS server SHOULD silently discard the attribute, rather
   than attempting to translate it to an EAP Notification Request.

3.  Attributes

   The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS
   in Access-Request packets, and either NAS-Identifier, NAS-IP-Address
   or NAS-IPv6-Address attributes MUST be included.  In order to permit
   forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name
   attribute was included in an Access-Request, the RADIUS server MUST
   include the User-Name attribute in subsequent Access-Accept packets.
   Without the User-Name attribute, accounting and billing becomes
   difficult to manage.  The User-Name attribute within the Access-
   Accept packet need not be the same as the User-Name attribute in the
   Access-Request.






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


3.1.  EAP-Message

   Description

      This attribute encapsulates EAP [RFC2284] packets so as to allow
      the NAS to authenticate peers via EAP without having to understand
      the EAP method it is passing through.

      The NAS places EAP messages received from the authenticating peer
      into one or more EAP-Message attributes and forwards them to the
      RADIUS server within an Access-Request message.  If multiple
      EAP-Message attributes are contained within an Access-Request or
      Access-Challenge packet, they MUST be in order and they MUST be
      consecutive attributes in the Access-Request or Access-Challenge
      packet.  The RADIUS server can return EAP-Message attributes in
      Access-Challenge, Access-Accept and Access-Reject packets.

      When RADIUS is used to enable EAP authentication, Access-Request,
      Access-Challenge, Access-Accept, and Access-Reject packets SHOULD
      contain one or more EAP-Message attributes.  Where more than one
      EAP-Message attribute is included, it is assumed that the
      attributes are to be concatenated to form a single EAP packet.

      Multiple EAP packets MUST NOT be encoded within EAP-Message
      attributes contained within a single Access-Challenge,
      Access-Accept, Access-Reject or Access-Request packet.

      It is expected that EAP will be used to implement a variety of
      authentication methods, including methods involving strong
      cryptography.  In order to prevent attackers from subverting EAP
      by attacking RADIUS/EAP, (for example, by modifying EAP Success or
      EAP Failure packets) it is necessary that RADIUS provide
      per-packet authentication and integrity protection.

      Therefore the Message-Authenticator attribute MUST be used to
      protect all Access-Request, Access-Challenge, Access-Accept, and
      Access-Reject packets containing an EAP-Message attribute.

      Access-Request packets including EAP-Message attribute(s) without
      a Message-Authenticator attribute SHOULD be silently discarded by
      the RADIUS server.  A RADIUS server supporting the EAP-Message
      attribute MUST calculate the correct value of the
      Message-Authenticator and MUST silently discard the packet if it
      does not match the value sent.  A RADIUS server not supporting the
      EAP-Message attribute MUST return an Access-Reject if it receives
      an Access-Request containing an EAP-Message attribute.





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


      Access-Challenge, Access-Accept, or Access-Reject packets
      including EAP-Message attribute(s) without a Message-Authenticator
      attribute SHOULD be silently discarded by the NAS.  A NAS
      supporting the EAP-Message attribute MUST calculate the correct
      value of the Message-Authenticator and MUST silently discard the
      packet if it does not match the value sent.

      A summary of the EAP-Message 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

      79 for EAP-Message

   Length

      >= 3