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

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

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
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 PEAP 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 PEAP start packet would be resent by
the EAP server. Once the peer received the PEAP 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 PEAP 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.

2.6.  Session resumption

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. This
capability is particularly useful for support of wireless roaming.

It is left up to the peer whether to attempt to continue a previous
session, thus shortening the PEAP Part 1 conversation. Typically the



Andersson et al.             Standards Track                   [Page 12]





INTERNET-DRAFT                    PEAP                    September 2002


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 the authenticator reside on the
same device, then the 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 backend
authentication server.

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.

2.7.  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 PEAP 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 anywhere 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 [RFC1990]. While
this is desirable, EAP methods are used in other applications such as
[IEEE80211] and there may be cases in which multilink or the MRRU LCP
option cannot be negotiated. As a result, a PEAP implementation MUST



Andersson et al.             Standards Track                   [Page 13]





INTERNET-DRAFT                    PEAP                    September 2002


provide its own support for fragmentation and reassembly.

Since EAP is an 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.

PEAP 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 PEAP 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 PEAP 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 a PEAP peer receives an EAP-Request packet with the M bit set, it
MUST respond with an EAP-Response with EAP-Type=PEAP 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 server receives an EAP-Response with the M bit
set, it MUST respond with an EAP-Request with EAP-Type=PEAP 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.

2.8.  Key derivation

Since the normal TLS keys are used in the handshake, and therefore
should not be used in a different context, new keys must be derived from
the TLS master secret for use with the selected link layer ciphersuites.
In the most general case, keying material must be provided for
authentication, encryption and initialization vectors (IVs) in each
direction.




Andersson et al.             Standards Track                   [Page 14]





INTERNET-DRAFT                    PEAP                    September 2002


Since EAP methods may not know the link layer ciphersuite that has been
negotiated, it may not be possible for them to provide link layer
ciphersuite-specific keys. In addition, attempting to provide such keys
is undesirable, since it would require the EAP method to be revised each
time a new link layer ciphersuite is developed. As a result, PEAP
derives master session keys which can subsequently be truncated for use
with a particular link layer ciphersuite.  Since the truncation
algorithms are ciphersuite-specific, they are not discussed here;
examples of such algorithms are provided in [RFC3079]. This draft also
does not discuss the format of the attributes used to communicate the
master session keys from the backend authentication server to the NAS;
examples of such attributes are provided in [RFC2548].

For both peer and EAP server, the derivation of master session keys
proceeds as follows:

[1]  Given the master key 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 key,
     "client PEAP encryption", random) is computed up to 128 bytes, and
     the value PRF("", "client PEAP encryption", random) is computed up
     to 64 bytes (where "" is an empty string).

[2]  The peer master session 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 these two PRF output strings.

[3]  The EAP server master session encryption key (the one used to
     encrypting data from EAP server to peer), if different from the
     client master session encryption key, is obtained by truncating to
     the correct length the second 32 bytes of this same PRF output
     string.

[4]  The peer master session 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.

[5]  The EAP server master session authentication key (the one used for
     computing MACs for messages from EAP server to peer), if used, and
     if different from the peer master session authentication key, is
     obtained by truncating to the correct length the fourth 32 bytes of
     this same PRF output string.

[6]  The peer master session initialization vector (IV), used for
     messages from peer to EAP server, is obtained by truncating to the



Andersson et al.             Standards Track                   [Page 15]





INTERNET-DRAFT                    PEAP                    September 2002


     cipher's block size the first 32 bytes of the second PRF output
     string mentioned above.

[7]  Finally, the EAP server master session initialization vector (IV),
     used for messages from peer to EAP server, is obtained by
     truncating to the cipher's block size the second 32 bytes of this
     second PRF output.

Algorithms for the truncation of these encryption and authentication
master session keys are specific to each link layer ciphersuite. Link
layer ciphersuites in use with PPP include DESEbis [RFC2419], 3DES
[RFC2420] and MPPE [RFC3078]. IEEE 802.11 ciphersuites are described in
[IEEE80211]. An example of how encryption keys for use with MPPE
[RFC3078] are derived from the TLS master session keys is given in
[RFC3079]. Additional keys or other non-secret values (such as IVs) can
be obtained as needed by extending the outputs of the PRF beyond 128
bytes and 64 bytes, respectively.

2.9.  Ciphersuite negotiation

Since TLS supports TLS ciphersuite negotiation, peers completing the TLS
negotiation will also have selected a TLS ciphersuite, which includes
key strength, encryption and hashing methods. However, unlike in
[RFC2716], within PEAP, the negotiated TLS ciphersuite relates only to
the mechanism by which the PEAP Part 2 conversation will be protected,
and has no relationship to link layer security mechanisms negotiated
within the PPP Encryption Control Protocol (ECP) [RFC1968] or within
IEEE 802.11 [IEEE80211].

As a result, PEAP does not support secure negotiation of link layer
ciphersuites. While such a negotiation is preferable from a security
perspective, it is in practice difficult to integrate with existing PPP
and IEEE 802.11 link layer security negotiation, as well as with backend
authentication servers.

Depending on the link layer technology in use, the link layer security
negotiation will occur at different stages in the connection process. In
IEEE 802.11, selection of the link layer security mechanism occurs via
the association/re-association messages, prior to authentication. In
contrast, within PPP, link layer security negotiation occurs in ECP
[RFC1968], which occurs after authentication.

As a result, within IEEE 802.11, by the time that PEAP is invoked, the
link layer security technology has already been selected. Thus if PEAP
were to support a protected link layer ciphersuite negotiation whose
conclusion disagreed with the IEEE 802.11 negotiation, a reassociation
(and additional authentication!) would be required to synchronize the
results of the two negotiations.  Within PPP, it is conceivable that the



Andersson et al.             Standards Track                   [Page 16]





INTERNET-DRAFT                    PEAP                    September 2002


results of a PEAP secure link layer security negotiation could be
subsequently reflected in the ECP negotiation.

There are other issues as well.  While link layer ciphersuite
negotiation occurs between the peer and the NAS, the EAP conversation
occurs between the peer and the EAP server.  Since the EAP server may
not be aware of the link layer ciphersuites supported by the NAS, it is
conceivable that the NAS and peer can negotiate a link layer ciphersuite
that is not supported by the NAS. To address this issue, it would be
necessary for the NAS to send the list of supported link layer
ciphersuites to the backend authentication server, and have the backend
security server respond with a list of acceptable choices. However, when
used with technologies such as IEEE 802.11 where link layer security
technology selection occurs prior to authentication, multiple
association/reassociation exchanges might be required to synchronize the
negotiations, resulting in extended connectivity loss.

The situation typically cannot be addressed merely by omitting IEEE
802.11 link layer security negotiation. Unless all users on the AP are
to be authenticated with PEAP or an alternative EAP method providing
secure link layer security negotiation, then omitting IEEE 802.11
security negotiation would leave some users without the ability to
negotiate security mechanisms.

For these reasons, protected negotiation of link layer ciphersuites
within PEAP is considered impractical and is omitted from this
specification.