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

来自「linux 下通过802.1认证的安装包」· 文本 代码 · 共 1,665 行 · 第 1/5 页

    0 1
   +-+-+
   |R 1|
   +-+-+

   R = Reserved (must be zero)

TLS Message Length

   The TLS Message Length field is four octets, and is present only if
   the L bit is set. This field provides the total length of the TLS
   message or set of messages that is being fragmented.

TLS data

   The TLS data consists of the encapsulated TLS packet in TLS record
   format.

4.  Security Considerations

4.1.  Method negotiation

If the peer does not support PEAP, or does not wish to utilize PEAP
authentication, it MUST respond to the initial EAP-Request/PEAP-Start
with a NAK, suggesting an alternate authentication method. Since the NAK
is sent in cleartext with no integrity protection or authentication, it
is subject to spoofing.  Unauthentic NAK packets can be used to trick
the peer and Authenticator into "negotiating down" to a weaker form of
authentication, such as EAP-MD5 (which only provides one way
authentication and does not derive a key).

Since a subsequent protected EAP conversation can take place within the
TLS session, selection of PEAP as an authentication method does not
limit the potential secondary authentication methods. As a result, the
only legitimate reason for a peer to NAK PEAP as an authentication
method is that it does not support it. Where the additional security of
PEAP is required, server implementations SHOULD respond to a NAK with an
EAP-Failure, terminating the authentication conversation.






Andersson et al.             Standards Track                   [Page 23]





INTERNET-DRAFT                    PEAP                    September 2002


4.2.  TLS session cache handling

In cases where a TLS session has been successfully resumed, in some
circumstances, it is possible for the EAP server  to skip the PEAP Part
2 conversation entirely, and immediately send an EAP-Success message
within the TLS channel established via session resumption.

PEAP "fast reconnect" is desirable in applications such as wireless
roaming, since it minimizes interruptions in connectivity.  It is also
desirable when the "inner" EAP mechanism used is such that it requires
user interaction.  The user should not be required to re-authenticate
herself, using biometrics, token cards or similar, every time the radio
connectivity is handed over between access points in wireless
environments.

However, there are issues that need to be understood in order to avoid
introducing security vulnerabilities.

Since PEAP Part 1 may not provide client authentication, establishment
of a TLS session (and an entry in the TLS session cache) does not by
itself provide an indication of the peer's authenticity.  The peer's
authenticity is only proven by successful completion of the PEAP Part 2
authentication.

Some PEAP implementations may not be capable of removing TLS session
cache entries established in PEAP Part 1 after an unsuccessful PEAP Part
2 authentication. In such implementations, the existence of a TLS
session cache entry provides no indication that the peer has previously
been authenticated. As a result, implementations that do not remove TLS
session cache entries after a failed PEAP Part 2 authentication MUST use
other means than successful TLS resumption as the indicator of whether
the client is authenticated or not.  Failing to do this would enable a
peer to gain access by completing PEAP Part 1, tearing down the
connection and re-connect and resume PEAP Part 1 thereby proving herself
authenticated.  Thus, TLS resumption MUST only be used as an indicator
of whether the client is authenticated or not if the implementation
supports TLS session cache removal.

If an EAP server implementing PEAP removes TLS session cache entries of
peers failing PEAP Part 2 authentication, then it SHOULD skip the PEAP
Part 2 conversation entirely after a successful session resumption,
immediately sending an EAP-Success message within the TLS channel.

4.3.  Certificate revocation

Since the EAP server is on the Internet during the EAP conversation, the
server is capable of following a certificate chain or verifying whether
the peer's certificate has been revoked. In contrast, the peer may or



Andersson et al.             Standards Track                   [Page 24]





INTERNET-DRAFT                    PEAP                    September 2002


may not have Internet connectivity, and thus while it can validate the
EAP server's certificate based on a pre-configured set of CAs, it may
not be able to follow a certificate chain or verify whether the EAP
server's certificate has been revoked.

