Network Working Group Bernard Aboba INTERNET-DRAFT Microsoft Category: Informational 2 March 2000 Expires: October 1, 2000 A Diagnostic Model for IEEE 802.1X This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. The distribution of this memo is unlimited. 1. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 2. Abstract IEEE 802.1X enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless networks. In order to management of these devices, this specification describes a diagnostic model for IEEE 802.1x. 3. Introduction IEEE 802.1X enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless networks. In order to management of these devices, this specification describes a diagnostic model for IEEE 802.1x. Aboba, et al. Informational [Page 1] INTERNET-DRAFT A Diagnostic Model for IEEE 802.1X 2 March 2000 3.1 Terminology This document uses the following terms: Authenticator An Authenticator is an entity at one end of a point-to-point LAN segment that requires to authenticate the entity attached to the other end of that link. Authentication Server An Authentication Server is an entity that provides an Authentication Service to an Authenticator. This service determines, from the credentials provided by the Supplicant, whether the Supplicant is authorised to access the services provided by the AUthenticator. Port Access Entity (PAE) The protocol entity associated with a Port. A given PAE may support the protocol functionality associated with the AUthenticator, Supplicant or both. Supplicant A Supplicant is an entity at one end of a point-to-point LAN segment that is being authenticated by an Authenticator attached to the other end of that link. 3.2 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [3]. 4. Diagnostic model 4.1 Authentication Failures In diagnosing authentication failures, it may be useful to keep track of the EAP-type of the packet received from the supplicant prior to sending an EAP-Success or EAP-Failure packet to the supplicant. This can help track EAP method interoperability issues. For example: Method EAP-Success EAP-Failure ====== =========== =========== EAP-MD5 27 1 EAP-OTP 2 15 Aboba, et al. Informational [Page 2] INTERNET-DRAFT A Diagnostic Model for IEEE 802.1X 2 March 2000 There seems to be problem with EAP-OTP here. 4.2 Proposed 802.1X Diagnostic Model The proposed IEEE 802.1X diagnostic model makes it possible on a port by port basis to track the progress of the supplicant from initial connection to final logoff, at each stage estimating how many supplicants fail to get to the next stage and why. If past experience with dialup diagnostics is any indication, such a model will be helpful in pinpointing issues with IEEE 802.1X bridge operation. The proposed model operates by providing per-counter counters at ten stages within the IEEE 802.1X authentication process. These counters are supplemented by additional counters covering "abnormal" events. The states in the model are given below: [1] Port transitions to CONNECTING state from any state, indicating that the supplicant has connected and established basic connectivity, and that the authenticator has sent an EAP- Request/Identity. a. Transition from CONNECTING to DISCONNECTED possible due to eapLogoff [2] Transitions from CONNECTING to AUTHENTICATING state. Indicates that authenticator received an EAP-Response/Identity from the supplicant. [3] Authenticator sends an initial Access-Request packet to the authentication server. Indicates that the authenticator attempted communication with the authentication server. [4] Authenticator receives an initial Access-Challenge packet from the authentication server (either an original packet or a re-transmit). Indicates that the authentication server communicated back. [5] Authenticator sends an EAP-Request (not Identity, Notification, Failure, Success) to the supplicant. Indicates that the authenticator chose an EAP-method. [6] Supplicant responds to initial EAP-Request with something other than EAP-NAK. Indicates supplicant can speak authenticator- requested EAP method. [7] EAP-Success received from authentication server. Indicates that supplicant has successfully authenticated to authentication server. a. EAP-Failure received from authentication server. Aboba, et al. Informational [Page 3] INTERNET-DRAFT A Diagnostic Model for IEEE 802.1X 2 March 2000 [8] Transitions from AUTHENTICATING to AUTHENTICATED state. Indicates that authenticator PAE has authorized the supplicant. a. Transition from AUTHENTICATING to CONNECTING can occur due to authTimeout. b. Transition from AUTHENTICATING to HELD due to authFail. c. Transition from AUTHENTICATING to ABORTING can occur due to reAuthenticate d. Transition from AUTHENTICATING to ABORTING can occur due to eapStart. e. Transition from AUTHENTICATING to ABORTING can occur due to eapLogoff. [9] Transitions from AUTHENTICATED to DISCONNECTED state via EAP- Logoff. Indicates that the client terminated normally. a. Transition from AUTHENTICATED to DISCONNECTED due to eapStart. b. Transition from AUTHENTICATED to DISCONNECTED due to reauthenticate. 4.2.1 Diagnostic metrics: Metric (fraction) Diagnostic function ================= =================== (counter1 - counter2)/counter1 = Supplicant EAPOL issue (counter2 - counter3)/counter2 = authenticator EAP compatibility issue (counter3 - counter4)/counter3 = authentication server EAP compatibility issue (counter4 - counter5)/counter4 = EAP protocol problem with Identity (counter5 - counter6)/counter5 = EAP type negotiation failures (counter6 - counter7)/counter6 = EAP authentication failures (counter7 - counter8)/counter7 = EAP protocol problem with EAP-Success (counter8 - counter9)/counter8 = abnormal termination percentage 5. References [1] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [2] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [4] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authentication Dial In User Service (RADIUS)", Internet draft (work in progress), draft-ietf-radius-radius-v2-04.txt, February 2000. Aboba, et al. Informational [Page 4] INTERNET-DRAFT A Diagnostic Model for IEEE 802.1X 2 March 2000 [5] Rigney, C., "RADIUS Accounting", Internet draft (work in progress), draft-ietf-radius-accounting-v2-03.txt, February 2000. [6] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", Internet Draft (work in progress), draft-ietf-radius-ext-06.txt, February 2000. [7] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [8] ISO/IEC 10038 Information technology - Telecommunications and information exchange between systems - Local area networks - Media Access Control (MAC) Bridges, (also ANSI/IEEE Std 802.1D- 1993), 1993. [9] ISO/IEC Final CD 15802-3 Information technology - Tele- communications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3:Media Access Control (MAC) bridges, (current draft available as IEEE P802.1D/D15). [10] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q/D8, January 1998. [11] 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. [12] IEEE Standards for Local and Metropolitan Area Networks: Demand Priority Access Method, Physical Layer and Repeater Specification For 100 Mb/s Operation, IEEE Std 802.12-1995. [13] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Draft 802.1X/D4, February 16, 2000. [14] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [15] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [16] Aboba, B., Beadles, M., "The Network Access Identifier", RFC 2486, January 1999. Aboba, et al. Informational [Page 5] INTERNET-DRAFT A Diagnostic Model for IEEE 802.1X 2 March 2000 [17] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [18] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996. [19] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995. [20] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", Internet draft (work in progress), draft-ietf-radius-tunnel- auth-09.txt, August 1999. [21] Zorn, G., Mitton, D., Aboba, B., "RADIUS Accounting Modifications for Tunnel Protocol Support", Internet draft (work in progress), draft-ietf-radius-tunnel-acct-05.txt, October 1999. 6. Security Considerations Since this document only describes a diagnostic model there are no security considerations. 7. IANA Considerations This draft does not create any new number spaces for IANA administration. 8. Acknowledgements The authors would like to acknowledge Tim Moore of Microsoft for contributions to this document. 9. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425-936-6605 EMail: bernarda@microsoft.com 10. 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 Aboba, et al. Informational [Page 6] INTERNET-DRAFT A Diagnostic Model for IEEE 802.1X 2 March 2000 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. 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. 11. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 implmentation 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." 12. Expiration Date This memo is filed as , and expires October 1, 2000. Aboba, et al. Informational [Page 7]