One document matched: draft-aboba-ieee802-rel-00.txt
Network Working Group Les Bell
INTERNET-DRAFT 3Com Europe Limited
Category: Informational Dan Romascanu
<draft-aboba-ieee802-rel-00.txt> Avaya Inc.
13 June 2003 Bernard Aboba
Microsoft Corporation
History of the IEEE 802/IETF Relationship
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 (2003). All Rights Reserved.
Abstract
Since the mid 1990s, IEEE 802 and IETF have cooperated in the
development of SNMP MIBs and AAA applications. This document describes
the history of that cooperation, and the policies and procedures that
have developed in order to coordinate between the two organizations.
1. Introduction
Since the mid-1990s, participants in IEEE 802 and the IETF have
cooperated in the development of MIBs and AAA applications relating to
IEEE standards. This has included the the Hub MIB [RFC2108], MAU MIB
[RFC2668], revisions to the Ethernet-like Interfaces MIB [RFC2665], the
WAN Interfaces Sublayer MIB [WISMIB], the Power Ethernet MIB [PETH],
multicast filtering and VLAN extension MIB [RFC2674], the IEEE 802.1X
MIB [8021XMIB], IEEE 802.1X RADIUS usage guidelines [Congdon],
Bell, Romascanu & Aboba Informational [Page 1]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
RADIUS/EAP [RFC2869bis], the revised EAP specification [RFC2284bis], and
the EAP State Machine specification [EAPSTATE]. This document describes
the history of the IEEE 802/IETF relationship, as well as the policies
and procedures that have been put in place to encourage cooperation.
2. MIB Development
2.1. Bridge MIB
The relationship between IETF and IEEE 802 began in the late 1980s with
SNMP MIBs developed for the original IEEE 802.1D standard. Because the
IEEE specification [IEEE8021D] contained only a functional definition of
the counters and operations, the IETF's Bridge MIB WG took on the role
of defining the Bridge MIB [RFC1493] which was published as an RFC.
Coordination between IETF and IEEE 802.1 was largely handled by the IETF
Bridge WG chairs Keith McCloghrie and Fred Baker.
2.2. MAU and Hub MIBs
In the early 1990s when IEEE 802.3 was completing the first Ethernet
standards, SNMP was not yet the dominant network management protocol.
As a result, a 'protocol independent' MIB is included in Clause 30 of
the IEEE 802.3 standard [IEEE8023], which is updated each time the
Ethernet standard is enhanced to support higher speeds. In parallel,
IEEE 802 participants interested in network management were active in
the formation of the IETF HUBMIB WG, which took on the task of
transforming IEEE 802 definitions into SNMP MIBs documented as Standards
Track RFCs. This included Dan Romascanu, Chair of the IETF HUBMIB WG
since 1996.
The Charter of the HUBMIB WG explicitly mentions that the IEEE 802.3
standard is the starting point for the Ethernet MIB, but at the same
time reserves the right to deviate from the IEEE model - either to cover
only part of the capabilities offered by the standard, or add MIB
objects that are not directly derived from the IEEE model (mostly
implemented in software). If management needs lead to requirements for
hardware support, the IETF HUBMIB WG is to provide this input to IEEE
802.3 in a timely manner.
Cooperation between the IETF HUBMIB WG and IEEE 802.3 has continued for
more than a decade until today, mostly based on the work of a few
editors supported by their companies, who are taking the IEEE standards
and mapping them into a management data model and MIBs. Work items
include:
- The Hub MIB [RFC2108], which has gone through three iterations,
and is probably ending its evolution, as repeaters are less used
Bell, Romascanu & Aboba Informational [Page 2]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
in Ethernets.
- The MAU MIB, which has been updated each time a new Ethernet speed
is developed, with [RFC2668] now being revised to accommodate
10 Gbps Ethernet.
- The Ethernet-like Interfaces MIB was not originally a work item
of the HUBMIB WG, but since the publication of [RFC2665] the WG
has taken responsibility for a revision, which is now in progress.
- The WAN Interfaces Sublayer MIB [WISMIB], and the Power Ethernet MIB
[PETH] are relatively new items in IEEE 802.3 and the IETF HUBMIB WG,
and are currently under review by the IESG.
In 2000, an official liason was established between IEEE 802.3 and the
IETF HUBMIB WG, and Dan Romascanu was appointed IETF liason. The
conditions of the liason agreement allows editors and other participants
in the IETF HUBMIB WG access to work-in-progress drafts in IEEE 802.3 on
a personal basis, for the purpose of working on MIBs before the release
of the standard. However, the username and password for IEEE 802.3
document access are not for publication on any IETF Web site or mail
list.
2.3. 802.1p/Q MIB
In 1996 as the 802.1p and 802.1Q standards were being completed, a need
was perceived for development of an SNMP MIB, based on the management
clauses of those standards. IEEE 802 management clauses are written in
a manner that was independent of any protocol that may be used to
implement them.
At that time, there were a number of proprietary VLAN management MIBs
which were both inadequate and difficult to understand. As a result
there was a need for a more comprehensive, simpler model for VLAN
management, along with the priority and multicast filtering management
also defined by these standards.
A small group of participants from the 802.1 WG began working on the
problem independently, then combined their work. The original authors
of the Bridge MIB, on which some of the work was based, reviewed the
initial work.
By the end of 1997, the work was ready for review by a larger audience.
Andrew Smith worked with Keith McCloghrie, chair of the Bridge MIB WG
(dormant at the time) to obtain a meeting slot at the March 1998 IETF
Meeting. After this, review and development of the MIB continued on the
IETF standards track.
During the development of [RFC2674], there was no official inter-working
between the IETF Bridge-MIB and IEEE 802.1 groups. Development of this
MIB was successful, because the main developers (Andrew Smith and Les
Bell, Romascanu & Aboba Informational [Page 3]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
Bell) were involved in both IEEE 802.1 as well as the IETF Bridge MIB
WGs.
2.4. 802.3ad and 802.1X MIBs
As part of the IEEE 802.3ad and IEEE 802.1X standards work, it was
decided that it would better to develop a MIB as part of the standards,
rather than wait until an IETF WG was formed, and develop the MIBs
separately, so as to avoid a significant time lag in their development.
As Les Bell was the participant in IEEE 802.3ad and IEEE 802.1 most
familiar with SNMP MIB development, he put together the initial MIBs
based on the management framework the groups had come up with.
Additional assistance was then received for both MIBs from within the
IEEE 802.3ad and IEEE 802.1X groups. Tony Jeffree, editor of both
standards, acted as editor of the MIBs as well.
The problem with IEEE 802 developing these MIBs without IETF involvement
was the lack of review. IEEE 802 members are generally not familiar
with MIBs and very few comments were received as part of the balloting
process for either MIB.
In the case of the IEEE 802.3ad MIB, this meant that basic errors were
not discovered until just before publication. Unfortunately by then it
was too late, and the corrections submitted to the IEEE 802.3ad chair
and document editor did not get applied to the published version.
To solicit additional review, the IEEE 802.1X MIB was re-published as an
Internet-Draft [8021XMIB] within the Bridge WG. This occurred after
publication of [IEEE8021X].
2.5. 802.1t, 802.1u, 802.1v and 802.1w MIBs
802.1t and 802.1u were minor amendments to the 802.1D and 802.1Q
standards, requiring some additions to the MIB published in [RFC2674].
802.1v was a new feature extending the VLAN classification schemes of
802.1Q, also requiring extensions to [RFC2674]. 802.1w was a new
version of Spanning Tree, requiring re-writing of part of [RFC1493].
When Les Bell took on the role of Chair of the IETF Bridge-MIB WG in
2001, these issues were raised as new work items and two volunteers were
found to become editors of the Internet Drafts. A work item was also
included to publish the IEEE 802.1X MIB as an Informational RFC.
This approach worked well for a while, but it then became difficult for
the participants, including the editors and the Chair, to sustain a
level of interest sufficient to overcome the difficulties introduced by
budget cut-backs. As a result, the drafts have now expired, although
Bell, Romascanu & Aboba Informational [Page 4]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
there are no significant technical issues outstanding.
3. AAA/EAP
Since the late 1990s, IEEE 802.1 has been involved in work relating to
authentication and authorization [IEEE8021X], which has lead to
uncovering of issues in several IETF specifications, including
[RFC2284], and [RFC2869]. Similarly, IETF participants have uncovered
issues in the RADIUS usage specifications such as [Congdon], as well as
the IEEE 802.1X state machine [Mishra].
In order to address these issues and ensure synchronization between IEEE
802.1 and the IETF EAP and AAA WGs, a liason arrangement has been
devised that has so far been relatively successful.
More recently, IEEE 802.11 groups such as IEEE 802.11i and IEEE 802.11f
have also become dependent on EAP and AAA work. This relationship is
still evolving, but is somewhat more challenging since IEEE 802.11 has a
need for features such as RADIUS extensions, new EAP methods and an EAP
Keying Framework that represent substantial new IETF work, as opposed to
the clarifications and updates that have been required by IEEE 802.1.
As a result, the likelihood of IETF process delays affecting completion
of IEEE standards is considerably greater. Going forward, the IETF and
IEEE 802 will need to work to resolve the tension between timely
delivery of standards and the need for thorough IETF review.
3.1. IEEE 802.1X
IEEE 802.1X-2001 [IEEE8021X] defined the encapsulation of EAP [RFC2284]
over IEEE 802, as well as a state machine for the joint operation of
IEEE 802.1X and EAP.
During the development of [IEEE8021X], several problems were discovered
in the specification for RADIUS/EAP [RFC2869], and as a result, work was
begun on a revision [RFC2869bis]. In addition, clarifications were
required on how RADIUS attributes defined in [RFC2865], [RFC2866],
[RFC2867], [RFC2868], [RFC2869], and [RFC3162] would be interpreted by
IEEE 802.1X implementations, and so a non-normative RADIUS usage
appendix was added to [IEEE8021X], and subsequently republished as an
Internet-Draft [Congdon].
Subsequent to the publication of [IEEE8021X], a formal analysis of the
IEEE 802.1X state machine by the University of Maryland disclosed
several security issues [Mishra]. After discussion within IEEE 802.1aa,
the group chartered to revise IEEE 802.1X, it was decided that the
issues were the result of lack of clarity in [RFC2284], and the absence
of an EAP state machine document.
Bell, Romascanu & Aboba Informational [Page 5]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
At that time, work on EAP was handled within the IETF PPPEXT WG, which
was largely inactive. In order to handle work on a revised EAP
specification [RFC2284bis] as well as an EAP state machine document, the
IETF EAP WG was formed in July 2002. Bernard Aboba, a participant in
IEEE 802.1X and IEEE 802.1aa, was named co-chair.
Work on the EAP state machine [EAPSTATE] and [RFC2284bis] specifications
have proceeded in parallel within EAP WG, with issues or changes in one
document requiring changes to the other document, as well as in some
cases revisions to IEEE 802.1X [IEEE8021aa]. The revised RADIUS/EAP
specification [RFC2869bis] has been reviewed within EAP WG, although it
is not a WG work item.
A revision to IEEE 802.1X [IEEE8021aa] is now in progress, which
includes the following:
- a revised RADIUS usage appendix based on [Congdon]
- clarifications based on [RFC2869bis]
- a revised IEEE 802.1X state machine
- an EAP state machine, based on [EAPSTATE] and [RFC2284bis]
Due to the deep dependencies between IEEE 802.1aa and EAP WG, a liason
was established between the two groups in August 2002. This enables
members of the IETF EAP WG to obtain access to IEEE 802.1aa work-in-
progress.
IEEE 802 groups are duty bound to consider all comments received,
regardless of their origin. This allows IETF participants to comment as
part of the IEEE 802 ballot process, regardless of their voting status
within IEEE 802. Where there is active cooperation, IETF WGs may be
made aware that IEEE 802 ballots are occurring and that their comments
are welcome. Currently IEEE 802.1aa and IEEE 802.11i ballots are
announced on the EAP WG mailing list, as are IEEE 802 interim meeting
arrangements.
Similarly, during the IEEE 802.1aa ballot process, comments have been
received relating to [RFC2284bis], [EAPSTATE], and [RFC2869bis]. These
comments are tracked on the EAP WG Issues List, and are reflected in the
documents.
In April 2003 [Congdon] was approved by the IESG for publication as an
RFC, and in May 2003 [RFC2869bis] was approved for publication as an
RFC. The review process for both drafts involved bringing the documents
to IETF last call, and then reposting the IETF last call announcement on
the IEEE 802.1 mailing list. While ballot comments in IEEE 802.1aa were
also reflected in changes to both documents, it was necessary for both
documents to be approved for publication as RFCs well in advance of IEEE
802.1aa Sponsor Ballot, in order to ensure that RFC #s would be assigned
Bell, Romascanu & Aboba Informational [Page 6]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
in time, so as to avoid delaying publication of IEEE 802.1aa.
Overall, despite the complex inter-dependencies between IEEE 802.1aa and
IETF specifications, the relationship has been relatively successful.
This is largely due to the work of a group of contributors who have been
joint participants in IEEE 802.1aa and the IETF EAP WG.
3.2. IEEE 802.11i
IEEE 802.11i is chartered with security enhancements to IEEE 802.11.
Since IEEE 802.11i has chosen to utilize IEEE 802.1X, IEEE 802.11i
depends on the IEEE 802.1X revision-in-progress [IEEE8021aa]. As a
result, IEEE 802.11i and IEEE 802.1aa have in the past held joint
meetings at IEEE 802 plenaries and have established a liason arrangement
that permits members of either group (as well as EAP WG participants)
access to IEEE 802.11i work-in-progress.
Since IEEE 802.11i depends on IEEE 802.1aa, IEEE 802.11i inherits IEEE
802.1aa dependencies on IETF work, including work on EAP, EAP methods,
and AAA support for EAP. In addition, since IEEE 802.11i uses EAP for
key management whereas [IEEE8021X] does not, there is an additional
dependency on EAP Key management [EAPKey].
In February 2002, IEEE 802.11 sent a liason letter to the IESG
[IEEE802Liason1] requesting additional work on EAP, EAP methods, and EAP
key management. This letter was presented at the second EAP BOF at IETF
53, and was used as input to the EAP WG charter. In March 2003, another
liason letter was presented, providing further clarifications on
requirements for EAP method work [IEEE802Liason2]. This included a
request from IEEE 802.11i for the EAP WG to consider changing the
mandatory-to-implement EAP method within [RFC2284bis], so as to provide
a method meeting the security requirements of IEEE 802.11i.
During IETF 56, the request for changing the mandatory-to-implement
method was considered by the EAP WG. A recommendation was made by the
Internet Area Director Erik Nordmark that the IEEE 802.11i requirements
be documented in an Internet Draft and that the EAP WG consider the
security requirements for EAP methods in various situations. These
requirements were subsequently included within [RFC2284bis]. It was
recommended not to change the mandatory-to-implement method, since the
EAP WG was not chartered to do work on methods. However, work on
additional methods may be included in a future version of the EAP WG
charter.
Most recently, IEEE 802.11i has been involved in discussions relating to
fast handoff, which may potentially require RADIUS extensions [Arbaugh]
as well as changes to the EAP Key hierarchy [EAPKey]. However, the
direction of this work has not yet been determined so that no liason
Bell, Romascanu & Aboba Informational [Page 7]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
request has been formulated yet.
In April 2003 Dorothy Stanley was appointed liason from IEEE 802.11 to
the IETF, in order to help coordinate between IEEE 802.11 and the IETF
EAP and AAA WGs.
3.3. IEEE 802.11f
IEEE 802.11f is chartered with development of a recommended practice for
Inter-Access Point Communications. As part of development of an Inter-
Access Point Protocol (IAPP), it was necessary to secure communications
between the access points, as well as to support the reverse resolution
of the MAC address of the previous access point to its IP address, so as
to allow the two access points to communicate via IAPP. Since the two
access points might not be on the same link, Inverse ARP [RFC2390], was
not considered sufficient in all cases.
IEEE 802.11f elected to extend the RADIUS protocol [RFC2865] to provide
inverse address resolution as well as IPsec key management. This was
accomplished via use of vendor-specific attributes, as well as new
RADIUS commands, defined through definition of additional values for the
RADIUS Service-Type attribute. As a result, IETF review was not
required under the IANA considerations included in [RFC2865].
Subsequently, the RADIUS IANA considerations were revised so as to
require IETF review [RADIANA] in most cases.
No liason arrangement was developed between IEEE 802.11f and relevant
IETF WGs such as AAA WG or SEAMOBY WG, so as to allow IETF participants
access to the IEEE 802.11f specifications prior to publication. Once
IEEE 802.11f entered into Recirculation ballot, only comments relating
to changes in the specification could be considered. As a result,
issues raised relating to the IEEE 802.11f RADIUS extensions were
rejected.
Currently the plan is to handle issues in the IEEE 802.11f RADIUS
extensions via the IEEE 802.11 interpretation process, and subsequently,
if warranted, by a group chartered to revise IEEE 802.11f.
4. Summary and Recommendations
Based on the above history, the following changes are recommended:
a. Increased reliance on online communication. In these times of travel
restriction it is important to be able to conclude IETF/IEEE 802
cooperative projects successfully without requiring physical attendance
at both IETF and IEEE 802 meetings. This is somewhat of a challenge
because in the past having participants attend both standards bodies has
been an important contributor to success.
Bell, Romascanu & Aboba Informational [Page 8]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
b. Development of a framework agreement. Access to IEEE work-in-
progress documents has frequently arisen as an issue in cooperation
between IETF and IEEE 802. The IEEE and IETF follow very different
models with respect to document access. While IETF Internet-Drafts are
freely available, IEEE 802 keeps documents restricted to the
participants in the IEEE 802 standards process. Within IEEE 802, a
participant is requred to physically attend at least one IEEE meeting.
While in the past IETF WGs have successfully negotiated access to IEEE
work-in-progress, each instance has been handled separately and may take
significant time to set up. Going forward it would be helpful to
develop a framework agreement between the IEEE 802 and IETF so that this
process could be concluded quickly and a new negotiation would not be
required each time cooperation is required.
c. Increased review of IEEE MIBs. It would be helpful to encourage
wider review of MIBs developed by IEEE 802 WGs, via liaisons with the
IETF and by permitting access to relevant IEEE 802 draft documents to
IETF WG members. Were IEEE 802 draft documents to be made more readily
available, IETF WG chairs could encourage WG members to review the MIBs
as soon as the drafts are considered stable enough.
It is recommended that SNMP MIBs written in the IEEE follow the MIB
guidelines [GUIDELINES] and be reviewed as part of the SNMP quality
control process ('MIB Doctors').
d. Increased review of IEEE AAA applications. It would be helpful to
encourage wider review of AAA applications developed by IEEE 802 WGs.
This can be accomplished via a liaison with the IETF AAA WG, and by
permitting access to IEEE 802 work-in-progress to IETF WGs with a
demonstrated need. The newly approved RADIUS IANA Considerations
document [RADIANA] now requires such a review in most cases.
e. Preference for IETF standard AAA attributes, and a single IEEE
Vendor-Specific attribute format. Currently several standards
organizations, including IEEE, have taken to allocating their own
vendor-specific AAA attributes. As noted in [RADIANA]:
RADIUS defines a mechanism for Vendor-Specific extensions (Attribute
26) and the use of that should be encouraged instead of allocation of
global attribute types, for functions specific only to one vendor's
implementation of RADIUS, where no interoperability is deemed useful.
Since IEEE vendor-specific attributes are not specific to only one
vendor's implementation of RADIUS and interoperability is generally
deemed useful, use of vendor-specific attributes represents a last
resort. For AAA attributes of general utility, and particularly those
useful in multiple potential applications, allocation from the IETF
standard attribute space is preferred.
Bell, Romascanu & Aboba Informational [Page 9]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
Where allocation of Vendor-Specific Attributes (VSAs) is required, it is
recommended that IEEE 802 create a uniform format for all of IEEE 802,
rather than letting each IEEE 802 WG create their own format. The
format defined in IEEE 802.11f is inappropriate for this, since it only
defines a single octet Type field, allowing for only 255 attributes.
5. Security considerations
As IEEE 802 becomes increasingly involved in the specification of
standards for link-layer security, experience has shown that it is
helpful to obtain outside review of work-in-progress prior to
publication. This has proven somewhat challenging since access to IEEE
802 work-in-progress documents are often tightly controlled. For
example, special permission had to be obtained for IEEE 802.11i to be
able to circulate a version of its security standard-in-progress for
review. A liason between an IEEE 802 group and a relevant IETF WG can
assist in obtaining the necessary level of review.
In addition, experience has shown that IETF standards may not be written
to the level of clarity required by the IEEE 802 standards process. In
the case of EAP [RFC2284], the process of developing the EAP state
machine specification has proven useful in uncovering aspects requiring
clarification, and the joint review process has exposed by IEEE and IETF
documents-in-progress to wider review than might otherwise have been
possible.
Due to weaknesses in the RADIUS specification [RFC2865], it is
relatively easy for protocol extensions to introduce serious security
vulnerabilities. As a result, IETF review of RADIUS extensions is
advisable, and the RADIUS IANA Considerations [RADIANA] have been
revised so as to require such a review in most cases.
6. IANA Considerations
This document does not create any registries or allocate any protocol
parameters.
7. Informational references
[RFC1493] Decker, E., et al., "Definitions of Managed Objects for
Bridges", RFC 1493, July 1993.
[RFC2108] Graaf, K., et al., "Definitions of Managed Objects for
IEEE 802.3 Repeater Devices using SMIv2", RFC 2108,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.
Bell, Romascanu & Aboba Informational [Page 10]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2390] Bradley, T., Brown, C and A. Malis, "Inverse Address
Resolution Protocol", RFC 2390, September 1998.
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2665] Flick, J. and J. Johnson, "Definitions of Managed Objects
for the Ethernet-Like Interface Types", RFC 2665, August
1999.
[RFC2668] Smith, A., et al., "Definitions of Managed Objects for
IEEE 802.3 Medium Attachment Units (MAUs)", RFC 2668,
August 1999.
[RFC2674] Bell, E., et al., "Definitions of Managed Objects for
Bridges with Traffic Classes, Multicast Filtering and
Virtual LAN Extensions", RFC 2674, August 1999.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2867] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867,
June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
[RFC2869bis] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", Internet draft (work in
progress), draft-aboba-radius-rfc2869bis-22.txt, May
2003.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001.
Bell, Romascanu & Aboba Informational [Page 11]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
[8021XMIB] Norseth, K., "Definitions for Port Access Control (IEEE
802.1X) MIB", Internet draft (work in progress), draft-
ietf-bridge-8021x-01.txt, April 2003.
[Congdon] Congdon, P., et al., "IEEE 802.1X RADIUS Usage
Guidelines", Internet draft (work in progress), draft-
congdon-radius-8021x-29.txt, April 2003.
[IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2001,
June 2001.
[IEEE8021aa] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1aa/D6,
June 2003.
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE8021D] ISO/IEC 15802-3 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Common
specifications - Part 3: Media access Control (MAC)
Bridges, (also ANSI/IEEE Std 802.1D-1998), 1998.
[IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks:
Draft Standard for Virtual Bridged Local Area Networks,
P802.1Q, January 1998.
[IEEE8023] ISO/IEC 8802-3 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Common
specifications - Part 3: Carrier Sense Multiple Access
with Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications, (also ANSI/IEEE Std 802.3-
1996), 1996.
[IEEE8025] ISO/IEC 8802-5 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Common
specifications - Part 5: Token ring access method and
physical layer specifications, (also ANSI/IEEE Std
802.5-1998), 1998.
[802.11] Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific Requirements Part
11: Wireless LAN Medium Access Control (MAC) and
Bell, Romascanu & Aboba Informational [Page 12]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
Physical Layer (PHY) Specifications, IEEE Std.
802.11-1999, 1999.
[WISMIB] Heard, C., "Definitions of Managed Objects for the
Ethernet WAN Interface Sublayer", Internet draft (work in
progress), draft-ietf-hubmib-wis-mib-07.txt, March 2003.
[PETH] Berger, A., and D. Romascanu, "Power over Ethernet (DTE
Power via MDI) MIB", draft-ietf-hubmib-power-ethernet-
mib-04.txt, Internet draft (work in progress), December
2002.
[Arbaugh] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension
to RADIUS", draft-irtf-aaaarch-handoff-02.txt, Internet
draft (work in progress), May 2003.
[Mishra] Mishra, A. and W. Arbaugh, "An Initial Security Analysis
of the IEEE 802.1X Standard", Department of Computer
Science, University of Maryland College Park, CS-TR-4328,
February 2002.
[EAPSTATE] Vollbrecht, J., et al., "State Machines for EAP Peer and
Authenticator", draft-vollbrecht-eap-state-02.txt,
Internet draft (work in progress), April 2003.
[EAPKey] Aboba, B. and D. Simon, "EAP Keying Framework", draft-
aboba-pppext-key-problem-06.txt, Internet draft (work in
progress), March 2003.
[IEEE80211Liason1]
IEEE 802.11 liason letter to Harald Alvestrand, February
2002, http://www.ietf.org/IESG/LIASON/ieee802.11.txt
[IEEE80211Liason2]
Input To IETF EAP Working Group on Methods and Key
Strength, March 2003, http://www.ietf.org/IESG/LIASON/LS-
ieee-80211.txt
[RADIANA] Aboba, B., "IANA Considerations for RADIUS", draft-aboba-
radius-iana-07.txt, Internet draft (work in progress),
April 2003.
[GUIDELINES] Heard, C.M., "Guidelines for MIB Authors and Reviewers",
draft-ietf-ops-mib-review-guidelines-01.txt, Internet
draft (work in progress), February 2003.
Acknowledgments
Bell, Romascanu & Aboba Informational [Page 13]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
The authors would like to acknowledge Tony Jeffree for contributions to
this document.
Authors' Addresses
Les Bell
3Com Europe Limited
3Com Centre, Boundary Way
Hemel Hempstead
Herts. HP2 7YU
UK
EMail: Les_Bell@3com.com
Phone: +44 1442 438025
Dan Romascanu
Avaya Inc.
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel
EMail: dromasca@avaya.com
Phone: +972 3 645 8414
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.
Bell, Romascanu & Aboba Informational [Page 14]
INTERNET-DRAFT IEEE 802/IETF History 13 June 2003
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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-ieee802-rel-00.txt>, and expires
December 22, 2003.
Bell, Romascanu & Aboba Informational [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-22 15:08:23 |