order to facilitate the fall back to a full handshake the peer SHOULD
   include ciphersuites that allow for a full handshake and possibly PAC
   provisioning so the server can select one of this in case session
   resumption fails.  An example of the transition is shown in
   Appendix A.

3.3  EAP-FAST Authentication Phase 2: Tunneled Authentication

   The second portion of the EAP-FAST Authentication occurs immediately
   after successful completion of phase 1.  Phase 2 occurs even if both
   peer and authenticator are authenticated in the phase 1 TLS
   negotiation.  Phase 2 MUST NOT occur if the Phase 1 TLS handshake
   fails.  Phase 2 consists of a series of requests and responses formed
   of TLV objects defined in Section 4.2.  Phase 2 MUST always end with
   a protected termination exchange described in Section 3.3.2.  The TLV
   exchange may include the execution of zero or more EAP methods within
   the protected tunnel as described in Section 3.3.1.  A server MAY
   proceed directly to the protected termination exchange if it does not
   wish to request further authentication from the peer.  However, the
   peer and server must not assume that either will skip inner EAP
   methods or other TLV exchanges.  The peer may have roamed to a
   network which requires conformance with a different authentication
   policy or the peer may request the server take additional action
   through the use of the Request-Action TLV.

3.3.1  EAP Sequences

   EAP [RFC3748] prohibits use of multiple authentication methods within
   a single EAP conversation in order to limit vulnerabilities to man-
   in-the-middle attacks.  EAP-FAST addresses man-in-the-middle attacks
   through support for cryptographic protection of the inner EAP
   exchange and cryptographic binding of the inner authentication method
   to the protected tunnel.  EAP methods are executed serially in a
   sequence.  This version of EAP-FAST does not support initiating
   multiple EAP methods simultaneously in parallel.  The methods need
   not be distinct.  For example, EAP-TLS could be run twice as an inner
   method, initially with machine credentials followed by user
   credentials.

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.6.  Upon method completion of a method a server MUST send
   an Intermediate-Result TLV indicating the result.  The peer MUST
   respond to the Intermediate-Result TLV indicating its result.  If the
   result indicates success the Intermediate-Result TLV MUST be
   accompanied by a Crypto-Binding TLV.  The Crypto-Binding TLV is



Cam-Winget, et al.       Expires April 22, 2006                [Page 12]

Internet-Draft                  EAP-FAST                    October 2005


   further discussed in Section 4.2.8 and Section 5.3.  The
   Intermediate-Result TLVs can be included with other TLVs such as EAP-
   Payload TLVs starting a new EAP conversation or with the Result TLV
   used in the protected termination exchange.

   If both peer and server indicate success then the method is
   considered to have completed.  If either indicates failure then the
   method is considered to have failed.  The result of failure of a EAP
   method does not always imply a failure of the overall authentication.
   If one authentication method fails the server may attempt to
   authenticate the peer with a different method.

3.3.2  Protected Termination and Acknowledged Result Indication

   A successful EAP-FAST phase 2 conversation MUST always end in a
   successful Result TLV exchange.  An EAP-FAST server may initiate the
   Result TLV exchange without initiating any EAP conversation in EAP-
   FAST Phase 2.  After the final Result TLV exchange the TLS tunnel is
   terminated and a clear text EAP-Success or EAP-Failure is sent by the
   server.  The format of the Result TLV is described in Section 4.2.2.

   A server initiates a successful protected termination exchange by
   sending a Result TLV indicating success.  The server may send the
   Result TLV along with an Intermediate-Result TLV and a Crypto-Binding
   TLV.  If the peer requires nothing more from the server it will
   respond with a Result TLV indicating success accompanied by an
   Intermediate-Result TLV and Crypto-Binding TLV if necessary.  The
   server then tears down the tunnel and sends a clear text EAP-Success.

   If the peer receives a Result TLV indicating success from the server,
   but its authentication policies are not satisfied (for example it
   requires a particular authentication mechanism be run or it wants to
   request a PAC) it may request further action from the server using
   the Request-Action TLV.  The Request-Action TLV is sent along with
   the Result TLV indicating what EAP Success/Failure result peer would
   expect if the requested action is not granted.  The value of the
   Request-Action TLV indicates what the peer would like to do next.
   The format and values for the Request-Action TLV are defined in
   Section 4.2.9.

   Upon receiving the Request-Action TLV the server may process the
   request or ignore it, based on its policy.  If the server ignores the
   request, it proceeds with termination of the tunnel and send the
   clear text EAP Success or Failure message based on the value of the
   peer's result TLV.  If server honors and processes the request, it
   continues with the requested action.  The conversation completes with
   a Result TLV exchange.  The Result TLV may be included with the TLV
   that completes the requested action.