In the case where the peer is initiating a voluntary Layer 2 tunnel
using PPTP or L2TP, the peer will typically already have Internet
connectivity established at the time of tunnel initiation.  As a result,
during the EAP conversation it is capable of checking for certificate
revocation.

As part of the TLS negotiation, the server presents a certificate to the
peer.  The peer SHOULD 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, 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.

In the case where the peer is attempting to obtain network access, it
will not have Internet connectivity. The TLS Extensions [TLSEXT] support
piggybacking of an Online Certificate Status Protocol (OCSP) response
within TLS, therefore can be utilized by the peer in order to verify the
validity of server certificate. However, since all TLS implementations
do not implement the TLS extensions, it may be necessary for the peer to
wait to check for certificate revocation until after Internet access has
been obtained.  In this case, the peer SHOULD conduct the certificate
status check immediately upon going online and SHOULD NOT send data
until it has received a positive response to the status request.  If the
server certificate is found to be invalid, then the peer SHOULD
disconnect.

4.4.  Separation of the EAP server and the authenticator

As a result of a complete PEAP Part 1 and Part 2 conversation, the EAP
endpoints will mutually authenticate, and derive a session key for
subsequent use in link layer security. Since the peer and EAP client
reside on the same machine, it is necessary for the EAP client module to
pass the session key to the link layer encryption module.

The situation may be more complex on the Authenticator, which may or may
not reside on the same machine as the EAP server. In the case where the
EAP server and the Authenticator reside on different machines, there are
several implications for security. Firstly, the mutual authentication



Andersson et al.             Standards Track                   [Page 25]





INTERNET-DRAFT                    PEAP                    September 2002


defined in PEAP will occur between the peer and the EAP server, not
between the peer and the authenticator. This means that as a result of
the PEAP conversation, it is not possible for the peer to validate the
identity of the NAS or tunnel server that it is speaking to.

The second issue is that the session key negotiated between the peer and
EAP server will need to be transmitted to the authenticator.  Therefore
a mechanism needs to be provided to transmit the session key from the
EAP server to the authenticator or tunnel server that needs to use the
key. The specification of this transit mechanism is outside the scope of
this document.

4.5.  Separation of PEAP Part 1 and Part 2 Servers

The EAP server involved in PEAP Part 2 need not necessarily be the same
as the EAP server involved in PEAP Part 1. For example, a local
authentication server or proxy might serve as the endpoint for the Part
1 conversation, establishing the TLS channel. Subsequently, once the
EAP-Response/Identity has been received within the TLS channel, it can
be decrypted and forwarded in cleartext to the destination realm EAP
server. The rest of the conversation will therefore occur between the
destination realm EAP server and the peer, with the local authentication
server or proxy acting as an encrypting/decrypting gateway. This permits
a non-TLS capable EAP server to participate in the PEAP conversation.

Note however that such an approach introduces security vulnerabilities.
Since the EAP Response/Identity is sent in the clear between the proxy
and the EAP server, this enables an attacker to snoop the user's
identity.  It also enables a remote environments, which may be public
hot spots or Internet coffee shops, to gain knowledge of the identity of
their users.  Since one of the potential benefits of PEAP is identity
protection, this is undesirable.

If the EAP method negotiated during PEAP Part 2 does not support mutual
authentication, then if the Part 2 conversation is proxied to another
destination, the PEAP peer will not have the opportunity to verify the
secondary EAP server's identity. Only the initial EAP server's identity
will have been verified as Part of TLS session establishment.

Similarly, if the EAP method negotiated during PEAP Part 2 is vulnerable
to dictionary attack, then an attacker capturing the cleartext exchange
will be able to mount an offline dictionary attack on the password.

Finally, when a Part 2 conversation is terminated at a different
location than the Part 1 conversation, the Part 2 destination is unaware
that the EAP client has negotiated PEAP. As a result, it is unable to
enforce policies requiring PEAP. Since some EAP methods require PEAP in
order to generate keys or lessen security vulnerabilities, where such



Andersson et al.             Standards Track                   [Page 26]





INTERNET-DRAFT                    PEAP                    September 2002


methods are in use, such a configuration may be unacceptable.

