rfc2716.txt

radius服务器

Network Working Group                                            B. Aboba
Requests for Commments: 2716                                     D. Simon
Category: Experimental                                          Microsoft
                                                             October 1999


                  PPP EAP TLS Authentication Protocol

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1.  Abstract

   The Point-to-Point Protocol (PPP) provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.  PPP
   also defines an extensible Link Control Protocol (LCP), which can be
   used to negotiate authentication methods, as well as an Encryption
   Control Protocol (ECP), used to negotiate data encryption over PPP
   links, and a Compression Control Protocol (CCP), used to negotiate
   compression methods.  The Extensible Authentication Protocol (EAP) is
   a PPP extension that provides support for additional authentication
   methods within PPP.

   Transport Level Security (TLS) provides for mutual authentication,
   integrity-protected ciphersuite negotiation and key exchange between
   two endpoints.  This document describes how EAP-TLS, which includes
   support for fragmentation and reassembly, provides for these TLS
   mechanisms within EAP.

2.  Introduction

   The Extensible Authentication Protocol (EAP), described in [5],
   provides a standard mechanism for support of additional
   authentication methods within PPP.  Through the use of EAP, support
   for a number of authentication schemes may be added, including smart
   cards, Kerberos, Public Key, One Time Passwords, and others. To date
   however, EAP methods such as [6] have focussed on authenticating a
   client to a server.





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


   However, it may be desirable to support mutual authentication, and
   since PPP encryption protocols such as [9] and [10] assume existence
   of a session key, it is useful to have a mechanism for session key
   establishment. Since design of secure key management protocols is
   non-trivial, it is desirable to avoid creating new mechanisms for
   this. The EAP protocol described in this document allows a PPP peer
   to take advantage of the protected ciphersuite negotiation, mutual
   authentication and key management capabilities of the TLS protocol,
   described in [12].

2.1.  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [11].

3.  Protocol overview