Cam-Winget, et al.       Expires April 22, 2006                [Page 13]

Internet-Draft                  EAP-FAST                    October 2005


   Error handling for phase 2 is discussed in Section 3.4.2.

3.4  Error Handling

   EAP-FAST uses the following error handling rules summarized below:

   1.  Errors in TLS layer are communicated via TLS alert messages in
       all phases of EAP-FAST.
   2.  The Intermediate-Result TLVs indicate success or failure
       indications of the individual EAP methods in EAP-FAST Phase 2.
       Errors within the EAP conversation in Phase 2 are expected to be
       handled by individual EAP methods.
   3.  Violations of the TLV rules are handled using Result TLVs
       together with Error TLVs.
   4.  Tunnel compromised errors (errors caused by Crypto-Binding failed
       or missing) are handled using Result TLVs and Error TLVs.

3.4.1  TLS Layer Errors

   If the EAP-FAST server detects an error at any point in the TLS
   Handshake or the TLS layer, the server SHOULD send an EAP-FAST
   request encapsulating a TLS record containing the appropriate TLS
   alert message rather than immediately terminating the conversation so
   as to allow the peer to inform the user of the cause of the failure
   and possibly allow for a restart of the conversation.  The peer MUST
   send an EAP-FAST response to an alert message.  The EAP-Response
   packet sent by the peer may encapsulate a TLS ClientHello handshake
   message, in which case the EAP-FAST server MAY allow the EAP-FAST
   conversation to be restarted, or it MAY contain an EAP-FAST response
   with a zero length message, in which case the server MUST terminate
   the conversation with an EAP-Failure packet.  It is up to the EAP-
   FAST server whether to allow restarts, and if so, how many times the
   conversation can be restarted.  An EAP-FAST Server implementing
   restart capability SHOULD impose a limit on the number of restarts,
   so as to protect against denial of service attacks.

   If the EAP-FAST peer detects an error at any point in the TLS layer,
   the EAP-FAST peer should send an EAP-FAST response encapsulating a
   TLS record containing the appropriate TLS alert message.  The server
   may restart the conversation by sending an EAP-FAST request packet
   encapsulating the TLS HelloRequest handshake message.  The peer may
   allow the EAP-FAST conversation to be restarted or it may terminate
   the conversation by sending an EAP-FAST response with an zero length
   message.

3.4.2  Phase 2 Errors

   Any time the peer or the server finds a fatal error outside of the



Cam-Winget, et al.       Expires April 22, 2006                [Page 14]

Internet-Draft                  EAP-FAST                    October 2005


   TLS layer during phase 2 TLV processing it MUST send a Result TLV of
   failure and an Error TLV with the appropriate error code.  For errors
   involving the processing the sequence of exchanges, such as a
   violation of TLV rules (e.g., multiple EAP-Payload TLVs) the error
   code is Unexpected_TLVs_Exchanged.  For errors involving a tunnel
   compromise the error-code is Tunnel_Compromise_Error.  Upon sending a
   Result TLV with a fatal Error TLV the sender terminates the TLS
   tunnel.

   If a server receives a Result TLV of failure with a fatal Error TLV
   it SHOULD send a clear text EAP-Failure.  If a peer receives a Result
   TLV of failure it MUST respond with a Result TLV indicating failure.
   If the server has sent a Result TLV of failure it ignores the peer
   response and it SHOULD send a clear text EAP-Failure.

