draft-josefsson-pppext-eap-tls-eap-05.txt

Linux上的802.1x 的supplicant的实现。很多supplicant程序都是基于它开发的

     carried out, unless part 1 provided client authentication.

In the next two sections, we provide an overview of each of the parts of
the PEAP conversation.

2.1.  PEAP Part 1

The PEAP conversation typically begins with the authenticator and the
peer negotiating EAP.  The authenticator will typically send an EAP-
Request/Identity packet to the peer, and the peer will respond with an



Andersson et al.             Standards Track                    [Page 6]





INTERNET-DRAFT                    PEAP                    September 2002


EAP-Response/Identity packet to the authenticator, containing the peer's
userId.

Once the optional initial Identity Request/Response exchange is
completed, while nominally the EAP conversation occurs between the
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 backend authentication 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, and determined that PEAP
authentication is to occur, the EAP server MUST respond with a
PEAP/Start packet, which is an EAP-Request packet with EAP-Type=PEAP,
the Start (S) bit set, and no data.  Assuming that the peer supports
PEAP, the PEAP conversation will then begin, with the peer sending an
EAP-Response packet with EAP-Type=PEAP.

The data field of the EAP-Response 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.

The client_hello message contains the client's TLS version number, a
sessionId, a random number, and a set of TLS 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=PEAP. 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.

Since after the TLS session is established, another complete EAP
negotiation will occur and the peer will authenticate using a secondary
mechanism, with PEAP the client need not authenticate as part of TLS
session establishment. As a result, although the EAP-Request packet sent
by the EAP Server MAY contain a certificate_request message, this is not
required.

The certificate_request message indicates that the server desires the
client to authenticate itself via public key. Typically when the EAP
server sends a certificate_request message, the intent is to complete



Andersson et al.             Standards Track                    [Page 7]





INTERNET-DRAFT                    PEAP                    September 2002


the PEAP authentication without requiring negotiation of an additional
EAP method, so that only an EAP-Success or EAP-Failure message is sent
inside the TLS channel.  However, it is valid for the server to request
a certificate in the server_hello and for the client refuse to provide
one. In this case, the EAP server MUST require that PEAP Part 2 be
completed.

Note that since TLS client certificates are sent in the clear, if
identity protection is required, then it is possible for the TLS
authentication to be re-negotiated after the first server
authentication.  To accomplish this, after the server_finished message
is sent, and before PEAP part 2,  the server sends a TLS hello_request.
This allows the  client to perform client authentication by sending a
client_hello if it wants to, or, send a no_renegotiation alert to the
server indicating that it wants to continue with PEAP part 2 instead.
Since this re-negotiation occurs within the encrypted TLS channel, it
does not reveal client certificate details.

The server_hello handshake message contains a TLS version number,
another random number, a sessionId, and a TLS ciphersuite.  The version
offered by the server MUST correspond to TLS v1.0 or later.  In order to
provide confidentiality, integrity and replay protection, and
authentication, the negotiated TLS ciphersuite MUST provide all of these
security services.

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 TLS ciphersuite from those offered by  the
client; if the session matches the client's, then the TLS ciphersuite
MUST match the one negotiated during the handshake protocol execution
that established the session.

PEAP implementations need not necessarily support all TLS ciphersuites
listed in [RFC2246]. Not all TLS ciphersuites are supported by available
TLS tool kits and licenses may be required to support some TLS
ciphersuites (e.g. TLS ciphersuites utilizing the IDEA encryption
algorithm). To ensure interoperability, PEAP peers and Authenticators
MUST be able to negotiate the following TLS ciphersuites:

    TLS_RSA_WITH_RC4_128_MD5
    TLS_RSA_WITH_RC4_128_SHA

TLS as described in [RFC2246] supports compression as well as
ciphersuite negotiation. Therefore during the PEAP Part 1 conversation
the EAP endpoints MAY request or negotiate TLS compression.




Andersson et al.             Standards Track                    [Page 8]





INTERNET-DRAFT                    PEAP                    September 2002


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 peer MUST respond to the EAP-Request with an EAP-Response packet of
EAP-Type=PEAP.  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.

The EAP server MUST then respond with an EAP-Request packet with EAP-
Type=PEAP, which includes, in the case of a new TLS session, one or more
TLS records containing TLS change_cipher_spec and finished handshake
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=PEAP 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.



Andersson et al.             Standards Track                    [Page 9]





INTERNET-DRAFT                    PEAP                    September 2002


If the EAP server authenticates successfully, the peer MUST send an EAP-
Response packet of EAP-Type=PEAP, and no data.  The EAP-Server then
continues with Part 2 of the PEAP conversation.

2.1.1.  Forging of Success and Failure packets

Within EAP, Success and Failure packets are not authenticated, so that
they may be forged by an attacker without fear of detection. Forged EAP
Failure packets can be used to convince an EAP peer to disconnect.
Forged EAP Success packets may be used by a rogue NAS to convince a peer
to let itself access the network, even though the NAS has not
authenticated itself.

