Subject: 2nd Notice: EAP Implementation Survey

From: Bernard Aboba <[email-masked]>
Date: Sat, 18 Aug 2001 16:36:20 -0700 (PDT)

This is the second notice relating to the EAP Implementation survey
required for RFC 2284bis. If you have not already filled out the survey
relating to your EAP implementation, please do so now. 

                        EAP Implementation Survey
                        -------------------------

Please fill this out and return it to [email-masked] by September 21, 2001.

For EAP (RFC 2284) to advance to Draft Standard, every feature must have at
least two independent implementations, or must be cut from the draft.
I'm putting together the RFC 2284bis document.  Please read these directions
carefully and email your answers to me directly, not to the list.

I only need a reply to this if your implementation is INDEPENDENT, that
is, not based on another implementation. If you started out once upon
a time with another code base and eventually replaced all the code
with fresh code, that counts as independent.  If you did your
implementation from scratch, better yet.

Please provide contact information and fill out the Company, Product
and Version fields following their colons, and mark the features
with a Y or N *before* the feature, and keep the spelling and order
exactly as they are here (so I can automate processing the results).
Lines starting with __ are headers and should not be marked.

Y means you support that feature in your EAP implementation NOW, N means you
do not.  No fair saying you'll be adding it later, it has to be in your
implementation that's already done and being used somewhere, although
beta or experimental software counts as in use, as long as its actually
running.

If you make both an EAP client and access device, please send in
two submissions (as two separate email messages), one for each.
If you make different flavors of access device (say, a switch,
access point and NAS), but they have the same EAP implementation,
you only need to send me an entry for one flavor. Similarly,
if you ship multiple client implementations, but they are using
the same code base, just send me one entry.

Contact name:
Contact email address:
Contact phone number:
Company name:
Product Name:
Product Version:
Client or Access Device (only one per entry):
Media Type(s) Supported (PPP, IEEE 802, Bluetooth, Other):
If Other, please describe:

__ Configuration Option
LCP Configuration option (C227) supported

__ Message Codes supported:
Request
Response
Success
Failure

__ EAP Types supported:
Identity
Notification
Nak (Response only)
MD5-Challenge
One-Time Password (OTP) (RFC 1938)
Generic Token Card

__ Length field check
Octets outside the range of the Length field ignored on reception

__ Request and Response messages
One Type specified per EAP Request or Response
Type field of the Response same as the Type of the Request (except Nak)
Authenticator transmits Request
Peer sends a Response packet in reply to a Request
Responses not retransmitted on a timer
Identifier field of Response matches that of the Request
Retransmitted Request sent with same Identifier value
New (non-retransmission) Requests modify the Identifier field
Additional Requests sent until a valid Response is received, or
  retry counter expires
Retransmission timer of 6 seconds with a maximum
  of 10 retransmissions used as default
Peer silently discards received retransmissions while waiting for
  user input

__ Success and Failure messages
Success packet is sent by the authenticator to the peer
Success packet is not sent by peer to authenticator
Success packet acknowledges successful authentication
Success packet sent with Code field set to 3
Failure packet is sent by the authenticator to the peer
Failure packet is not sent by peer to authenticator
Failure packet acknowledges unsuccessful authentication
Failure packet sent with Code field set to 4
Authenticator issues multiple Requests before sending a Failure
Peer allows for loss of Success and Failure packets
Peer uses Network protocol packet as alternative indication of Success
Peer uses receipt of LCP Terminate-Request as alternative indication of
Failure

__Identity type
Identity Request can contain a displayable message
Identity field is not null terminates
Length of identity field derived from Length field
Identity can be bypassed
If Identity is unknown, Identity Response is zero bytes in length
Authenticator retries Identity Request
Identity Request retried a minimum of 3 times before termination
Failure indicated within new Identity Request

__ Notification type
Peer displays Notification to the user
Peer logs Notification if it cannot be displayed
Notification request used to indicate invalid authentication attempt
Notification is not null terminated
Length of notification field derived from Length field
Response sent in reply to Notification Request
The Type-Data field of Notification Response is zero octets in length
Notification Response sent immediately (independent of display or logging)

__ Nak type
Nak Type sent in Response
Nak Type NOT sent in a Request
Nak Type-data field contains single octet indicating desired auth type

__ MD5-Challenge type
MD5-Challenge Response can be sent in reply to MD5-Challenge Request
Nak message can be sent in reply to MD5-Challenge Request

__ OTP type
Request contains OTP challenge
Request is not null terminated
Length of Request derived from Length field
Type 5 (OTP) Response can be sent in reply to the Request
Type 3 (Nak) Response can be sent in reply to the Request

__ Generic Token Card type
Request contains displayable message greater than zero octets in length
Length of message determined by length field
Request is not null terminated
Type 6 (GTC) response can be sent in reply to GTC Request
Type 3 (Nak) response can be sent in reply to GTC Request

__ Security considerations
Upon authentication failure, link is terminated
Upon authentication failure, traffic limited to filtered subset
Counters used for authentication failure not reset until after
   successful authentication, link termination
For each named user support for exactly one authentication method