rfc3748.txt

使用最广泛的radius的linux的源码

       Typically, the EAP peer obtains information on the EAP MTU from
       the lower layers and sets the EAP frame size to an appropriate
       value.  Where the authenticator operates in pass-through mode,
       the authentication server does not have a direct way of
       determining the EAP MTU, and therefore relies on the
       authenticator to provide it with this information, such as via
       the Framed-MTU attribute, as described in [RFC3579], Section 2.4.





Aboba, et al.               Standards Track                    [Page 16]

RFC 3748                          EAP                          June 2004


       While methods such as EAP-TLS [RFC2716] support fragmentation and
       reassembly, EAP methods originally designed for use within PPP
       where a 1500 octet MTU is guaranteed for control frames (see
       [RFC1661], Section 6.1) may lack fragmentation and reassembly
       features.

       EAP methods can assume a minimum EAP MTU of 1020 octets in the
       absence of other information.  EAP methods SHOULD include support
       for fragmentation and reassembly if their payloads can be larger
       than this minimum EAP MTU.

       EAP is a lock-step protocol, which implies a certain inefficiency
       when handling fragmentation and reassembly.  Therefore, if the
       lower layer supports fragmentation and reassembly (such as where
       EAP is transported over IP), it may be preferable for
       fragmentation and reassembly to occur in the lower layer rather
       than in EAP.  This can be accomplished by providing an
       artificially large EAP MTU to EAP, causing fragmentation and
       reassembly to be handled within the lower layer.

   [5] Possible duplication.  Where the lower layer is reliable, it will
       provide the EAP layer with a non-duplicated stream of packets.
       However,  while it is desirable that lower layers provide for
       non-duplication, this is not a requirement.  The Identifier field
       provides both the peer and authenticator with the ability to
       detect duplicates.

   [6] Ordering guarantees.  EAP does not require the Identifier to be
       monotonically increasing, and so is reliant on lower layer
       ordering guarantees for correct operation.  EAP was originally
       defined to run on PPP, and [RFC1661] Section 1 has an ordering
       requirement:

           "The Point-to-Point Protocol is designed for simple links
           which transport packets between two peers.  These links
           provide full-duplex simultaneous bi-directional operation,
           and are assumed to deliver packets in order."

       Lower layer transports for EAP MUST preserve ordering between a
       source and destination at a given priority level (the ordering
       guarantee provided by [IEEE-802]).

       Reordering, if it occurs, will typically result in an EAP
       authentication failure, causing EAP authentication to be re-run.
       In an environment in which reordering is likely, it is therefore
       expected that EAP authentication failures will be common.  It is
       RECOMMENDED that EAP only be run over lower layers that provide
       ordering guarantees; running EAP over raw IP or UDP transport is



Aboba, et al.               Standards Track                    [Page 17]

RFC 3748                          EAP                          June 2004


       NOT RECOMMENDED.  Encapsulation of EAP within RADIUS [RFC3579]
       satisfies ordering requirements, since RADIUS is a "lockstep"
       protocol that delivers packets in order.

3.2.  EAP Usage Within PPP

   In order to establish communications over a point-to-point link, each
   end of the PPP link first sends LCP packets to configure the data
   link during the Link Establishment phase.  After the link has been
   established, PPP provides for an optional Authentication phase before
   proceeding to the Network-Layer Protocol phase.

   By default, authentication is not mandatory.  If authentication of
   the link is desired, an implementation MUST specify the
   Authentication Protocol Configuration Option during the Link
   Establishment phase.

   If the identity of the peer has been established in the
   Authentication phase, the server can use that identity in the
   selection of options for the following network layer negotiations.

   When implemented within PPP, EAP does not select a specific
   authentication mechanism at the PPP Link Control Phase, but rather
   postpones this until the Authentication Phase.  This allows the
   authenticator to request more information before determining the
   specific authentication mechanism.  This also permits the use of a
   "backend" server which actually implements the various mechanisms
   while the PPP authenticator merely passes through the authentication
   exchange.  The PPP Link Establishment and Authentication phases, and
   the Authentication Protocol Configuration Option, are defined in The
   Point-to-Point Protocol (PPP) [RFC1661].

3.2.1.  PPP Configuration Option Format

   A summary of the PPP Authentication Protocol Configuration Option
   format to negotiate EAP follows.  The fields are transmitted from
   left to right.

   Exactly one EAP packet is encapsulated in the Information field of a
   PPP Data Link Layer frame where the protocol field indicates type hex
   C227 (PPP EAP).










Aboba, et al.               Standards Track                    [Page 18]