3.1.  Overview of the EAP-TLS conversation

   As described in [5], the EAP-TLS conversation will typically begin
   with the authenticator and the peer negotiating EAP.  The
   authenticator will then typically send an EAP-Request/Identity packet
   to the peer, and the peer will respond with an EAP-Response/Identity
   packet to the authenticator, containing the peer's userId.

   From this point forward, while nominally the EAP conversation occurs
   between the PPP authenticator and the peer, the authenticator MAY act
   as a passthrough device, with the EAP packets received from the peer
   being encapsulated for transmission to a RADIUS server or backend
   security server. In the discussion that follows, we will use the term
   "EAP server" to denote the ultimate endpoint conversing with the
   peer.

   Once having received the peer's Identity, the EAP server MUST respond
   with an EAP-TLS/Start packet, which is an EAP-Request packet with
   EAP-Type=EAP-TLS, the Start (S) bit set, and no data.  The EAP-TLS
   conversation will then begin, with the peer sending an EAP-Response
   packet with EAP-Type=EAP-TLS.  The data field of that packet will
   encapsulate one or more TLS records in TLS record layer format,
   containing a TLS client_hello handshake message.  The current cipher
   spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null
   compression.  This current cipher spec remains the same until the
   change_cipher_spec message signals that subsequent records will have
   the negotiated attributes for the remainder of the handshake.






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


   The client_hello message contains the client's TLS version number, a
   sessionId, a random number, and a set of ciphersuites supported by
   the client. The version offered by the client MUST correspond to TLS
   v1.0 or later.

   The EAP server will then respond with an EAP-Request packet with
   EAP-Type=EAP-TLS. The data field of this packet will encapsulate one
   or more TLS records. These will contain a TLS server_hello handshake
   message, possibly followed by TLS certificate, server_key_exchange,
   certificate_request, server_hello_done and/or finished handshake
   messages, and/or a TLS change_cipher_spec message.  The server_hello
   handshake message contains a TLS version number, another random
   number, a sessionId, and a ciphersuite.  The version offered by the
   server MUST correspond to TLS v1.0 or later.

   If the client's sessionId is null or unrecognized by the server, the
   server MUST choose the sessionId to establish a new session;
   otherwise, the sessionId  will  match  that  offered by the client,
   indicating a resumption of the previously established session with
   that sessionID.  The server will also choose a ciphersuite from those
   offered by  the client; if the session matches the client's, then the
   ciphersuite MUST match the one negotiated during the handshake
   protocol execution that established the session.

   The purpose of the sessionId within the TLS protocol is to allow for
   improved efficiency in the case where a client repeatedly attempts to
   authenticate to an EAP server within a short period of time. While
   this model was developed for use with HTTP authentication, it may
   also have application to PPP authentication (e.g. multilink).

   As a result, it is left up to the peer whether to attempt to continue
   a previous session, thus shortening the TLS conversation. Typically
   the peer's decision will be made based on the time elapsed since the
   previous authentication attempt to that EAP server. Based on the
   sessionId chosen by the peer, and the time elapsed since the previous
   authentication, the EAP server will decide whether to allow the
   continuation, or whether to choose a new session.

   In the case where the EAP server and authenticator reside on the same
   device, then client will only be able to continue sessions when
   connecting to the same NAS or tunnel server. Should these devices be
   set up in a rotary or round-robin then it may not be possible for the
   peer to know in advance the authenticator it will be connecting to,
   and therefore which sessionId to attempt to reuse. As a result, it is
   likely that the continuation attempt will fail. In the case where the
   EAP authentication is remoted then continuation is much more likely
   to be successful, since multiple NAS devices and tunnel servers will
   remote their EAP authentications to the same RADIUS server.



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


   If the EAP server is resuming a previously established session, then
   it MUST include only a TLS change_cipher_spec message and a TLS
   finished handshake message after the server_hello message.  The
   finished message contains the EAP server's authentication response to
   the peer.  If the EAP server is not resuming a previously established
   session, then it MUST include a TLS server_certificate handshake
   message, and a server_hello_done handshake message MUST be the last
   handshake message encapsulated in this EAP-Request packet.

   The certificate message contains a public key certificate chain for
   either a key exchange public key (such as an RSA or Diffie-Hellman
   key exchange public key) or a signature public key (such as an RSA or
   DSS signature public key).  In the latter case, a TLS
   server_key_exchange handshake message MUST also be included to allow
   the key exchange to take place.

   The certificate_request message is included when the server desires
   the client to authenticate itself via public key. While the EAP
   server SHOULD require client authentication, this is not a
   requirement, since it may be possible that the server will require
   that the peer authenticate via some other means.

   The peer MUST respond to the EAP-Request with an EAP-Response packet
   of EAP-Type=EAP-TLS.  The data field of this packet will encapsulate
   one or more TLS records containing a TLS change_cipher_spec message
   and finished handshake message, and possibly certificate,
   certificate_verify and/or client_key_exchange handshake messages.  If
   the preceding server_hello message sent by the EAP server in the
   preceding EAP-Request packet indicated the resumption of a previous
   session, then the peer MUST send only the change_cipher_spec and
   finished handshake messages.  The finished message contains the
   peer's authentication response to the EAP server.

   If the preceding server_hello message sent by the EAP server in the
   preceeding EAP-Request packet did not indicate the resumption of a
   previous session, then the peer MUST send, in addition to the
   change_cipher_spec and finished messages, a client_key_exchange
   message, which completes the exchange of a shared master secret
   between the peer and the EAP server.  If the EAP server sent a
   certificate_request message in the preceding EAP-Request packet, then
   the peer MUST send, in addition, certificate and certificate_verify
   handshake messages.  The former contains a certificate for the peer's
   signature public key, while the latter contains the peer's signed
   authentication response to the EAP server. After receiving this
   packet, the EAP server will verify the peer's certificate and digital
   signature, if requested.





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


   If the peer's authentication is unsuccessful, the EAP server SHOULD
   send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS
   record containing the appropriate TLS alert message.  The EAP server
   SHOULD send a TLS alert message rather 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.

   To ensure that the peer receives the TLS alert message, the EAP
   server MUST wait for the peer to reply with an EAP-Response packet.
   The EAP-Response packet sent by the peer MAY encapsulate a TLS
   client_hello handshake message, in which case the EAP server MAY
   allow the EAP-TLS conversation to be restarted, or it MAY contain an
   EAP-Response packet with EAP-Type=EAP-TLS and no data, in which case
   the EAP-Server MUST send an EAP-Failure packet, and terminate the
   conversation. It is up to the EAP server whether to allow restarts,
   and if so, how many times the conversation can be restarted. An EAP
   Server implementing restart capability SHOULD impose a limit on the
   number of restarts, so as to protect against denial of service
   attacks.

   If the peers authenticates successfully, the EAP server MUST respond
   with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in
   the case of a new TLS session, one or more TLS records containing TLS
   change_cipher_spec and finished handshke messages.  The latter
   contains the EAP server's authentication response to the peer.  The
   peer will then verify the hash in order to authenticate the EAP
   server.

   If the EAP server authenticates unsuccessfully, the peer MAY send an
   EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert
   message identifying the reason for the failed authentication. The
   peer MAY send a TLS alert message rather than immediately terminating
   the conversation so as to allow the EAP server to log the cause of
   the error for examination by the system administrator.

   To ensure that the EAP Server receives the TLS alert message, the
   peer MUST wait for the EAP-Server to reply before terminating the
   conversation.  The EAP Server MUST reply with an EAP-Failure packet
   since server authentication failure is a terminal condition.

   If the EAP server authenticates successfully, the peer MUST send an
   EAP-Response packet of EAP-Type=EAP-TLS, and no data.  The EAP-Server
   then MUST respond with an EAP-Success message.








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


3.2.  Retry behavior

   As with other EAP protocols, the EAP server is responsible for retry
   behavior. This means that if the EAP server does not receive a reply
   from the peer, it MUST resend the EAP-Request for which it has not
   yet received an EAP-Response. However, the peer MUST NOT resend EAP-
   Response packets without first being prompted by the EAP server.

   For example, if the initial EAP-TLS start packet sent by the EAP
   server were to be lost, then the peer would not receive this packet,
   and would not respond to it. As a result, the EAP-TLS start packet
   would be resent by the EAP server. Once the peer received the EAP-TLS
   start packet, it would send an EAP-Response encapsulating the
   client_hello message.  If the EAP-Response were to be lost, then the
   EAP server would resend the initial EAP-TLS start, and the peer would
   resend the EAP-Response.

   As a result, it is possible that a peer will receive duplicate EAP-
   Request messages, and may send duplicate EAP-Responses.  Both the
   peer and the EAP-Server should be engineered to handle this
   possibility.

3.3.  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. The group of EAP-TLS messages
   sent in a single round may thus be larger than the PPP MTU size, the
   maximum RADIUS packet size of 4096 octets, or even the Multilink
   Maximum Received Reconstructed Unit (MRRU).  As described in [2], the
   multilink MRRU is negotiated via the Multilink MRRU LCP option, which
   includes an MRRU length field of two octets, and thus can support
   MRRUs as large as 64 KB.

   However, 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 anwhere near as long, a
   reasonable choice of maximum acceptable message length might be 64
   KB.

   If this value is chosen, then fragmentation can be handled via the
   multilink PPP fragmentation mechanisms described in [2]. While this
   is desirable, there may be cases in which multilink or the MRRU LCP
   option cannot be negotiated. As a result, an EAP-TLS implementation
   MUST provide its own support for fragmentation and reassembly.