In summary, PEAP encrypting/decrypting gateway configurations are
vulnerable to attack and SHOULD NOT be used.  Instead, the entire PEAP
connection SHOULD be proxied to the final destination, and the
subsequently derived master session keys need to be transmitted back.
This provides end to end protection of PEAP.  The specification of this
transit mechanism is outside the scope of this document, but mechanisms
similar to [RFC2548] can be used.  These steps protects the client from
revealing her identity to the remote environment.

In order to find the proper PEAP destination, the EAP client SHOULD
place a Network Access Identifier (NAI) conforming to [RFC2486] in the
Identity Response.

There may be cases where a natural trust relationship exists between the
(foreign) authentication server and final EAP server, such as on a
campus or between two offices within the same company, where there is no
danger in revealing the identity of the station to the authentication
server.  In these cases, using a proxy solution without end to end
protection of PEAP MAY be used. The PEAP encrypting/decrypting gateway
SHOULD provide support for IPsec protection of RADIUS in order to
provide confidentiality for the portion of the conversation between the
gateway and the EAP server, as described in [RFC3162].

4.6.  Identity verification

Since the TLS session has not yet been negotiated, the initial Identity
request/response occurs in the clear without integrity protection or
authentication. It is therefore subject to snooping and packet
modification.

In configurations where all users are required to authenticate with PEAP
and the first portion of the PEAP conversation is terminated at a local
backend authentication server, without routing by proxies, the initial
cleartext Identity Request/Response exchange is not needed in order to
determine the required authentication method(s) or route the
authentication conversation to its destination. As a result, the initial
Identity and  Request/Response exchange MAY NOT be present, and a
subsequent Identity Request/Response exchange MAY occur after the TLS
session is established.

If the initial cleartext Identity Request/Response has been tampered
with, after the TLS session is established, it is conceivable that the
EAP Server will discover that it cannot verify the peer's claim of
identity. For example, the peer's userID may not be valid or may not be
within a realm handled by the EAP server. Rather than attempting to
proxy the authentication to the server within the correct realm, the EAP



Andersson et al.             Standards Track                   [Page 27]





INTERNET-DRAFT                    PEAP                    September 2002


server SHOULD terminate the conversation.

The PEAP peer can present the server with multiple identities. This
includes the claim of identity within the initial EAP-Response/Identity
(MyID) packet, which is typically used to route the EAP conversation to
the appropriate home backend authentication server. There may also be
subsequent EAP-Response/Identity packets sent by the peer once the TLS
tunnel has been established.

Note that since the PEAP peer may not present a certificate, it is not
always possible to check the initial EAP-Response/Identity against the
identity presented in the certificate, as is done in [RFC2716].
Moreover, it cannot be assumed that the peer identities presented within
multiple EAP-Response/Identity packets will be the same. For example,
the initial EAP-Response/Identity might correspond to a machine
identity, while subsequent identities might be those of the user. Thus,
PEAP implementations SHOULD NOT abort the authentication just because
the identities do not match.  However, since the initial EAP-
Response/Identity will determine the EAP server handling the
authentication, if this or any other identity is inappropriate for use
with the destination EAP server, there is no alternative but to
terminate the PEAP conversation.

The protected identity or identities presented by the peer within PEAP
Part 2 may not be identical to the cleartext identity presented in PEAP
Part 1, for legitimate reasons. In order to shield the userID from
snooping, the cleartext Identity may only provide enough information to
enable routing of the authentication request to the correct realm. For
example, the peer may initially claim the identity of "[e-mail]"
in order to route the authentication request to the bigco.com EAP
server. Subsequently, once the TLS session has been negotiated, in PEAP
Part 2, the peer may claim the identity of "[e-mail]".  Thus, PEAP
can provide protection for the user's identity, though not necessarily
the destination realm, unless the PEAP Part 1 conversation terminates at
the local authentication server.

As a result, PEAP implementations SHOULD NOT attempt to compare the
Identities claimed with Parts 1 and 2 of the PEAP conversation.
Similarly, if multiple Identities are claimed within PEA