By requiring mutual authentication and by encrypting and integrity
protecting the EAP conversation within a TLS channel, PEAP provides
protection against these attacks. Since the EAP Server MUST authenticate
itself to the EAP Peer in PEAP Part 1, once the TLS channel has been
brought up, EAP Success or Failure packets should be sent down the
encrypted channel, rather than being sent in cleartext. As a result,
once PEAP has been selected as the authentication method, and the PEAP
conversation has begun, a peer receiving cleartext Success or Failure
packets MUST silently discard them.

2.2.  PEAP Part 2

The second portion of the PEAP conversation consists of another complete
EAP conversation occurring within the TLS session negotiated in PEAP
Part 1. It will therefore occur only if establishment of the TLS session
in Part 1 is successful. It MUST NOT occur if the EAP Server
authenticates unsuccessfully or if an EAP-Failure has been sent by the
EAP Server to the peer, terminating the conversation.  Since all packets
sent within the PEAP Part 2 conversation occur after TLS session
establishment, they are protected using the negotiated TLS ciphersuite.

Part 2 of the PEAP conversation typically begins with the Authenticator
sending an EAP-Request/Identity packet to the peer, protected by the TLS
ciphersuite negotiated in PEAP Part 1. The peer responds with an EAP-
Response/Identity packet to the authenticator, containing the peer's
userId. Since this Identity Request/Response exchange is protected by
the ciphersuite negotiated in TLS, it is protected against snooping or
packet modification attacks.

After the TLS session-protected Identity exchange, the EAP server will
then select authentication method(s) for the peer, and will send an EAP-
Request with the EAP-Type set to the initial method. As described in
[RFC2284], the peer can NAK the suggested EAP method, suggesting an
alternative. Since the NAK will be sent within the TLS channel, it is
protected from snooping or packet modification. As a result, an attacker



Andersson et al.             Standards Track                   [Page 10]





INTERNET-DRAFT                    PEAP                    September 2002


snooping on the exchange will be unable to inject NAKs in order to
"negotiate down" the authentication method.  An attacker will also not
be able to determine which EAP method was negotiated.

As with a normal EAP conversation described in [RFC2284], an EAP
conversation encapsulated within the TLS channel as within PEAP Part 2
continues until the EAP server sends an EAP-Failure or EAP-Success. The
receipt of an EAP-Failure or EAP-Success within the TLS protected
channel results in a shutdown of the TLS channel by the peer and EAP
server. The EAP-Failure or EAP-Success packet sent within the TLS
channel is protected from snooping or packet modification, and as a
result, while an EAP server MAY send an additional EAP-Failure or EAP-
Success message in cleartext, this is not required, since it adds
another round-trip. As described in [RFC2869], a RADIUS Access-Accept or
Access-Reject packet need not contain an EAP-Message attribute, since
the NAS determines the success of the conversation from the RADIUS
message (Accept/Reject), not the encapsulated EAP-Message attribute.

2.3.  Version negotiation

PEAP packets contain a two bit version field, which enables PEAP
implementations to be backward compatible with previous versions of the
protocol. Implementations of this specification MUST use a version field
set to 1.  Version negotiation proceeds as follows:

[1]  In the first EAP-Request sent with EAP type=PEAP, the EAP server
     MUST set the version field to the highest supported version number.

[2]  If the EAP client supports this version of the protocol, it MUST
     respond with an EAP-Response of EAP type=PEAP, and the version
     number proposed by the EAP server.

[3]  If the EAP client does not support this version, it responds with
     an EAP-Response of EAP type=PEAP and a lower version number,
     indicating the highest supported version number.

[4]  If the EAP server supports the version proposed by the client, then
     all future EAP-Request and EAP-Response packets of EAP type=PEAP
     MUST include the version field set to the agreed upon version
     number.

[5]  If the EAP server does not support the version number proposed by
     the EAP client, it responds with an EAP-Failure sent in the clear.

This version negotiation procedure guarantees that the EAP client and
server will agree to the latest version supported by both parties. If
version negotiation fails, then use of PEAP will not be possible, and
another mutually acceptable EAP method will need to be negotiated if



Andersson et al.             Standards Track                   [Page 11]





INTERNET-DRAFT                    PEAP                    September 2002


authentication is to proceed.

2.4.  Error handling

Other than supporting TLS alert messages, PEAP does not have its own
error message capabilities. This is unnecessary since errors in the PEAP
Part 1 conversation are communicated via TLS alert messages, and errors
in the PEAP Part 2 conversation are expected to be handled by individual
EAP methods.

If an error occurs at any point in the PEAP conversation, the EAP server
SHOULD send an EAP-Request packet with EAP-Type=PEAP, encapsulating a
TLS record containing the appropriate TLS alert message.  The EAP server
SHOULD send a 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.  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.

2.5.  Retry behavior

As with other EAP protocols, the EAP server is responsible for retry