draft-kamath-pppext-peapv0-00.txt

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

   1 - Mandatory AVP

R

   Reserved, set to zero (0)

AVP Type

   3 - Result

Length

   2

Status

   The status field is two octets. Values include:

   1 - Success
   2 - Failure

3.  Security considerations

3.1.  Authentication and integrity protection

The EAP Extension method is presumed to run before or after an EAP
method that supports mutual authentication and establishes a protected
channel.  PEAP is such a method, and as a result the acknowledged
Success and Failure messages are always protected.

Note however, that [IEEE8021X] manufactures clear-text EAP Success and
EAP Failure messages, so that even though the Result AVP will be
protected, this will be followed by a clear-text EAP Success or EAP



Kamath, Palekar & Wodrich     Informational                     [Page 7]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


Failure packet.

3.2.  Outcomes

Within the Microsoft PEAP Version 0 implementation, support for the EAP
Extensions method and the Result AVP is required. The only outcome which
should be considered a successful authentication is when an EAP Request
of Type=Extensions with  Result AVP of Status=Success is answered by an
EAP Response of Type=Extensions with Result AVP of Status=Success. All
other combinations (Extensions Success, Extensions Failure), (Extensions
Failure, Extensions Success), (Extensions Failure, Extensions Failure),
(No extensions exchange) should be considered failed authentications,
both by the EAP Peer and EAP Server. This is true regardless of whether
an EAP Success or EAP Failure packet is subsequently sent, either in
clear-text or within the PEAP tunnel. Because the EAP Extensions method
is protected within the PEAP channel, its messages cannot be spoofed,
whereas clear-text Success and Failure messages can be sent by an
attacker.

While the [PEAP] specification permits a tunneled EAP Success or Failure
packet to be sent as the last message, this is not possible within the
Windows XP SP1 implementation, which can only tunnel EAP packets of
codes Request or Response within PEAP.  Since the [IEEE8021X]
specification requires that the switch or access point "manufacture" a
clear-text EAP Success packet when an Access-Accept is received from the
backend authentication server, and a clear-text EAP Failure packet when
an Access-Reject is received.  As a result, a tunneled EAP Success or
Failure packet, if sent as the last message, would be thrown away by
conformant [IEEE 8021X] implementations, and replaced with clear-text.
This problem is being addressed within the IEEE 802.1aa revision to IEEE
802.1X, but the fix may take a while to move through the standards
process and be implemented in commercial products.

4.  Normative references

[PEAP]         Andersson, H., et al. "Protected EAP Protocol", Internet
               draft (work in progress), draft-josefsson-pppext-eap-tls-
               eap-02.txt, February 2002.

[RFC1661]      Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
               STD 51, RFC 1661, July 1994.

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2284]      Blunk, L., Vollbrecht, J., "PPP Extensible Authentication
               Protocol (EAP)", RFC 2284, March 1998.




Kamath, Palekar & Wodrich     Informational                     [Page 8]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


[IEEE8021X]    IEEE Standards for Local and Metropolitan Area Networks:
               Port based Network Access Control, IEEE Std 802.1X-2001,
               June 2001.

5.  Informative references

[IEEE80211]    Information technology - Telecommunications and
               information exchange between systems - Local and
               metropolitan area networks - Specific Requirements Part
               11:  Wireless LAN Medium Access Control (MAC) and
               Physical Layer (PHY) Specifications, IEEE Std.
               802.11-1999, 1999.







































Kamath, Palekar & Wodrich     Informational                     [Page 9]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


Appendix A - Examples

In the case where an identity exchange occurs within
PEAP Part 1, the conversation will appear as follows:

Authenticating Peer     Authenticator
-------------------     -------------
                        <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                        <- EAP-Request/
                        EAP-Type=PEAP, V=0
                        (PEAP Start, S bit set)

EAP-Response/
EAP-Type=PEAP, V=0
(TLS client_hello)->
                        <- EAP-Request/
                        EAP-Type=PEAP, V=0
                        (TLS server_hello,
                         TLS certificate,
                 [TLS server_key_exchange,]
                 [TLS certificate_request,]
                     TLS server_hello_done)
