Subject: [eap] Issue 42: EAP Enhancements

From: [email-masked] (Bernard Aboba)
Date: Tue, 5 Nov 2002 17:15:48 -0800 (PST)

Issue 42: EAP Enhancements
Submitter: Tena Tsou
Submitter email address: [email-masked]
Date first submitted: November 5, 2002
Reference: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue 42
Document: RFC2284bis-07, 802.1aa D3
Comment type: T
Priority: S
Section:  Many

Rationale/Explanation of issue:

This comment was received during IEEE balloting on IEEE 802.1aa Draft 3.
Since it requests EAP protocol changes, it has been filed as an EAP Issue
for resolution by EAP WG. For a full transcript of the issue, including
the recommended revised EAP packet format, see Issue 42 on the EAP Issues
list.

Supplementary Comment to IEEE P802.1aa

Add this section to the end of Section 8.4:

1.1.1. Handshaking mechanism

The Authenticator should be able to detect users abnormal disconnection
and provide the online users and charging information as precise as
possible. The Authenticator should support the handshaking mechanism with
the Supplicant. During the handshaking, the controlled ports keep the
authorized status, until the handshaking fails, then the controlled ports
turn to the unauthorized status.

The Authenticator uses EAP-Request/Identity as the handshaking request
packet, and the Supplicant uses EAP-Response/Identity as the handshaking
response packet.

It is recommended to set the range allowed for the handshaking period
(must be configurable) to 5-90s, and its default value to 15s. Moreover,
the handshaking period should be less than the parameter value of
authPeriod when the Supplicant PAE performs re-authentication for the
timer authWhile (see IEEE std 802.1X-2001, 8.5), and the recommended
parameter value of authPeriod is as twice as the handshaking period at
least.

The maximum times of handshaking should be configurable and the
recommended value is 3.

The requirements on 802.1X Supplicant:

The following should be added to the end of the Section 7.7.4 (see the red
below):

EAP packet format

When the protocol field of the PPP frame (see IETF RFC 1661) indicates
that the protocol type is C227 (PPP EAP), only one PPP EAP packet is
encapsulated in the Information field of the frame in PPP data link layer.
The format of EAP packet is shown in Figure A-1.Each field is transmitted
from left to right one by one.

Figure A-1 EAP packet format

(See EAP Issues list for Figure)

A.1.1. Code

The Code field is one octet in length and identifies the type of EAP
packet. EAP Codes are assigned as follows:

1 Request
2 Response
3 Success
4 Failure

A.1.2. Identifier

The Identifier filed is one octet in length and allows matching of
Response with Request. The Identifier field and System Port together
uniquely identify an authentication exchange. Thus, the use of a single
octet identifier field results in a restriction of 256 authentications per
System Port.

The operation of the Authenticator PAE determines the value of Identifier
used in the EAP-Request/Identify packets. The Supplicant PAE uses the same
Identifiers in subsequent EAP-Request/Identify packets responding to that
initial frame. The Authenticator PAE uses the same Identifier value in any
re-transmissions of the same request.

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

A.1.4. Data
The Data field is zero or more octets. The format of the Data field is
determined by the Code field.

Type

The Type field is one octet and mainly defines various authentication
mechanisms. The Type values in ITEF RFC 2284 include the first six of the
following. As required, the No. 7 and 8 Type values are added into this
standard. The Type values 1~2, 4~7 and 13 apply to the Request and
Response packet, the Type value 3 only applies to the Response packet and
the Type value 8 only applies to the Failure packet.

1 Identity
2 Notification
3 Nak (Response only)
4 MD5-Challenge
5 One-Time Password (OTP) (RFC1938)
6 Generic Token Card
7 PAP
8 CauseCode

A.1.5. Identity

The Identity type is used to query the users status. Each Identity type of
Request packet should correspond to an Identity type of Response packet.

A.1.6. Notification
The Notification type is used to send an on-screen message from the
Authenticator to the Supplicant. The Supplicant should display the message
for the users. If it can not be displayed, it should be recorded into the
log.

Each Notification type of Request packet should correspond to a
Notification type of Response packet.

A.1.7. Nak

The Nak type only applies to the Response packet. When the expected
authentication mechanism in the Request packet is not accepted, the Nak
type of Response packet should be sent.

A.1.8. MD5-Challenge

The MD5-Challenge type is similar to the MD5 in CHAP protocol (see IETF
RFC 1994). The MD5-Challenge type of Request packet includes the Challenge
message. Each MD5-Challenge type of Request packet should correspond to an
MD5-Challenge type or a Nak type of Response packet.

A.1.9. One-Time Password
The One-Time Password type of Request packet includes an OTP Challenge.
Each One-Time Password type of Request packet should correspond to a
One-Time Password type or a Nak type of Response packet.
Refer to IETF RFC 1938 for more information about One-Time Password
System.

A.1.10. Generic Token Card

The Generic Token Card type is defined for the users to enter various
Token Card messages. The Generic Token Card type of Request packet
includes an ASCII text message, and the corresponding Generic Card type of
Response packet includes the necessary information related to the Token
Card. Usually the information is read by the users from the Token Card
device and is entered in ASCII text.

A.1.11. PAP

The PAP type is similar to the PPP PAP protocol. The difference is that
the PPP PAP must be originated by the Supplicant, while the PAP in EAP can
be originated by the Authenticator. In the Request packet, use the No.7
type value to originate the PAP authentication and request the password of
the other party. The password is sent in plain text on the network. Each
PAP type of Request packet should correspond to a PAP type or a Nak type
of Response packet.

A1.12. CauseCode

The CauseCode type is used to give the failure causes of authentication
for the Supplicant. The CauseCode Values give the failure causes.

The CauseCode Values include the following eight types:

1 Name-Pwd-Failure Incorrect user name and the password
2 IdleCut Idle cut logoff
3 TimeCut Time restriction cut off
4 FlowCut Flow restriction cut off
5 Supplicant-Logoff Supplicant logoff actively
6 Supplicant-Restart  Supplicant restarting
7 Reauthen-Failure  Re-authentication failure
8 Other-Failure  Other causes of failure

Tena Tsou
Signalling and Protocol Department, R&D
Huawei Tech.
Tel:86-755-26516939
[email-masked]

---

From: [email-masked] (Glen Zorn)
Date: Wed, 6 Nov 2002 21:38:40 -0800

> Issue 42: EAP Enhancements

Recommend rejection.  There are almost too many problems with this issue to
list.  First, the expected applicability of the "Handshaking mechanism" is
unclear: what is the purpose of this heartbeat?  AFAIK, virtually all link
layers have a link-down indication of some type and reliability; why recover
this functionality in EAP?  Second, the actual heartbeat mechanism provides
virtually no assurance that the user/peer that sent the nth heartbeat is the
same as the user/peer that sent the n-1st, since Identity responses are not
authenticated.  Last but not least, though the ability to transmit plaintext
passwords is of indubitable utility, it opens a hole in EAP about a mile
wide and is rarely actually necessary.

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>
>

---

From: [email-masked] (Jari Arkko)
Date: Thu, 07 Nov 2002 05:50:44 +0200

Is there a particular reason why frequent (re-)authentication couldn't
provide the desired functionality? Too costly?

On some link-layers, the receipt of a packet signed with keys produced
during initial EAP authentication may also be taken as a proof that the
peer is still connected.

Jari