Internet DRAFT - draft-aboba-pppext-eap-vendor
draft-aboba-pppext-eap-vendor
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]