EAP-Response/
EAP-Type=PEAP, V=0
([TLS certificate,]
 TLS client_key_exchange,
[TLS certificate_verify,]
 TLS change_cipher_spec,
 TLS finished) ->
                        <- EAP-Request/
                        EAP-Type=PEAP, V=0
                        (TLS change_cipher_spec,
                         TLS finished)
EAP-Response/
EAP-Type=PEAP ->

TLS channel established
(messages sent within the TLS channel)

                       <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                       <- EAP-Request/
                        EAP-Type=X



Kamath, Palekar & Wodrich     Informational                    [Page 10]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


EAP-Response/
EAP-Type=X or NAK ->

                       <- EAP-Request/
                        EAP-Type=X
EAP-Response/
EAP-Type=X  ->
                        <- EAP-Request/
                           EAP-Type=Extensions
                           Result=Success
EAP-Response/
EAP-Type=Extensions
Result=Success  ->

TLS channel torn down
(messages sent in clear-text)

                        <- EAP-Success

In the case where the PEAP fragmentation is required, the conversation
will appear as follows:

Authenticating Peer     Authenticator
-------------------     -------------
                        <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                        <- EAP-Request/
                        EAP-Type=PEAP, V=0
                        (PEAP Start, S bit set)

EAP-Response/
EAP-Type=PEAP, V=0
(TLS client_hello)->
                        <- EAP-Request/
                        EAP-Type=PEAP, V=0
                        (TLS server_hello,
                         TLS certificate,
                 [TLS server_key_exchange,]
                 [TLS certificate_request,]
                     TLS server_hello_done)
                 (Fragment 1: L, M bits set)
EAP-Response/
EAP-Type=PEAP, V=0 ->
                        <- EAP-Request/
                           EAP-Type=PEAP, V=0
                        (Fragment 2: M bit set)



Kamath, Palekar & Wodrich     Informational                    [Page 11]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


EAP-Response/
EAP-Type=PEAP, V=0 ->
                        <- EAP-Request/
                        EAP-Type=PEAP, V=0
                        (Fragment 3)
EAP-Response/
EAP-Type=PEAP, V=0
([TLS certificate,]
 TLS client_key_exchange,
[TLS certificate_verify,]
 TLS change_cipher_spec,
 TLS finished)
 (Fragment 1: L, M bits set)->

                         <- EAP-Request/
                        EAP-Type=PEAP, V=0
EAP-Response/
EAP-Type=PEAP, V=0
(Fragment 2)->
                       <- EAP-Request/
                        EAP-Type=PEAP, V=0
                        (TLS change_cipher_spec,
                         TLS finished)

EAP-Response/
EAP-Type=PEAP, V=0 ->

TLS channel established
(messages sent within the TLS channel)

                       <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                       <- EAP-Request/
                        EAP-Type=X
EAP-Response/
EAP-Type=X or NAK ->

                       <- EAP-Request/
                        EAP-Type=X
EAP-Response/
EAP-Type=X  ->
                        <- EAP-Request/
                           EAP-Type=Extensions
                           Result=Success
EAP-Response/
EAP-Type=Extensions



Kamath, Palekar & Wodrich     Informational                    [Page 12]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


Result=Success  ->

TLS channel torn down
(messages sent in clear-text)

                        <- EAP-Success

In the case where the server authenticates to the client
successfully in PEAP Part 1, but the client fails to authenticate
to the server in PEAP Part 2, the conversation will appear as follows:

Authenticating Peer     Authenticator
-------------------     -------------
                        <- EAP-Request/
                        Identity
EAP-Response/
Identity (MyID) ->
                        <- EAP-Request/
                        EAP-Type=PEAP, V=0
                        (PEAP Start, S bit set)
EAP-Response/
EAP-Type=PEAP, V=0
(TLS client_hello)->
                        <- EAP-Request/
                        EAP-Type=PEAP, V=0
                        (TLS server_hello,
                         TLS certificate,
                 [TLS server_key_exchange,]
                 [TLS certificate_request,]
                     TLS server_hello_done)
EAP-Response/
EAP-Type=PEAP, V=0
([TLS certificate,]
 TLS client_key_exchange,
[TLS certificate_verify,]
 TLS change_cipher_spec,