[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
PPPEXT Working Group                                            B. Aboba
INTERNET-DRAFT                                                 Microsoft
Category: Standards Track
<draft-aboba-pppext-eap-vendor-01.txt>
24 February 2002
Updates: RFC 2284


                     The Vendor-Specific EAP Method

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 document defines a Vendor-Specific Method for the Extensible
Authentication Protocol (EAP), defined in RFC 2284.


1.  Introduction

The Extensible Authentication Protocol (EAP), defined in [RFC2284]  is a
general protocol for authentication which supports multiple
authentication mechanisms.  EAP may be used on dedicated links as well
as switched circuits, and wired as well as wireless links.

To date, EAP has been implemented with hosts and routers that connect
via switched circuits or dial-up lines using PPP [RFC1661]. It also also
been implemented with switches and wireless access points [IEEE80211]



Aboba                        Standards Track                    [Page 1]


INTERNET-DRAFT         EAP Vendor-Specific Method       24 February 2002


over IEEE 802 local area networks [IEEE802] implementing IEEE 802.1X
[IEEE8021X].

Due to EAP's popularity, the original Method Type space, which only
provides for 255 values, is being allocated at a pace, which if
continued, would result in exhaustion within a few years.  Since many of
the existing uses of EAP are vendor-specific, the Vendor-Specific Method
Type is available to allow vendors to support their own extended Types
not suitable for general usage. The Vendor-specific Type may also be
used to expand the global Method Type space beyond the original 255
values.

1.1.  Specification of Requirements

In this document, several words are used to signify the requirements of
the specification.  These words are often capitalized.  The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119].

2.  EAP Vendor Specific Method

Description

   This Method Type is available to allow vendors to support their own
   extended Types not suitable for general usage.  The Vendor-specific
   Type may also be used to expand the global Method Type space beyond
   the original 255 values.

   Peers not equipped to interpret the vendor-specific information sent
   by an authenticator MUST send a NAK, and negotiate a more suitable
   authentication method.

   A summary of the Vendor-specific Type 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |               Vendor-Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

   255 for Vendor-specific




Aboba                        Standards Track                    [Page 2]


INTERNET-DRAFT         EAP Vendor-Specific Method       24 February 2002


Vendor-Id

   The Vendor-Id is 3 octets and represents the SMI Network Management
   Private Enterprise Code of the Vendor in network byte order, as
   allocated by IANA. A Vendor-Id of zero is reserved for use by the
   IETF in providing an expanded global EAP Type space.

String

   The String field is one or more octets.  The actual format of the
   information is site or application specific, and a robust
   implementation SHOULD support the field as undistinguished octets.

   The codification of the range of allowed usage of this field is
   outside the scope of this specification.

   It SHOULD be encoded as follows.  The Vendor-Specific field is
   dependent on the vendor's definition of that attribute.  An example
   encoding of the Vendor-Specific attribute using this method follows.

Example Implementation

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |               Vendor-Id                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor-Type                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Vendor-Specific...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Vendor-Type

   The Vendor-Type field is four octets and represents the vendor-
   specific Method Type. Where a Vendor-Id of zero is present, the
   Vendor-Type field provides an expanded global EAP Type space,
   beginning with EAP Type values of 256.

Vendor-Specific

   The Vendor-Specific field is dependent on the vendor's definition of
   that attribute. Where a Vendor-Id of zero is present, the Vendor-
   Specific field will be used for transporting the contents of EAP
   Methods of Types 256 or greater.





Aboba                        Standards Track                    [Page 3]


INTERNET-DRAFT         EAP Vendor-Specific Method       24 February 2002


3.  IANA Considerations

This document requires allocation of EAP Method Type 255 for vendor-
specific use.

4.  Normative references

[RFC1661]
     Simpson, W., "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", RFC 2119, March 1997.

[RFC2434]
     Alvestrand, H. and Narten, T., "Guidelines for Writing an IANA
     Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

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

[IEEE802]
     IEEE Standards for Local and Metropolitan Area Networks: Overview
     and Architecture, ANSI/IEEE Std 802, 1990.

[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-1997, 1997.

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

5.  Security Considerations

Since support for the Vendor-specific type is optional, it cannot be
used to support methods whose use is mandatory in a given situation. As
a result, EAP methods that are expected to find common use should be
allocated Method Types of 254 or less.







Aboba                        Standards Track                    [Page 4]


INTERNET-DRAFT         EAP Vendor-Specific Method       24 February 2002


Acknowledgments

Thanks to John Vollbrecht of Interlink Networks and Tim Moore of
Microsoft for discussions relating to this document.

Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax:   +1 425 706 7329

Full Copyright Statement

Copyright (C) The Internet Society (2002).  All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.  The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns.  This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Expiration Date

This memo is filed as <draft-aboba-pppext-eap-vendor-01.txt>,  and
expires August 19, 2002.








Aboba                        Standards Track                    [Page 5]