idnits 2.17.00 (12 Aug 2021) /tmp/idnits12265/draft-aboba-ieee802-rel-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 869. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 859), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE-802.lX-2004' is mentioned on line 347, but not defined == Missing Reference: 'IEEE802Liaison1' is mentioned on line 354, but not defined == Missing Reference: 'IEEE802Liaison2' is mentioned on line 358, but not defined == Missing Reference: 'IEEE-802.11F' is mentioned on line 563, but not defined == Unused Reference: 'RFC2119' is defined on line 631, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 640, but no explicit reference was found in the text == Unused Reference: 'IEEE802' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.1Q' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.5' is defined on line 734, but no explicit reference was found in the text == Unused Reference: 'IEEE80211Liaison1' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'IEEE80211Liaison2' is defined on line 785, but no explicit reference was found in the text == Outdated reference: draft-ietf-capwap-arch has been published as RFC 4118 == Outdated reference: draft-adrangi-eap-network-discovery has been published as RFC 4284 -- Obsolete informational reference (is this intentional?): RFC 1493 (Obsoleted by RFC 4188) -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2674 (Obsoleted by RFC 4363) -- Obsolete informational reference (is this intentional?): RFC 3636 (Obsoleted by RFC 4836) == Outdated reference: draft-ietf-eap-statemachine has been published as RFC 4137 == Outdated reference: draft-iab-link-indications has been published as RFC 4907 == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 == Outdated reference: draft-ietf-ops-mib-review-guidelines has been published as RFC 4181 Summary: 8 errors (**), 0 flaws (~~), 20 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Les Bell 2 INTERNET-DRAFT 3Com Europe Limited 3 Category: Informational Dan Romascanu 4 Avaya Inc. 5 5 April 2005 Bernard Aboba 6 Microsoft Corporation 8 History of the IEEE 802/IETF Relationship 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 22, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 Since the mid 1990s, IEEE 802 and IETF have cooperated in the 40 development of SNMP MIBs and AAA applications. This document 41 describes the history of that cooperation, and the policies and 42 procedures that have developed in order to coordinate between the two 43 organizations. 45 Table of Contents 47 1. Introduction .......................................... 3 48 2. MIB Development ....................................... 3 49 2.1 Bridge MIB ...................................... 3 50 2.2 MAU and Hub MIBs ................................ 3 51 2.3 802.1p/Q MIB .................................... 4 52 2.4 802.3ad and 802.1X MIBs ......................... 5 53 2.5 802.1t, 802.1u, 802.1v and 802.1w MIBs .......... 6 54 3. AAA/EAP ............................................... 6 55 3.1 IEEE 802.1X ..................................... 7 56 3.2 IEEE 802.11i .................................... 8 57 3.3 IEEE 802.11F .................................... 9 58 4. Recent Developments ................................... 10 59 5. Recommendations ....................................... 11 60 6. Security Considerations ............................... 13 61 7. IANA Considerations ................................... 14 62 8. References ............................................ 14 63 8.1 Informative References .......................... 14 64 Acknowledgments .............................................. 18 65 Authors' Addresses ........................................... 18 66 Intellectual Property Statement .............................. 18 67 Copyright Statement .......................................... 19 68 Disclaimer of Validity ....................................... 19 69 1. Introduction 71 Since the late 1980s, participants in IEEE 802 and the IETF have 72 cooperated in the development of MIBs and AAA applications relating 73 to IEEE standards. This has included the Bridge MIB [RFC1493], the 74 multicast filtering and VLAN extension MIB [RFC2674], the Hub MIB 75 [RFC2108], the Ethernet-like Interfaces MIB [RFC3635], the MAU MIB 76 [RFC3636], the WAN Interfaces Sublayer MIB [RFC3637], the Power 77 Ethernet MIB [RFC3621], RADIUS/EAP [RFC3579], IEEE 802.1X RADIUS 78 usage guidelines [RFC3580], the revised EAP specification [RFC3748], 79 and the EAP State Machine specification [EAPSTATE]. This document 80 describes the history of the IEEE 802/IETF relationship, as well as 81 the policies and procedures that have been put in place to encourage 82 cooperation. 84 2. MIB Development 86 2.1. Bridge MIB 88 The relationship between IETF and IEEE 802 began in the late 1980s 89 with SNMP MIBs developed for the original IEEE 802.1D standard. 90 Because the IEEE specification [IEEE-802.1D] contained only a 91 functional definition of the counters and operations, the IETF's 92 Bridge MIB WG took on the role of defining the Bridge MIB [RFC1493] 93 which was published as an RFC. Fred Baker and later Keith McCloghrie 94 served as chairs of the Bridge WG. 96 The Bridge MIB combined the work of Keith McCloghrie, Eric Decker and 97 Paul Langille, with spanning tree expertise provided by Anil 98 Rijsinghani. Mick Seaman (author of 802.1D) and Floyd Backes (who 99 had written the code for Digital Equipment's spanning tree 100 implementation) were the main contacts within IEEE 802.1. Since 101 Mick, Floyd, Anil and Paul all worked for Digital Equipment 102 Corporation at the time, much of the coordination between IEEE 802.1 103 and the Bridge MIB WG took place in the hallways at Digital, rather 104 than within official channels. 106 2.2. MAU and Hub MIBs 108 In the early 1990s when IEEE 802.3 was completing the first Ethernet 109 standards, SNMP was not yet the dominant network management protocol. 110 As a result, a 'protocol independent' MIB is included in Clause 30 of 111 the IEEE 802.3 standard [IEEE-802.3], which is updated each time the 112 Ethernet standard is enhanced to support higher speeds. In parallel, 113 IEEE 802 participants interested in network management were active in 114 the formation of the IETF HUBMIB WG, which took on the task of 115 transforming IEEE 802 definitions into SNMP MIBs documented as 116 Standards Track RFCs. This included Dan Romascanu, Chair of the IETF 117 HUBMIB WG since 1996. 119 The Charter of the HUBMIB WG explicitly mentions that the IEEE 802.3 120 standard is the starting point for the Ethernet MIB, but at the same 121 time reserves the right to deviate from the IEEE model - either to 122 cover only part of the capabilities offered by the standard, or add 123 MIB objects that are not directly derived from the IEEE model (mostly 124 implemented in software). If management needs lead to requirements 125 for hardware support, the IETF HUBMIB WG is to provide this input to 126 IEEE 802.3 in a timely manner. 128 Cooperation between the IETF HUBMIB WG and IEEE 802.3 has continued 129 for more than a decade until today, mostly based on the work of a few 130 editors supported by their companies, who are taking the IEEE 131 standards and mapping them into a management data model and MIBs. 132 Work items include: 134 - The Hub MIB [RFC2108], which has gone through three iterations, 135 and is probably ending its evolution, as repeaters are less used 136 in Ethernets. 137 - The MAU MIB, which has been updated each time a new Ethernet speed 138 is developed, with [RFC3636] accommodating 10 Gbps Ethernet. 139 - The Ethernet-like Interfaces MIB was not originally a work item 140 of the HUBMIB WG, but the WG took responsibility for a revision, 141 published as [RFC3635]. 142 - The WAN Interfaces Sublayer MIB [RFC3637], and the Power Ethernet MIB 143 [RFC3621] were developed in IEEE 802.3 and the IETF HUBMIB WG. 145 In 2000, an official liaison was established between IEEE 802.3 and 146 the IETF HUBMIB WG, and Dan Romascanu was appointed IETF liaison. 147 The conditions of the liaison agreement allows editors and other 148 participants in the IETF HUBMIB WG access to work-in-progress drafts 149 in IEEE 802.3 on a personal basis, for the purpose of working on MIBs 150 before the release of the standard. However, the user name and 151 password for IEEE 802.3 document access are not for publication on 152 any IETF Web site or mail list. 154 2.3. 802.1p/Q MIB 156 In 1996 as the 802.1p and 802.1Q standards were being completed, a 157 need was perceived for development of an SNMP MIB, based on the 158 management clauses of those standards. IEEE 802 management clauses 159 are written in a manner that was independent of any protocol that may 160 be used to implement them. 162 At that time, there were a number of proprietary VLAN management MIBs 163 which were both inadequate and difficult to understand. As a result 164 there was a need for a more comprehensive, simpler model for VLAN 165 management, along with the priority and multicast filtering 166 management also defined by these standards. 168 A small group of participants from the 802.1 WG began working on the 169 problem independently, then combined their work. The original 170 authors of the Bridge MIB, on which some of the work was based, 171 reviewed the initial work. 173 By the end of 1997, the work was ready for review by a larger 174 audience. Andrew Smith worked with Keith McCloghrie, chair of the 175 Bridge MIB WG (dormant at the time) to obtain a meeting slot at the 176 March 1998 IETF Meeting. After this, review and development of the 177 MIB continued on the IETF standards track. 179 During the development of [RFC2674], there was no official inter- 180 working between the IETF Bridge-MIB and IEEE 802.1 groups. 181 Development of this MIB was successful, because the main developers 182 (Andrew Smith and Les Bell) were involved in both IEEE 802.1 as well 183 as the IETF Bridge MIB WGs. 185 2.4. 802.3ad and 802.1X MIBs 187 As part of the IEEE 802.3ad and IEEE 802.1X standards work, it was 188 decided that it would better to develop a MIB as part of the 189 standards, rather than wait until an IETF WG was formed, and develop 190 the MIBs separately, so as to avoid a significant time lag in their 191 development. 193 As Les Bell was the participant in IEEE 802.3ad and IEEE 802.1 most 194 familiar with SNMP MIB development, he put together the initial MIBs 195 based on the management framework the groups had come up with. 196 Additional assistance was then received for both MIBs from within the 197 IEEE 802.3ad and IEEE 802.1X groups. Tony Jeffree, editor of both 198 standards, acted as editor of the MIBs as well. 200 The problem with IEEE 802 developing these MIBs without IETF 201 involvement was the lack of review. IEEE 802 members are generally 202 not familiar with MIBs and very few comments were received as part of 203 the balloting process for either MIB. 205 In the case of the IEEE 802.3ad MIB, this meant that basic errors 206 were not discovered until just before publication. Unfortunately by 207 then it was too late, and the corrections submitted to the IEEE 208 802.3ad chair and document editor did not get applied to the 209 published version. 211 Subsequent to the publication of [IEEE-802.1X], the IEEE 802.1X MIB 212 was reviewed within the Bridge WG, and several syntax errors were 213 found. These have been corrected in the version of the MIB module 214 that was developed as part of [IEEE-802.1X-2004]. However, while 215 [8021XMIB] was originally published as a draft within the Bridge WG, 216 there was not sufficient interest to complete its publication as an 217 RFC. As a result, the draft has now expired. 219 2.5. 802.1t, 802.1u, 802.1v and 802.1w MIBs 221 802.1t and 802.1u were minor amendments to the 802.1D and 802.1Q 222 standards, requiring some additions to the MIB published in 223 [RFC2674]. 802.1v was a new feature extending the VLAN 224 classification schemes of 802.1Q, also requiring extensions to 225 [RFC2674]. 802.1w was a new version of Spanning Tree, requiring re- 226 writing of part of [RFC1493]. 228 When Les Bell took on the role of Chair of the IETF Bridge-MIB WG in 229 2001, these issues were raised as new work items and two volunteers 230 were found to become editors of the Internet Drafts. A work item was 231 also included to publish the IEEE 802.1X MIB as an Informational RFC. 233 This approach worked well for a while, but it then became difficult 234 for the participants, including the editors and the Chair, to sustain 235 a level of interest sufficient to overcome the difficulties 236 introduced by budget cut-backs. As a result, the drafts have now 237 expired, although there are no significant technical issues 238 outstanding. 240 3. AAA/EAP 242 Since the late 1990s, IEEE 802.1 has been involved in work relating 243 to authentication and authorization [IEEE-802.1X], which lead to 244 discovery of issues in several IETF specifications, including 245 [RFC2284] and [RFC2869]. Similarly, IETF participants have uncovered 246 issues in early versions of the RADIUS usage specifications such as 247 [RFC3580], as well as the IEEE 802.1X state machine [Mishra]. 249 In order to address these issues and ensure synchronization between 250 IEEE 802.1 and the IETF EAP and AAA WGs, a liaison arrangement was 251 utilized during the development of [IEEE-802.1X] and 252 [IEEE-802.1X-2004]. 254 IEEE 802.11 groups such as IEEE 802.11i and IEEE 802.11F have also 255 become dependent on EAP and AAA work. This relationship was more 256 challenging since IEEE 802.11 required development of EAP methods and 257 the EAP Key Management Framework, which represented substantial new 258 IETF work, as opposed to the clarifications and updates required by 259 IEEE 802.1. 261 3.1. IEEE 802.1X 263 IEEE 802.1X-2001 [IEEE-802.1X] defined the encapsulation of EAP 264 [RFC2284] over IEEE 802, as well as a state machine for the joint 265 operation of IEEE 802.1X and EAP. 267 During the development of IEEE 802.1X-2001, several problems were 268 discovered in the specification for RADIUS/EAP [RFC2869], and as a 269 result, work was begun on a revision [RFC3579]. In addition, 270 clarifications were required on how RADIUS attributes defined in 271 [RFC2865], [RFC2866], [RFC2867], [RFC2868], [RFC2869], and [RFC3162] 272 would be interpreted by IEEE 802.1X implementations. To address 273 this, a non-normative RADIUS usage appendix was added to 274 [IEEE-802.1X], and published as [RFC3580]. 276 Subsequent to the publication of [IEEE-802.1X], a formal analysis of 277 the IEEE 802.1X state machine by the University of Maryland disclosed 278 several security issues [Mishra]. Discussion within IEEE 802.1 279 pointed to lack of clarity in [RFC2284], which resulted from the 280 absence of a specification for the EAP state machine specification. 282 At that time, EAP was handled within the IETF PPPEXT WG, which was 283 largely inactive. In order to undertake work on a revised EAP 284 specification as well the specification of the EAP state machine, the 285 IETF EAP WG was formed in July 2002. Bernard Aboba, a participant in 286 IEEE 802.1 as well as PPPEXT was named co-chair. 288 Work on the EAP state machine [EAPSTATE] and revised EAP 289 specification [RFC3748] proceeded in parallel within EAP WG, with 290 issues or changes in one document requiring changes to the other 291 document, as well as revisions to [IEEE-802.1X-2004]. The revised 292 RADIUS/EAP specification [RFC3579] was also reviewed within EAP WG, 293 since at that time the RADEXT WG had not yet been formed. 295 The revision to IEEE 802.1X [IEEE-802.1X-2004] included the 296 following: 298 - a revised RADIUS usage appendix based on [RFC3580] 299 - clarifications based on [RFC3579] 300 - a revised IEEE 802.1X state machine, based on [RFC3748] and 301 [EAPSTATE] 303 Due to the deep dependencies between [IEEE-802.1X-2004], [RFC3748] 304 and [EAPSTATE], a liaison was established between IEEE 802.1X-REV and 305 the IETF EAP WG in August 2002. This enabled members of the IETF EAP 306 WG to obtain access to the IEEE 802.1X revision in progress. 308 IEEE 802 groups are duty bound to consider all comments received, 309 regardless of their origin. This allows IETF participants to comment 310 as part of the IEEE 802 ballot process, regardless of their voting 311 status within IEEE 802. Where there is active cooperation, IETF WGs 312 may be made aware that IEEE 802 ballots are occurring and that their 313 comments are welcome. IEEE 802.1X-REV and IEEE 802.11i ballots were 314 announced on the EAP WG mailing list, as are IEEE 802 interim meeting 315 arrangements. 317 Similarly, during the IEEE 802.1X-REV ballot process, comments were 318 received relating to [RFC3748], [EAPSTATE], and [RFC3579]. These 319 comments were tracked on the EAP WG Issues List, and were 320 subsequently addressed in the documents. 322 In April 2003 [RFC3580] was approved by the IESG for publication as 323 an RFC, and in May 2003 [RFC3579] was approved for publication as an 324 RFC. The review process for both drafts involved bringing the 325 documents to IETF last call, and then reposting the IETF last call 326 announcement on the IEEE 802.1 mailing list. While ballot comments 327 on IEEE 802.1X-REV were also reflected in changes to both documents, 328 it was necessary for both documents to be approved for publication as 329 RFCs well in advance of Sponsor Ballot, in order to ensure that RFC 330 numbers would be assigned in time, so as to avoid delaying 331 publication. 333 Overall, despite the complex inter-dependencies between 334 [IEEE-802.1X-2004], [RFC3748] and [EAPSTATE], the documents were 335 produced without undue delay. This was largely due to the work of 336 joint participants in IEEE 802.1 and IETF EAP WG. 338 3.2. IEEE 802.11i 340 IEEE 802.11i was chartered with security enhancements to 341 [IEEE-802.11]. Since [IEEE-802.11i] utilized IEEE 802.1X, it depended 342 on [IEEE-802.1X-2004]. As a result, IEEE 802.11i and IEEE 802.1 held 343 joint meetings at IEEE 802 plenaries and established a liaison 344 arrangement that permitted members of either group (as well as EAP WG 345 participants) access to IEEE 802.11i work-in-progress. 347 Since [IEEE-802.11i] depended on [IEEE-802.lX-2004], it inherited the 348 dependencies of [IEEE-802.1X-2004], including work on EAP, EAP 349 methods and AAA support for EAP. In addition, since IEEE 802.11i 350 utilized EAP for key management whereas [IEEE-802.1X] does not, 351 additional security requirements arose with respect to EAP methods. 353 In February 2002, IEEE 802.11 sent a liaison letter to the IESG 354 [IEEE802Liaison1] requesting additional work on EAP, EAP methods, and 355 EAP key management. This letter was presented at the second EAP BOF 356 at IETF 53, and was used as input to the EAP WG charter. In March 357 2003, another liaison letter was presented, providing further 358 clarifications on requirements for EAP method work [IEEE802Liaison2]. 359 This included a request from IEEE 802.11i for the EAP WG to consider 360 changing the mandatory-to-implement EAP method within [RFC3748], so 361 as to provide a method meeting the security requirements of IEEE 362 802.11i. 364 During IETF 56, the request for changing the mandatory-to-implement 365 method was considered by the EAP WG. A recommendation was made by 366 the Internet Area Director Erik Nordmark that the IEEE 802.11i 367 requirements be documented in an RFC and that the EAP WG consider the 368 security requirements for EAP methods in various situations. It was 369 recommended not to change the mandatory-to-implement method, since 370 the EAP WG was not chartered to do work on methods. However, it was 371 decided to produce a document describing the EAP method requirements 372 for WLAN usage. This document was subsequently published as 373 [RFC4017]. 375 Most recently, IEEE 802.11r has been involved in discussions relating 376 to fast handoff, which may potentially require AAA extensions as well 377 as changes to the EAP Key hierarchy. However, the direction of this 378 work has not yet been determined so that no liaison request has been 379 formulated yet. 381 In April 2003 Dorothy Stanley was appointed liaison from IEEE 802.11 382 to the IETF, in order to help coordinate between IEEE 802.11 and IETF 383 WGs, including AAA, BMWG, CAPWAP, and EAP. 385 3.3. IEEE 802.11F 387 IEEE 802.11F was chartered with development of a recommended practice 388 for Inter-Access Point Communications. As part of development of an 389 Inter-Access Point Protocol (IAPP), it was necessary to secure 390 communications between the access points, as well as to support the 391 reverse resolution of the MAC address of the previous access point to 392 its IP address, so as to allow the two access points to communicate 393 via IAPP. Since the two access points might not be on the same link, 394 Inverse ARP [RFC2390], was not considered sufficient in all cases. 396 IEEE 802.11F elected to extend the RADIUS protocol [RFC2865] to 397 provide inverse address resolution as well as IPsec key management. 398 This was accomplished via use of vendor-specific attributes, as well 399 as new RADIUS commands, defined through definition of additional 400 values for the RADIUS Service-Type attribute. As a result, IETF 401 review was not required under the IANA considerations included in 402 [RFC2865]. Subsequently, the RADIUS IANA considerations were revised 403 so as to require IETF review [RFC3575] in most cases. 405 No liaison arrangement was developed between IEEE 802.11F and IETF 406 WGs such as AAA WG or SEAMOBY WG, so as to allow IETF participants 407 access to the IEEE 802.11F specifications prior to publication. Once 408 IEEE 802.11F entered into Recirculation ballot, only comments 409 relating to changes in the specification could be considered. As a 410 result, issues raised relating to the IEEE 802.11F RADIUS extensions 411 were rejected. 413 Since IEEE 802.11F was a Recommended Practice, it was required that 414 the document be renewed by July 2004. Since that deadline passed 415 without ratification, IEEE 802.11F is now deprecated. This raises 416 the question of whether the RADIUS parameters allocated for use by 417 IEEE 802.11F should be reclaimed. 419 4. Recent Developments 421 In order to improve communications between the IETF and IEEE 802, 422 members of the IESG and IAB (including Bert Wijnen, James Kempf and 423 Bernard Aboba) met with the IEEE 802 Executive Committee in 424 Vancouver, Canada during the IEEE 802 Plenary in January 2004. At 425 that meeting a number of issues were discussed and the following 426 procedures were put in place: 428 [a] Access to IEEE 802 archives. Access to IEEE 802 standards more 429 than 12 months old is provided free of charge on the IEEE 802 430 website via the Get IEEE 802 Program [GetIEEE802]. Access to IEEE 431 802 work-in-progress has frequently arisen as an issue in 432 cooperation between IETF and IEEE 802. IEEE 802 and IETF follow 433 different models with respect to document access. While IETF 434 Internet-Drafts are freely available, IEEE 802 keeps documents 435 restricted to the participants in the IEEE 802 standards process. 436 Within IEEE 802, a participant is required to physically attend at 437 least one IEEE meeting. While in the past IETF WGs have 438 successfully negotiated access to IEEE 802 work-in-progress, each 439 instance has been handled separately and may take significant time 440 to set up. In order to more easily enable document access for IETF 441 WGs collaborating with IEEE 802, a liaison statement was sent to 442 the IETF in July 2004 by Paul Nikolich, Chair of IEEE 802 443 [IEEE802Liaison], describing a general process by which IETF WGs 444 could obtain access to IEEE 802 work-in-progress. IEEE 802 Chairs 445 have the authority to grant membership in their WGs, and can use 446 this authority to grant membership to an IETF WG chair upon 447 request. The IETF WG chair will be provided with access to the 448 username/password for the IEEE 802 WG archives, and is permitted to 449 share that information with members of the IETF WG. Since it is 450 possible to participate in IETF without attending meetings, or even 451 joining a mailing list, IETF WG chairs will provide the information 452 with anyone who requests it. However, since IEEE 802 work-in- 453 progress is copyrighted, incorporating material into IETF documents 454 or posting the username/password on mailing lists or websites is 455 not permitted. 457 [b] New work review. In order to enable IEEE 802 review of proposed 458 IETF WG charters, as well as to enable IETF review of proposed IEEE 459 802 PARs, it was proposed that the New Work mailing list be used. 460 The IEEE 802 Executive Committee was subscribed to the list, so 461 that they can receive proposed IETF WG Charters. Paul Congdon, 462 Vice-Chair of IEEE 802.1 took on the task of posting proposed IEEE 463 802 PARs to the New Work list as well. Where a new work 464 announcement is of particular interest, it is also (manually) 465 forwarded to the relevant IETF and IEEE 802 mailing lists. 467 [c] MIB review. With travel budgets under pressure, it has become 468 increasingly difficult for companies to fund employees to attend 469 both IEEE 802 and IETF meetings. As a result, an alternative is 470 needed to past arrangements which involved chartering a work item 471 within an IETF WG. In order to encourage wider review of MIBs 472 developed by IEEE 802 WGs, it was recommended that SNMP MIBs 473 developed in IEEE 802 follow the MIB guidelines [GUIDELINES] and be 474 reviewed as part of the IETF SNMP quality control process ('MIB 475 Doctors'). An IEEE 802 group may request assignment of a 'MIB 476 Doctor' to assist in a MIB review by contacting the IETF Operations 477 and Management Area Director. By standardizing IEEE 802 MIBs only 478 within IEEE 802 while utilizing the SNMP quality control process, 479 the IETF and IEEE 802 seek to assure quality while decreasing 480 overhead. A trial run of this process has taken place in IEEE 481 802.1 where David Harrington has agreed to review IEEE 802.1 MIBs. 483 [d] Document review. With the areas of cooperation between IEEE 802 484 and IETF increasing, the document review process has extended 485 beyond the traditional subjects of SNMP MIBs and AAA. Recently, 486 interest has arisen within the IETF BMWG WG to review the work of 487 IEEE 802.11TGT. As part of the IETF CAPWAP WG charter, IEEE 488 802.11 was asked to review the CAPWAP Taxonomy Document [CAPARCH]; 489 Dorothy Stanley organized an adhoc group for this purpose. IEEE 490 802.11 has also reviewed [IDSEL] and [IABLINK]. Within IETF, IEEE 491 802 comments are resolved using normal WG and IETF processes. 492 Similarly, IETF participants can comment as part of the IEEE 802 493 ballot process, regardless of their voting status within IEEE 802. 495 5. Recommendations 497 Based on the above history, the following changes are recommended: 499 [a] Increased reliance on online communication. In these times of 500 travel restriction it is important to be able to conclude IETF/IEEE 501 802 cooperative projects successfully without requiring physical 502 attendance at both IETF and IEEE 802 meetings. This is somewhat of 503 a challenge because in the past having participants attend both 504 standards bodies has been an important contributor to success. 506 [b] Earlier review of New Work. While the New Work list has been 507 successful in keeping IETF and IEEE 802 management appraised of new 508 WGs, the posting of proposed Charter and PARs has often come too 509 late to significantly affect the process. By the time an IETF WG 510 Charter or IEEE 802 PAR appears on New Work, a IETF BOF or IEEE 802 511 "Call for Interest" has already occurred, interest has been 512 demonstrated and considerable work has gone into development of the 513 Charter or PAR. If problems are found at that point, it is often 514 too late in the process to make major changes. It is therefore 515 recommended that IETF and IEEE 802 explore mechanisms for earlier 516 consultation on new work items. 518 [c] AAA review. In general, it is not advisable for IEEE 802 to 519 develop its own AAA applications, particularly when those 520 applications involve AAA key management [Housley56]. IEEE 802 WGs 521 requiring new AAA applications are encouraged to alert the IETF to 522 those requirements by contacting the IETF AAA or RADEXT WGs, rather 523 than proceeding on their own. Where new attributes are required 524 rather than a new application, the attributes may be included in 525 the IEEE 802 attributes draft currently under development within 526 the IETF RADEXT WG, or if the attributes are not appropriate for 527 inclusion there, an individual submission can be prepared, and 528 review can be requested from the RADEXT, AAA, EAP WGs. In addition 529 the AAA Doctors list has been created within the IETF Operations 530 and Management Area Directorate. The AAA Doctors serve a similar 531 function to the MIB Doctors. While the AAA Doctors have not yet 532 been called upon to assist with and review AAA work outside of the 533 IETF, it is conceivable that group could be of assistance to IEEE 534 802 with their AAA requirements. 536 [d] Preference for IETF standard AAA attributes, and a single IEEE 537 Vendor-Specific attribute format. Currently several standards 538 organizations, including IEEE 802, have taken to allocating their 539 own vendor-specific AAA attributes. As noted in [RFC3575]: 541 RADIUS defines a mechanism for Vendor-Specific extensions 542 (Attribute 26) and the use of that should be encouraged instead 543 of allocation of global attribute types, for functions specific 544 only to one vendor's implementation of RADIUS, where no 545 interoperability is deemed useful. 547 Since IEEE 802 vendor-specific attributes are not specific to only 548 one vendor's implementation of RADIUS and interoperability is 549 generally deemed useful, use of vendor-specific attributes 550 represents a last resort. For AAA attributes of general utility, 551 and particularly those useful in multiple potential applications, 552 allocation from the IETF standard attribute space is preferred. 553 The RADIUS IANA Considerations [RFC3575] now requires review for 554 many RADIUS parameter allocations. With respect to EAP, [RFC3748] 555 describes the procedures for IANA allocation of EAP protocol 556 parameters, including Type values. 558 Where allocation of Vendor-Specific Attributes (VSAs) is required, 559 it is recommended that IEEE 802 create a uniform format for all of 560 IEEE 802, rather than letting each IEEE 802 WG create their own 561 format. The format defined in [IEEE-802.11F] is inappropriate for 562 this, since it only defines a single octet Type field, allowing for 563 only 255 attributes. Now that [IEEE-802.11F] has been deprecated, 564 it is recommended that IEEE 802 abandon the IEEE 802.11F vendor- 565 specific attribute format in order to design a new vendor-specific 566 attribute format suitable for use by all of IEEE 802. 568 6. Security considerations 570 As IEEE 802 becomes increasingly involved in the specification of 571 standards for link-layer security, experience has shown that it is 572 helpful to obtain outside review of work-in-progress prior to 573 publication. This has proven somewhat challenging since access to 574 IEEE 802 work-in-progress documents are often tightly controlled. 575 For example, special permission had to be obtained for IEEE 802.11i 576 to be able to circulate a version of its security standard-in- 577 progress for review. A liaison between an IEEE 802 group and a 578 relevant IETF WG can assist in obtaining the necessary level of 579 review. 581 Experience has also shown that IETF standards may not be written to 582 the level of clarity required by the IEEE 802 standards process. In 583 the case of EAP [RFC2284], the process of developing the EAP state 584 machine specification [EAPSTATE] proved useful in uncovering aspects 585 requiring clarification, and the joint review process exposed IEEE 586 802 and IETF documents-in-progress to wider review than might 587 otherwise have been possible. 589 Similarly, the development of [IEEE-802.11i], [RFC3748], [KEYFRAME] 590 and [RFC4017] lead to a deeper understanding of the limitations and 591 security vulnerabilities of the EAP/AAA system. As described in 592 [Housley56], it is not advisable to develop new AAA key management 593 applications without completing a security analysis such the analysis 594 provided in [KEYFRAME]. 596 Due to weaknesses in the RADIUS specification [RFC2865], it is 597 relatively easy for protocol extensions to introduce serious security 598 vulnerabilities. As a result, IETF review of IEEE 802 RADIUS 599 extensions is advisable, and the RADIUS IANA Considerations [RFC3575] 600 have been revised so as to require such a review in most cases. 602 7. IANA Considerations 604 This document does not create any registries or allocate any protocol 605 parameters. 607 8. References 609 8.1. Informative References 611 [CAPARCH] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy 612 for Control and Provisioning of Wireless Access Points 613 (CAPWAP)", draft-ietf-capwap-arch-06.txt, Internet draft 614 (work in progress), November 2004. 616 [IDSEL] Adrangi, F., Lortz, V., Bari, F. and P. Eronen, "Identity 617 selection hints for Extensible Authentication Protocol 618 (EAP)", draft-adrangi-eap-network-discovery-11.txt, 619 Internet draft (work in progress), March 2005. 621 [GetIEEE802] IEEE Standards Association Get IEEE 802 (R) Program, 622 http://standards.ieee.org/getieee802/ 624 [RFC1493] Decker, E., et al., "Definitions of Managed Objects for 625 Bridges", RFC 1493, July 1993. 627 [RFC2108] Graaf, K., et al., "Definitions of Managed Objects for 628 IEEE 802.3 Repeater Devices using SMIv2", RFC 2108, 629 February 1997. 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", RFC 2119, March, 1997. 634 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 635 Authentication Protocol (EAP)", RFC 2284, March 1998. 637 [RFC2390] Bradley, T., Brown, C and A. Malis, "Inverse Address 638 Resolution Protocol", RFC 2390, September 1998. 640 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 641 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 642 October 1998. 644 [RFC2674] Bell, E., et al., "Definitions of Managed Objects for 645 Bridges with Traffic Classes, Multicast Filtering and 646 Virtual LAN Extensions", RFC 2674, August 1999. 648 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, 649 "Remote Authentication Dial In User Service (RADIUS)", 650 RFC 2865, June 2000. 652 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 654 [RFC2867] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting 655 Modifications for Tunnel Protocol Support", RFC 2867, 656 June 2000. 658 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 659 M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol 660 Support", RFC 2868, June 2000. 662 [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS 663 Extensions", RFC 2869, June 2000. 665 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 666 3162, August 2001. 668 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, 669 July 2003. 671 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 672 Authentication Protocol (EAP)", RFC 3579, September 2003. 674 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 675 "IEEE 802.1X RADIUS Usage Guidelines", RFC 3580, 676 September 2003. 678 [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 679 3621, December 2003. 681 [RFC3635] Flick, J., "Definitions of Managed Objects for the 682 Ethernet-like Interface Types", RFC 3635, September 2003. 684 [RFC3636] Flick, J., "Definitions of Managed Objects for IEEE 802.3 685 Medium Attachment Units (MAUs)", RFC 3636, September 686 2003. 688 [RFC3637] Heard, C. M., Ed., "Definitions of Managed Objects for 689 the Ethernet WAN Interface Sublayer", RFC 3637, September 690 2003. 692 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 693 Levkowetz, "Extensible Authentication Protocol (EAP)", 694 RFC 3748, June 2004. 696 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "Extensible 697 Authentication Protocol (EAP) Method Requirements for 698 Wireless LANs", RFC 4017, March 2005. 700 [8021XMIB] Norseth, K., "Definitions for Port Access Control (IEEE 701 802.1X) MIB", Internet draft (work in progress), draft- 702 ietf-bridge-8021x-03.txt, November 2003. 704 [IEEE-802.1X] IEEE Standards for Local and Metropolitan Area Networks: 705 Port based Network Access Control, IEEE Std 802.1X-2001, 706 June 2001. 708 [IEEE-802.1X-2004] 709 IEEE Standards for Local and Metropolitan Area Networks: 710 Port based Network Access Control, IEEE Std 802.1X-2004, 711 December 2004. 713 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 714 Overview and Architecture, ANSI/IEEE Std 802, 1990. 716 [IEEE-802.1D] ISO/IEC 15802-3 Information technology - 717 Telecommunications and information exchange between 718 systems - Local and metropolitan area networks - Common 719 specifications - Part 3: Media access Control (MAC) 720 Bridges, (also ANSI/IEEE Std 802.1D-1998), 1998. 722 [IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: 723 Draft Standard for Virtual Bridged Local Area Networks, 724 P802.1Q, January 1998. 726 [IEEE-802.3] ISO/IEC 8802-3 Information technology - 727 Telecommunications and information exchange between 728 systems - Local and metropolitan area networks - Common 729 specifications - Part 3: Carrier Sense Multiple Access 730 with Collision Detection (CSMA/CD) Access Method and 731 Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 732 1996), 1996. 734 [IEEE-802.5] ISO/IEC 8802-5 Information technology - 735 Telecommunications and information exchange between 736 systems - Local and metropolitan area networks - Common 737 specifications - Part 5: Token ring access method and 738 physical layer specifications, (also ANSI/IEEE Std 739 802.5-1998), 1998. 741 [IEEE-802.11] Information technology - Telecommunications and 742 information exchange between systems - Local and 743 metropolitan area networks - Specific Requirements Part 744 11: Wireless LAN Medium Access Control (MAC) and 745 Physical Layer (PHY) Specifications, IEEE Std. 746 802.11-2003, 2003. 748 [IEEE-802.11i] Institute of Electrical and Electronics Engineers, 749 "Supplement to Standard for Telecommunications and 750 Information Exchange Between Systems - LAN/MAN Specific 751 Requirements - Part 11: Wireless LAN Medium Access 752 Control (MAC) and Physical Layer (PHY) Specifications: 753 Specification for Enhanced Security", IEEE 802.11i, July 754 2004. 756 [Mishra] Mishra, A. and W. Arbaugh, "An Initial Security Analysis 757 of the IEEE 802.1X Standard", Department of Computer 758 Science, University of Maryland College Park, CS-TR-4328, 759 February 2002. 761 [EAPSTATE] Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, 762 "State Machines for EAP Peer and Authenticator", draft- 763 ietf-eap-statemachine-06.pdf, Internet draft (work in 764 progress), December 2004. 766 [Housley56] Housley, R., "Key Management in AAA", Presentation to the 767 AAA WG at IETF 56, 768 http://www.ietf.org/proceedings/03mar/slides/aaa- 769 5/index.html, March 2003. 771 [IABLINK] Aboba, B., "Architectural Implications of Link 772 Indications", draft-iab-link-indications-01.txt, Internet 773 draft (work in progress), January 2005. 775 [KEYFRAME] Aboba, B., Simon, D., Arkko, J., Eronen, P. and H. 776 Levkowetz, "Extensible Authentication Protocol (EAP) Key 777 Management Framework", draft-ietf-eap-keying-06.txt, 778 Internet draft (work in progress), April 2005. 780 [IEEE80211Liaison1] 781 IEEE 802.11 liaison letter to Harald Alvestrand, February 782 2002, 783 http://www.ietf.org/IESG/LIAISON/ieeeIEEE-802.11.txt 785 [IEEE80211Liaison2] 786 Input To IETF EAP Working Group on Methods and Key 787 Strength, March 2003, 788 http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt 790 [IEEE802Liaison] 791 IEEE 802 Liaison letter to Bert Wijnen and Bernard Aboba, 792 July 26, 2004, 793 http://www.ietf.org/IESG/LIAISON/file41.pdf 795 [GUIDELINES] Heard, C.M., "Guidelines for Authors and Reviewers of MIB 796 Documents", draft-ietf-ops-mib-review-guidelines-04.txt, 797 Internet draft (work in progress), February 2005. 799 Acknowledgments 801 The authors would like to acknowledge Tony Jeffree, Fred Baker, Paul 802 Langille and C. M. Heard for contributions to this document. 804 Authors' Addresses 806 Les Bell 807 3Com Europe Limited 808 3Com Centre, Boundary Way 809 Hemel Hempstead Herts. HP2 7YU 810 UK 812 EMail: Les_Bell@3com.com 813 Phone: +44 1442 438025 815 Dan Romascanu 816 Avaya Inc. 817 Atidim Technology Park, Bldg. #3 818 Tel Aviv, 61131 819 Israel 821 EMail: dromasca@avaya.com 822 Phone: +972 3 645 8414 824 Bernard Aboba 825 Microsoft Corporation 826 One Microsoft Way 827 Redmond, WA 98052 829 EMail: bernarda@microsoft.com 830 Phone: +1 425 706 6605 831 Fax: +1 425 936 7329 833 Intellectual Property Statement 835 The IETF takes no position regarding the validity or scope of any 836 intellectual property or other rights that might be claimed to 837 pertain to the implementation or use of the technology described in 838 this document or the extent to which any license under such rights 839 might or might not be available; neither does it represent that it 840 has made any effort to identify any such rights. Information on the 841 IETF's procedures with respect to rights in standards-track and 842 standards-related documentation can be found in BCP-11. Copies of 843 claims of rights made available for publication and any assurances of 844 licenses to be made available, or the result of an attempt made to 845 obtain a general license or permission for the use of such 846 proprietary rights by implementors or users of this specification can 847 be obtained from the IETF Secretariat. 849 The IETF invites any interested party to bring to its attention any 850 copyrights, patents or patent applications, or other proprietary 851 rights which may cover technology that may be required to practice 852 this standard. Please address the information to the IETF Executive 853 Director. 855 Copyright Statement 857 Copyright (C) The Internet Society (2005). This document is subject 858 to the rights, licenses and restrictions contained in BCP 78, and 859 except as set forth therein, the authors retain all their rights. 861 Disclaimer of Validity 863 This document and the information contained herein are provided on an 864 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 865 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 866 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 867 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 868 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 869 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.