rfc2716.txt

radius服务器

Aboba & Simon                 Experimental                      [Page 6]

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


   Since EAP is a simple ACK-NAK 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-TLS fragmentation support is provided through addition of a flags
   octet 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-TLS 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-TLS 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 buffer
   allocation.

   When an EAP-TLS peer receives an EAP-Request packet with the M bit
   set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS 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-Reponse.
   Retransmitted fragments will contain the same Identifier value.

   Similarly, when the EAP server receives an EAP-Response with the M
   bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS
   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 use 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-
   Reponse.

3.4.  Identity verification

   As part of the TLS negotiation, the server presents a certificate to
   the peer, and if mutual authentication is requested, the peer
   presents a certificate to the server.

   Note that since the peer has made a claim of identity in the EAP-
   Response/Identity (MyID) packet, the EAP server SHOULD verify that
   the claimed identity corresponds to the certificate presented by the



Aboba & Simon                 Experimental                      [Page 7]

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


   peer.  Typically this will be accomplished either by placing the
   userId within the peer certificate, or by providing a mapping between
   the peer certificate and the userId using a directory service.

   Similarly, the peer MUST verify the validity of the EAP server
   certificate, and SHOULD also examine the EAP server name presented in
   the certificate, in order to determine whether the EAP server can be
   trusted. Please note that in the case where the EAP authentication is
   remoted that the EAP server will not reside on the same machine as
   the authenticator, and therefore the name in the EAP server's
   certificate cannot be expected to match that of the intended
   destination. In this case, a more appropriate test might be whether
   the EAP server's certificate is signed by a CA controlling the
   intended destination and whether the EAP server exists within a
   target sub-domain.

3.5.  Key derivation

   Since the normal TLS keys are used in the handshake, and therefore
   should not be used in a different context, new encryption keys must
   be derived from the TLS master secret for use with PPP encryption.
   For both peer and EAP server, the derivation proceeds as follows:
   given the master secret negotiated by the TLS handshake, the
   pseudorandom function (PRF) defined in the specification for the
   version of TLS in use, and the value random defined as the
   concatenation of the handshake message fields client_hello.random and
   server_hello.random (in that order), the value PRF(master secret,
   "client EAP encryption", random) is computed up to 128 bytes, and the
   value PRF("", "client EAP encryption", random) is computed up to 64
   bytes (where "" is an empty string).  The peer encryption key (the
   one used for encrypting data from peer to EAP server) is obtained by
   truncating to the correct length the first 32 bytes of the first PRF
   of these two output strings.  TheEAP server encryption key (the one
   used for encrypting data from EAP server to peer), if different from
   the client encryption key, is obtained by truncating to the correct
   length the second 32 bytes of this same PRF output string.  The
   client authentication key (the one used for computing MACs for
   messages from peer to EAP server), if used, is obtained by truncating
   to the correct length the third 32 bytes of this same PRF output
   string.  The EAP server authentication key (the one used for
   computing MACs for messages from EAP server to peer), if used, and if
   different from the peer authentication key, is obtained by truncating
   to the correct length the fourth 32 bytes of this same PRF output
   string.  The peer initialization vector (IV), used for messages from
   peer to EAP server if a block cipher has been specified, is obtained
   by truncating to the cipher's block size the first 32 bytes of the
   second PRF output string mentioned above.  Finally, the server
   initialization vector (IV), used for messages from peer to EAP server



Aboba & Simon                 Experimental                      [Page 8]

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


   if a block cipher has been specified, is obtained by truncating to
   the cipher's block size the second 32 bytes of this second PRF
   output.

   The use of these encryption and authentication keys is specific to
   the PPP encryption mechanism used, such as those defined in [9] and
   [10].  Additional keys or other non-secret values (such as IVs) can
   be obtained as needed for future PPP encryption methods by extending
   the outputs of the PRF beyond 128 bytes and 64 bytes, respectively.

3.6.  ECP negotiation

   Since TLS supports ciphersuite negotiation, peers completing the TLS
   negotiation will also have selected a ciphersuite, which includes key
   strength, encryption and hashing methods. As a result, a subsequent
   Encryption Control Protocol (ECP) conversation, if it occurs, has a
   predetermined result.

   In order to ensure agreement between the EAP-TLS ciphersuite
   negotiation and the subsequent ECP negotiation (described in [6]),
   during ECP negotiation the PPP peer MUST offer only the ciphersuite
   negotiated inEAP-TLS.  This ensures that the PPP authenticator MUST
   accept the EAP-TLS negotiated ciphersuite in order for the
   onversation to proceed.  Should the authenticator not accept the
   EAP-TLS negotiated ciphersuite, then the peer MUST send an LCP
   terminate and disconnect.

   Please note that it cannot be assumed that the PPP authenticator and
   EAP server are located on the same machine or that the authenticator
   understands the EAP-TLS conversation that has passed through it. Thus
   if the peer offers a ciphersuite other than the one negotiated in
   EAP-TLS there is no way for the authenticator to know how to respond
   correctly.