3.5  Fragmentation

   A single TLS record may be up to 16384 octets in length, but a TLS
   message may span multiple TLS records, and a TLS certificate message
   may in principle be as long as 16MB.  This is larger than the maximum
   size for a message on most media types, therefore it is desirable to
   support fragmentation.  Note that in order to protect against
   reassembly lockup and denial of service attacks, it may be desirable
   for an implementation to set a maximum size for one such group of TLS
   messages.  Since a typical certificate chain is rarely longer than a
   few thousand octets, and no other field is likely to be anywhere near
   as long, a reasonable choice of maximum acceptable message length
   might be 64 KB.  This is still a fairly large message packet size so
   an EAP-FAST implementation MUST provide its own support for
   fragmentation and reassembly.

   Since EAP is an lock-step protocol, fragmentation support can be
   added in a simple manner.  In EAP, fragments that are lost or damaged
   in transit will be retransmitted, and since sequencing information is
   provided by the Identifier field in EAP, there is no need for a
   fragment offset field as is provided in IPv4.

   EAP-FAST fragmentation support is provided through addition of flag
   bits within the EAP-Response and EAP-Request packets, as well as a
   TLS Message Length field of four octets.  Flags include the Length
   included (L), More fragments (M), and EAP-FAST Start (S) bits.  The L
   flag is set to indicate the presence of the four octet TLS Message
   Length field, and MUST be set for the first fragment of a fragmented
   TLS message or set of messages.  The M flag is set on all but the
   last fragment.  The S flag is set only within the EAP-FAST start
   message sent from the EAP server to the peer.  The TLS Message Length
   field is four octets, and provides the total length of the TLS
   message or set of messages that is being fragmented; this simplifies



Cam-Winget, et al.       Expires April 22, 2006                [Page 15]

Internet-Draft                  EAP-FAST                    October 2005


   buffer allocation.

   When an EAP-FAST peer receives an EAP-Request packet with the M bit
   set, it MUST respond with an EAP-Response with EAP-Type of EAP-FAST
   and no data.  This serves as a fragment ACK.  The EAP server must
   wait until it receives the EAP-Response before sending another
   fragment.  In order to prevent errors in processing of fragments, the
   EAP server MUST increment the Identifier field for each fragment
   contained within an EAP-Request, and the peer must include this
   Identifier value in the fragment ACK contained within the EAP-
   Response.  Retransmitted fragments will contain the same Identifier
   value.

   Similarly, when the EAP-FAST server receives an EAP-Response with the
   M bit set, it must respond with an EAP-Request with EAP-Type of EAP-
   FAST and no data.  This serves as a fragment ACK.  The EAP peer MUST
   wait until it receives the EAP-Request before sending another
   fragment.  In order to prevent errors in the processing of fragments,
   the EAP server MUST increment the Identifier value for each fragment
   ACK contained within an EAP-Request, and the peer MUST include this
   Identifier value in the subsequent fragment contained within an EAP-
   Response.

4.  Message Formats

   The following sections describe the message formats used in EAP-FAST.
   The fields are transmitted from left to right in network byte order.

4.1  EAP-FAST Message Format

   A summary of the EAP-FAST Request/Response packet format is shown
   below.

    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      |   Flags | Ver |        Message Length         +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Message Length        |           Data...             +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+









Cam-Winget, et al.       Expires April 22, 2006                [Page 16]

Internet-Draft                  EAP-FAST                    October 2005


      Code

         1  Request
         2  Response

      Identifier

         The Identifier field is one octet and aids in matching
         responses with requests.  The Identifier field MUST be changed
         on each Request packet.  The Identifier field in the Response
         packet MUST match the Identifier field from the corresponding
         request.

      Length

         The Length field is two octets and indicates the length of the
         EAP packet including the Code, Identifier, Length, Type, Flags,
         Ver, Message Length and Data fields.  Octets outside the range
         of the Length field should be treated as Data Link Layer
         padding and should be ignored on reception.

      Type

         43 for EAP-FAST

      Flags

          0 1 2 3 4
         +-+-+-+-+-+
         |L M S R R|
         +-+-+-+-+-+

         L  Length included
         M  More fragments