RFC 3748                          EAP                          June 2004


    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     |     Authentication Protocol   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      3

   Length

      4

   Authentication Protocol

      C227 (Hex) for Extensible Authentication Protocol (EAP)

3.3.  EAP Usage Within IEEE 802

   The encapsulation of EAP over IEEE 802 is defined in [IEEE-802.1X].
   The IEEE 802 encapsulation of EAP does not involve PPP, and IEEE
   802.1X does not include support for link or network layer
   negotiations.  As a result, within IEEE 802.1X, it is not possible to
   negotiate non-EAP authentication mechanisms, such as PAP or CHAP
   [RFC1994].

3.4.  Lower Layer Indications

   The reliability and security of lower layer indications is dependent
   on the lower layer.  Since EAP is media independent, the presence or
   absence of lower layer security is not taken into account in the
   processing of EAP messages.

   To improve reliability, if a peer receives a lower layer success
   indication as defined in Section 7.2, it MAY conclude that a Success
   packet has been lost, and behave as if it had actually received a
   Success packet.  This includes choosing to ignore the Success in some
   circumstances as described in Section 4.2.

   A discussion of some reliability and security issues with lower layer
   indications in PPP, IEEE 802 wired networks, and IEEE 802.11 wireless
   LANs can be found in the Security Considerations, Section 7.12.

   After EAP authentication is complete, the peer will typically
   transmit and receive data via the authenticator.  It is desirable to
   provide assurance that the entities transmitting data are the same
   ones that successfully completed EAP authentication.  To accomplish



Aboba, et al.               Standards Track                    [Page 19]

RFC 3748                          EAP                          June 2004


   this, it is necessary for the lower layer to provide per-packet
   integrity, authentication and replay protection, and to bind these
   per-packet services to the keys derived during EAP authentication.
   Otherwise, it is possible for subsequent data traffic to be modified,
   spoofed, or replayed.

   Where keying material for the lower layer ciphersuite is itself
   provided by EAP, ciphersuite negotiation and key activation are
   controlled by the lower layer.  In PPP, ciphersuites are negotiated
   within ECP so that it is not possible to use keys derived from EAP
   authentication until the completion of ECP.  Therefore, an initial
   EAP exchange cannot be protected by a PPP ciphersuite, although EAP
   re-authentication can be protected.

   In IEEE 802 media, initial key activation also typically occurs after
   completion of EAP authentication.  Therefore an initial EAP exchange
   typically cannot be protected by the lower layer ciphersuite,
   although an EAP re-authentication or pre-authentication exchange can
   be protected.

4.  EAP Packet Format

   A summary of the EAP packet format 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+

   Code

      The Code field is one octet and identifies the Type of EAP packet.
      EAP Codes are assigned as follows:

         1       Request
         2       Response
         3       Success
         4       Failure

      Since EAP only defines Codes 1-4, EAP packets with other codes
      MUST be silently discarded by both authenticators and peers.






Aboba, et al.               Standards Track                    [Page 20]

RFC 3748                          EAP                          June 2004


   Identifier

      The Identifier field is one octet and aids in matching Responses
      with Requests.

   Length

      The Length field is two octets and indicates the length, in
      octets, of the EAP packet including the Code, Identifier, Length,
      and Data fields.  Octets outside the range of the Length field
      should be treated as Data Link Layer padding and MUST be ignored
      upon reception.  A message with the Length field set to a value
      larger than the number of received octets MUST be silently
      discarded.

   Data

      The Data field is zero or more octets.  The format of the Data
      field is determined by the Code field.

4.1.  Request and Response

   Description

      The Request packet (Code field set to 1) is sent by the
      authenticator to the peer.  Each Request has a Type field which
      serves to indicate what is being requested.  Additional Request
      packets MUST be sent until a valid Response packet is received, an
      optional retry counter expires, or a lower layer failure
      indication is received.

      Retransmitted Requests MUST be sent with the same Identifier value
      in order to distinguish them from new Requests.  The content of
      the data field is dependent on the Request Type.  The peer MUST
      send a Response packet in reply to a valid Request packet.
      Responses MUST only be sent in reply to a valid Request and never
      be retransmitted on a timer.

      If a peer receives a valid duplicate Request for which it has
      already sent a Response, it MUST resend its original Response
      without reprocessing the Request.  Requests MUST be processed in
      the order that they are received, and MUST be processed to their
      completion before inspecting the next Request.

   A summary of the Request and Response packet format follows.  The
   fields are transmitted from left to right.





Aboba, et al.               Standards Track                    [Page 21]

RFC 3748                          EAP                          June 2004