rfc3748.txt

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

    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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Type-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      1 for Request
      2 for Response

   Identifier

      The Identifier field is one octet.  The Identifier field MUST be
      the same if a Request packet is retransmitted due to a timeout
      while waiting for a Response.  Any new (non-retransmission)
      Requests MUST modify the Identifier field.

      The Identifier field of the Response MUST match that of the
      currently outstanding Request.  An authenticator receiving a
      Response whose Identifier value does not match that of the
      currently outstanding Request MUST silently discard the Response.

      In order to avoid confusion between new Requests and
      retransmissions, the Identifier value chosen for each new Request
      need only be different from the previous Request, but need not be
      unique within the conversation.  One way to achieve this is to
      start the Identifier at an initial value and increment it for each
      new Request.  Initializing the first Identifier with a random
      number rather than starting from zero is recommended, since it
      makes sequence attacks somewhat more difficult.

      Since the Identifier space is unique to each session,
      authenticators are not restricted to only 256 simultaneous
      authentication conversations.  Similarly, with re-authentication,
      an EAP conversation might continue over a long period of time, and
      is not limited to only 256 roundtrips.

   Implementation Note: The authenticator is responsible for
   retransmitting Request messages.  If the Request message is obtained
   from elsewhere (such as from a backend authentication server), then
   the authenticator will need to save a copy of the Request in order to
   accomplish this.  The peer is responsible for detecting and handling
   duplicate Request messages before processing them in any way,
   including passing them on to an outside party.  The authenticator is
   also responsible for discarding Response messages with a non-matching



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


   Identifier value before acting on them in any way, including passing
   them on to the backend authentication server for verification.  Since
   the authenticator can retransmit before receiving a Response from the
   peer, the authenticator can receive multiple Responses, each with a
   matching Identifier.  Until a new Request is received by the
   authenticator, the Identifier value is not updated, so that the
   authenticator forwards Responses to the backend authentication
   server, one at a time.

   Length

      The Length field is two octets and indicates the length of the EAP
      packet including the Code, Identifier, Length, Type, and Type-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.

   Type

      The Type field is one octet.  This field indicates the Type of
      Request or Response.  A single Type MUST be specified for each EAP
      Request or Response.  An initial specification of Types follows in
      Section 5 of this document.

      The Type field of a Response MUST either match that of the
      Request, or correspond to a legacy or Expanded Nak (see Section
      5.3) indicating that a Request Type is unacceptable to the peer.
      A peer MUST NOT send a Nak (legacy or expanded) in response to a
      Request, after an initial non-Nak Response has been sent.  An EAP
      server receiving a Response not meeting these requirements MUST
      silently discard it.

   Type-Data

      The Type-Data field varies with the Type of Request and the
      associated Response.

