draft-kamath-pppext-peapv0-00.txt

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

PPPEXT Working Group                                        Vivek Kamath
INTERNET-DRAFT                                            Ashwin Palekar
Category: Informational                                     Mark Wodrich
<draft-kamath-pppext-peapv0-00.txt>                            Microsoft
25 October 2002


     Microsoft's PEAP version 0 (Implementation in Windows XP SP1)

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright Notice

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

Abstract

This specification documents the implementation of PEAP supported in
Windows XP SP1. This implementation utilizes a version number of zero
(0) and supports acknowledged and protected success and failure
indications, using the EAP Extensions method, Type 33.














Kamath, Palekar & Wodrich     Informational                     [Page 1]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


Table of Contents

1.     Introduction ..........................................    3
   1.1       EAP encapsulation ...............................    3
   1.2       Version field ...................................    3
   1.3       EAP Extensions method ...........................    4
2.     Details of EAP extensions method ......................    4
   2.1       Extensions Request Packet .......................    4
   2.2       Extensions Response Packet ......................    5
   2.3       AVP format ......................................    6
3.       Security considerations .............................    7
   3.1       Authentication and integrity protection .........    7
   3.2       Outcomes ........................................    7
4.       Normative references ................................    8
5.       Informative references ..............................    9
Appendix A - Examples ........................................   10
Acknowledgments ..............................................   18
Author's Addresses ...........................................   18
Intellectual Property Statement ..............................   18
Full Copyright Statement .....................................   19































Kamath, Palekar & Wodrich     Informational                     [Page 2]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


1.  Introduction

Microsoft's Windows XP SP1 implementation of PEAP version 0 differs in
the following ways from the protocol specified in [PEAP].

   Version field
   EAP encapsulation
   Acknowledged and protected success and failure using EAP extensions method

PEAP protocol [PEAP] supports versioning and hence servers and clients can
support multiple versions of the protocol. [PEAP] is currently at version 1.
Each of these differences is explained in the sections that follow.

1.1.  EAP encapsulation

The [PEAP] specification requires that EAP packets be tunneled within a
TLS channel in their entirety. However, the Windows XP SP1
implementation of PEAP does not include an EAP header on packets sent
within the TLS channel, except for EAP Extension packets (Type 33),
where the complete header is sent.  As a result, for EAP Types other
than 33, the Code, Identifier, and Length fields are not sent, but
rather EAP packets sent within the PEAP tunnel begin with the Type
field.

While the Code, Identifier and Length fields are not sent over the wire,
they are reconstructed at the receiver prior to EAP processing.  For
example, the Code and Identifier fields of the tunneled EAP packet are
assumed to be the same as the equivalent fields within the outer EAP
header, and the Length field of the tunneled EAP packet is derived from
the Length field of the PEAP packet.  This has the following
implications:

[a]  The Code field of the tunneled EAP packet is assumed to be the same
     as the Code field of the PEAP packet. This may not always be the
     case; for example, an EAP Success or Failure packet (Code 3 and 4)
     may be tunneled within a PEAP Request packet (Code 1). This means
     that the Windows XP SP1 implementation of PEAP is incapable of
     tunneling arbitrary EAP packets.

[b]  Since the full EAP header is sent for the EAP Extensions type (Type
     33), but not for other Types, it is difficult for the
     implementation to distinguish an Extensions Request (Code 1) from
     an EAP Type 1 (Identity) Request packet.  In practice, this implies
     that the Windows XP SP1 PEAP implementation can only support
     authentication using a single EAP method per session.






Kamath, Palekar & Wodrich     Informational                     [Page 3]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


1.2.  Version Field

[PEAP] is currently a work-in-progress.  In order to allow for backward
compatibility once the final specification of PEAP is completed, a
version field of zero (0) is used, rather than the value of one (1)
required for conformant implementations as specified in [PEAP].

Note that use of distinct version numbers enables backward compatibility
once the final specification of PEAP is complete.  Version negotiation
takes place at the start of the conversation, with the authenticator
indicating its highest supported version. The peer then responds with
the highest version it supports. The conversation will then occur using
the highest version supported by both parties. This behavior is
illustrated in the last example in Appendix A.

1.3.  EAP extensions method

The [PEAP] termination mechanism (sending an encrypted EAP Success or
EAP Failure packet) does not function correctly with Authenticators
implementing [IEEE8021X]. Since IEEE 802.1X authenticators "manufacture"
a clear-text EAP Success based on receipt of a RADIUS Access-Accept, or
a clear-text EAP Failure based on receipt of a RADIUS Access-Reject,
unless an acknowledged success/failure indication is used, the PEAP
Supplicant may never receive a protected success/failure indication.
This leaves the PEAP Supplicant open to attack. As a result, the Windows
XP SP1 PEAP implementation supports acknowledged and protected
success/failure indications, using the EAP Extensions method (Type 33).

2.  Details of EAP extensions method

The packet formats for the EAP Extensions method (type 33) follow.

2.1.  Extensions Request Packet

A summary of the Extensions Request packet format is shown below.  The
fields are transmitted from left to right.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |   Identifier  |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |                  Data....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

   1



Kamath, Palekar & Wodrich     Informational                     [Page 4]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


Identifier

   The Identifier field is one octet and aids in matching responses with
   requests.  The Identifier field MUST be changed on each Request
   packet.

Length

   The Length field is two octets and indicates the length of the EAP
   packet including the Code, Identifier, Length, Type, and Data fields.

Type

   33 - EAP Extensions

Data
   The Data field is of variable length, and contains Attribute-Value
   Pairs (AVPs).

2.2.  Extensions Response Packet

A summary of the Extensions Response packet format is shown below.  The
fields are transmitted from left to right.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |   Identifier  |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |                  Data....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

   2

Identifier

   The Identifier field is one octet and aids in matching responses with
   requests.  The Identifier field MUST be changed on each Request
   packet.

Length

   The Length field is two octets and indicates the length of the EAP
   packet including the Code, Identifier, Length, Type, and Data fields.

Type



Kamath, Palekar & Wodrich     Informational                     [Page 5]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


   33 - EAP Extensions

Data
   The Data field is of variable length, and contains Attribute-Value
   Pairs (AVPs).

2.3.  AVP format

Extensions AVPs are defined as follows:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|            AVP Type       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

   0 - Non-mandatory AVP
   1 - Mandatory AVP

R

   Reserved, set to zero (0)

AVP Type

   A 14-bit field, denoting the attribute type. Allocated AVP Types
   include:

   0 - Reserved
   1 - Reserved
   2 - Reserved
   3 - Acknowledged Result

Length

   The length of the value field in octets.

Value

   The value of the attribute.







Kamath, Palekar & Wodrich     Informational                     [Page 6]





INTERNET-DRAFT               PEAP Version 0              25 October 2002


2.3.1.  Result AVP

The Result AVP provides support for acknowledged Success and Failure
within EAP. It is defined as follows:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         AVP Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Status           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M