3.7.  CCP negotiation

   TLS as described in [12] supports compression as well as ciphersuite
   negotiation. However, TLS only provides support for a limited number
   of compression types which do not overlap with the compression types
   used in PPP. As a result, during the EAP-TLS conversation the EAP
   endpoints MUST NOT request or negotiate compression. Instead, the PPP
   Compression Control Protocol (CCP), described in [13] should be used
   to negotiate the desired compression scheme.








Aboba & Simon                 Experimental                      [Page 9]

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


3.8.  Examples

   In the case where the EAP-TLS mutual authentication is successful,
   the conversation will appear as follows:

   Authenticating Peer     Authenticator
   -------------------     -------------
                           <- PPP LCP Request-EAP
                           auth
   PPP LCP ACK-EAP
   auth ->
                           <- PPP EAP-Request/
                           Identity
   PPP EAP-Response/
   Identity (MyID) ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS Start)
   PPP EAP-Response/
   EAP-Type=EAP-TLS
   (TLS client_hello)->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS server_hello,
                            TLS certificate,
                    [TLS server_key_exchange,]
                    [TLS certificate_request,]
                        TLS server_hello_done)
   PPP EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
    TLS client_key_exchange,
   [TLS certificate_verify,]
    TLS change_cipher_spec,
    TLS finished) ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS change_cipher_spec,
                            TLS finished)
   PPP EAP-Response/
   EAP-Type=EAP-TLS ->
                           <- PPP EAP-Success
   PPP Authentication
   Phase complete,
   NCP Phase starts

   ECP negotiation
   CCP negotiation



Aboba & Simon                 Experimental                     [Page 10]

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


   In the case where the EAP-TLS mutual authentication is successful,
   and fragmentation is required, the conversation will appear as
   follows:

   Authenticating Peer     Authenticator
   -------------------     -------------
                           <- PPP LCP Request-EAP
                           auth
   PPP LCP ACK-EAP
   auth ->
                           <- PPP EAP-Request/
                           Identity
   PPP EAP-Response/
   Identity (MyID) ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS Start, S bit set)
   PPP EAP-Response/
   EAP-Type=EAP-TLS
   (TLS client_hello)->
                           <- PPP EAP-Request/
                              EAP-Type=EAP-TLS
                             (TLS server_hello,
                               TLS certificate,
                     [TLS server_key_exchange,]
                     [TLS certificate_request,]
                         TLS server_hello_done)
                    (Fragment 1: L, M bits set)
   PPP EAP-Response/
   EAP-Type=EAP-TLS ->
                           <- PPP EAP-Request/
                              EAP-Type=EAP-TLS
                           (Fragment 2: M bit set)
   PPP EAP-Response/
   EAP-Type=EAP-TLS ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-TLS
                           (Fragment 3)
   PPP EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
    TLS client_key_exchange,
   [TLS certificate_verify,]
    TLS change_cipher_spec,
    TLS inished)(Fragment 1:
    L, M bits set)->
                            <- PPP EAP-Request/
                           EAP-Type=EAP-TLS



Aboba & Simon                 Experimental                     [Page 11]

RFC 2716          PPP EAP TLS Authentication Protocol       October 1999


   PPP EAP-Response/
   EAP-Type=EAP-TLS
   (Fragment 2)->
                          <- PPP EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS change_cipher_spec,
                            TLS finished)
   PPP EAP-Response/
   EAP-Type=EAP-TLS ->
                           <- PPP EAP-Success
   PPP Authentication
   Phase complete,
   NCP Phase starts

   ECP negotiation
   CCP negotiation

   In the case where the server authenticates to the client
   successfully, but the client fails to authenticate to the server, the
   conversation will appear as follows:

   Authenticating Peer     Authenticator
   -------------------     -------------
                           <- PPP LCP Request-EAP
                           auth
   PPP LCP ACK-EAP
   auth ->
                           <- PPP EAP-Request/
                           Identity
   PPP EAP-Response/
   Identity (MyID) ->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS Start)
   PPP EAP-Response/
   EAP-Type=EAP-TLS
   (TLS client_hello)->
                           <- PPP EAP-Request/
                           EAP-Type=EAP-TLS
                           (TLS server_hello,
                            TLS certificate,
                    [TLS server_key_exchange,]
                           TLS certificate_request,
                           TLS server_hello_done)
   PPP EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
    TLS client_key_exchange,



Aboba & Simon                 Experimental                     [Page 12]