4.2.  Success and Failure

   The Success packet is sent by the authenticator to the peer after
   completion of an EAP authentication method (Type 4 or greater) to
   indicate that the peer has authenticated successfully to the
   authenticator.  The authenticator MUST transmit an EAP packet with
   the Code field set to 3 (Success).  If the authenticator cannot
   authenticate the peer (unacceptable Responses to one or more
   Requests), then after unsuccessful completion of the EAP method in
   progress, the implementation MUST transmit an EAP packet with the



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


   Code field set to 4 (Failure).  An authenticator MAY wish to issue
   multiple Requests before sending a Failure response in order to allow
   for human typing mistakes.  Success and Failure packets MUST NOT
   contain additional data.

   Success and Failure packets MUST NOT be sent by an EAP authenticator
   if the specification of the given method does not explicitly permit
   the method to finish at that point.  A peer EAP implementation
   receiving a Success or Failure packet where sending one is not
   explicitly permitted MUST silently discard it.  By default, an EAP
   peer MUST silently discard a "canned" Success packet (a Success
   packet sent immediately upon connection).  This ensures that a rogue
   authenticator will not be able to bypass mutual authentication by
   sending a Success packet prior to conclusion of the EAP method
   conversation.

   Implementation Note: Because the Success and Failure packets are not
   acknowledged, they are not retransmitted by the authenticator, and
   may be potentially lost.  A peer MUST allow for this circumstance as
   described in this note.  See also Section 3.4 for guidance on the
   processing of lower layer success and failure indications.

   As described in Section 2.1, only a single EAP authentication method
   is allowed within an EAP conversation.  EAP methods may implement
   result indications.  After the authenticator sends a failure result
   indication to the peer, regardless of the response from the peer, it
   MUST subsequently send a Failure packet.  After the authenticator
   sends a success result indication to the peer and receives a success
   result indication from the peer, it MUST subsequently send a Success
   packet.

   On the peer, once the method completes unsuccessfully (that is,
   either the authenticator sends a failure result indication, or the
   peer decides that it does not want to continue the conversation,
   possibly after sending a failure result indication), the peer MUST
   terminate the conversation and indicate failure to the lower layer.
   The peer MUST silently discard Success packets and MAY silently
   discard Failure packets.  As a result, loss of a Failure packet need
   not result in a timeout.

   On the peer, after success result indications have been exchanged by
   both sides, a Failure packet MUST be silently discarded.  The peer
   MAY, in the event that an EAP Success is not received, conclude that
   the EAP Success packet was lost and that authentication concluded
   successfully.






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


   If the authenticator has not sent a result indication, and the peer
   is willing to continue the conversation, the peer waits for a Success
   or Failure packet once the method completes, and MUST NOT silently
   discard either of them.  In the event that neither a Success nor
   Failure packet is received, the peer SHOULD terminate the
   conversation to avoid lengthy timeouts in case the lost packet was an
   EAP Failure.

   If the peer attempts to authenticate to the authenticator and fails
   to do so, the authenticator MUST send a Failure packet and MUST NOT
   grant access by sending a Success packet.  However, an authenticator
   MAY omit having the peer authenticate to it in situations where
   limited access is offered (e.g., guest access).  In this case, the
   authenticator MUST send a Success packet.

   Where the peer authenticates successfully to the authenticator, but
   the authenticator does not send a result indication, the
   authenticator MAY deny access by sending a Failure packet where the
   peer is not currently authorized for network access.

   A summary of the Success and Failure 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      3 for Success
      4 for Failure

   Identifier

      The Identifier field is one octet and aids in matching replies to
      Responses.  The Identifier field MUST match the Identifier field
      of the Response packet that it is sent in response to.

   Length

      4








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


4.3.  Retransmission Behavior

   Because the authentication process will often involve user input,
   some care must be taken when deciding upon retransmission strategies
   and authentication timeouts.  By default, where EAP is run over an
   unreliable lower layer, the EAP retransmission timer SHOULD be
   dynamically estimated.  A maximum of 3-5 retransmissions is
   suggested.

   When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as
   within [PIC]), the authenticator retransmission timer SHOULD be set
   to an infinite value, so that retransmissions do not occur at the EAP
   layer.  The peer may still maintain a timeout value so as to avoid
   waiting indefinitely for a Request.

   Where the authentication process requires user input, the measured
   round trip times may be determined by user responsiveness rather than
   network characteristics, so that dynamic RTO estimation may not be
   helpful.  Instead, the retransmission timer SHOULD be set so as to
   provide sufficient time for the user to respond, with longer timeouts
   required in certain cases, such as where Token Cards (see Section
   5.6) are involved.

   In order to provide the EAP authenticator with guidance as to the
   appropriate timeout value, a hint can be communicated to the
   authenticator by the backend authentication server (such as via the
   RADIUS Session-Timeout attribute).

   In order to dynamically estimate the EAP retransmission timer, the
   algorithms for the estimation of SRTT, RTTVAR, and RTO described in
   [RFC2988] are RECOMMENDED, including use of Karn's algorithm, with
   the following potential modifications:

   [a] In order to avoid synchronization behaviors that can occur with
       fixed timers among distributed systems, the retransmission timer
       is calculated with a jitter by using the RTO value and randomly
       adding a value drawn between -RTOmin/2 and RTOmin/2.  Alternative
       calculations to create jitter MAY be used.  These MUST be
       pseudo-random.  For a discussion of pseudo-random number
       generation, see [RFC1750].

   [b] When EAP is transported over a single link (as opposed to over
       the Internet), smaller values of RTOinitial, RTOmin, and RTOmax
       MAY be used.  Recommended values are RTOinitial=1 second,
       RTOmin=200ms, and RTOmax=20 seconds.






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


   [c] When EAP is transported over a single link (as opposed to over
       the Internet), estimates MAY be done on a per-authenticator
       basis, rather than a per-session basis.  This enables the
       retransmission estimate to make the most use of information on
       link-layer behavior.

   [d] An EAP implementation MAY clear SRTT and RTTVAR after backing off
       the timer multiple times, as it is likely that the current SRTT
       and RTTVAR are bogus in this situation.  Once SRTT and RTTVAR are
       cleared, they should be initialized with the next RTT sample
       taken as described in [RFC2988] equ