doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc4017.txt b/doc/rfc/rfc4017.txt
new file mode 100644
index 0000000..63197b2
--- /dev/null
+++ b/doc/rfc/rfc4017.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                         D. Stanley
+Request for Comments: 4017                                 Agere Systems
+Category: Informational                                        J. Walker
+                                                       Intel Corporation
+                                                                B. Aboba
+                                                   Microsoft Corporation
+                                                              March 2005
+
+
+      Extensible Authentication Protocol (EAP) Method Requirements
+                           for Wireless LANs
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The IEEE 802.11i MAC Security Enhancements Amendment makes use of
+   IEEE 802.1X, which in turn relies on the Extensible Authentication
+   Protocol (EAP).  This document defines requirements for EAP methods
+   used in IEEE 802.11 wireless LAN deployments.  The material in this
+   document has been approved by IEEE 802.11 and is being presented as
+   an IETF RFC for informational purposes.
+
+Table of Contents
+
+   1.  Introduction .................................................  2
+       1.1.  Requirements Specification .............................  2
+       1.2.  Terminology ............................................  2
+   2.  Method Requirements ..........................................  3
+       2.1.  Credential Types .......................................  3
+       2.2.  Mandatory Requirements .................................  4
+       2.3.  Recommended Requirements ...............................  5
+       2.4.  Optional Features ......................................  5
+       2.5.  Non-compliant EAP Authentication Methods ...............  5
+   3.  Security Considerations ......................................  6
+   4.  References ...................................................  8
+   Acknowledgments ..................................................  9
+   Authors' Addresses ............................................... 10
+   Full Copyright Statement ......................................... 11
+
+
+
+
+Stanley, et al.              Informational                      [Page 1]
+
+RFC 4017       EAP Method Requirements for Wireless LANs      March 2005
+
+
+1.  Introduction
+
+   The IEEE 802.11i MAC Security Enhancements Amendment [IEEE802.11i]
+   makes use of IEEE 802.1X [IEEE802.1X], which in turn relies on the
+   Extensible Authentication Protocol (EAP), defined in [RFC3748].
+
+   Today, deployments of IEEE 802.11 wireless LANs are based on EAP and
+   use several EAP methods, including EAP-TLS [RFC2716], EAP-TTLS
+   [TTLS], PEAP [PEAP], and EAP-SIM [EAPSIM].  These methods support
+   authentication credentials that include digital certificates, user-
+   names and passwords, secure tokens, and SIM secrets.
+
+   This document defines requirements for EAP methods used in IEEE
+   802.11 wireless LAN deployments.  EAP methods claiming conformance to
+   the IEEE 802.11 EAP method requirements for wireless LANs must
+   complete IETF last call review.
+
+1.1.  Requirements Specification
+
+   In this document, several words are used to signify the requirements
+   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+   An EAP authentication method is not compliant with this specification
+   if it fails to satisfy one or more of the MUST or MUST NOT
+   requirements.  An EAP authentication method that satisfies all the
+   MUST, MUST NOT, SHOULD, and SHOULD NOT requirements is said to be
+   "unconditionally compliant"; one that satisfies all the MUST and MUST
+   NOT requirements but not all the SHOULD or SHOULD NOT requirements is
+   said to be "conditionally compliant".
+
+1.2.  Terminology
+
+   authenticator
+      The end of the link initiating EAP authentication.  The term
+      authenticator is used in [IEEE802.1X], and authenticator has the
+      same meaning in this document.
+
+   peer
+      The end of the link that responds to the authenticator.  In
+      [IEEE802.1X], this end is known as the supplicant.
+
+   Supplicant
+      The end of the link that responds to the authenticator in
+      [IEEE802.1X].
+
+
+
+
+Stanley, et al.              Informational                      [Page 2]
+
+RFC 4017       EAP Method Requirements for Wireless LANs      March 2005
+
+
+   backend authentication server
+      A backend authentication server is an entity that provides an
+      authentication service to an authenticator.  When used, this
+      server typically executes EAP methods for the authenticator.  This
+      terminology is also used in [IEEE802.1X].
+
+   EAP server
+      The entity that terminates the EAP authentication method with the
+      peer.  In the case where no backend authentication server is used,
+      the EAP server is part of the authenticator.  In the case where
+      the authenticator operates in pass-through mode, the EAP server is
+      located on the backend authentication server.
+
+   Master Session Key (MSK)
+      Keying material that is derived between the EAP peer and server
+      and exported by the EAP method.  The MSK is at least 64 octets in
+      length.  In existing implementations, an AAA server acting as an
+      EAP server transports the MSK to the authenticator.
+
+   Extended Master Session Key (EMSK)
+      Additional keying material derived between the EAP client and
+      server that is exported by the EAP method.  The EMSK is at least
+      64 octets in length.  The EMSK is not shared with the
+      authenticator or any other third party.  The EMSK is reserved for
+      future uses that are not yet defined.
+
+   4-Way Handshake
+      A pairwise Authentication and Key Management Protocol (AKMP)
+      defined in [IEEE802.11i], which confirms mutual possession of a
+      Pairwise Master Key by two parties and distributes a Group Key.
+
+2.  Method Requirements
+
+2.1.  Credential Types
+
+   The IEEE 802.11i MAC Security Enhancements Amendment requires that
+   EAP authentication methods be available.  Wireless LAN deployments
+   are expected to use different credential types, including digital
+   certificates, user-names and passwords, existing secure tokens, and
+   mobile network credentials (GSM and UMTS secrets).  Other credential
+   types that may be used include public/private key (without
+   necessarily requiring certificates) and asymmetric credential support
+   (such as password on one side, public/private key on the other).
+
+
+
+
+
+
+
+
+Stanley, et al.              Informational                      [Page 3]
+
+RFC 4017       EAP Method Requirements for Wireless LANs      March 2005
+
+
+2.2.  Mandatory Requirements
+
+   EAP authentication methods suitable for use in wireless LAN
+   authentication MUST satisfy the following criteria:
+
+   [1]  Generation of symmetric keying material.  This corresponds to
+        the "Key derivation" security claim defined in [RFC3748],
+        Section 7.2.1.
+
+   [2]  Key strength.  An EAP method suitable for use with IEEE 802.11
+        MUST be capable of generating keying material with 128-bits of
+        effective key strength, as defined in [RFC3748], Section 7.2.1.
+        As noted in [RFC3748], Section 7.10, an EAP method supporting
+        key derivation MUST export a Master Session Key (MSK) of at
+        least 64 octets, and an Extended Master Session Key (EMSK) of at
+        least 64 octets.
+
+   [3]  Mutual authentication support.  This corresponds to the "Mutual
+        authentication" security claim defined in [RFC3748], Section
+        7.2.1.
+
+   [4]  Shared state equivalence.  The shared EAP method state of the
+        EAP peer and server must be equivalent when the EAP method is
+        successfully completed on both sides.  This includes the
+        internal state of the authentication protocol but not the state
+        external to the EAP method, such as the negotiation occurring
+        prior to initiation of the EAP method.  The exact state
+        attributes that are shared may vary from method to method, but
+        typically include the method version number, the credentials
+        presented and accepted by both parties, the cryptographic keys
+        shared, and the EAP method specific attributes negotiated, such
+        as ciphersuites and limitations of usage on all protocol state.
+        Both parties must be able to distinguish this instance of the
+        protocol from all other instances of the protocol, and they must
+        share the same view regarding which state attributes are public
+        and which are private to the two parties alone.  The server must
+        obtain the authenticated peer name, and the peer must obtain the
+        authenticated server name (if the authenticated server name is
+        available).
+
+   [5]  Resistance to dictionary attacks.  This corresponds to the
+        "Dictionary attack resistance" security claim defined in
+        [RFC3748], Section 7.2.1.
+
+   [6]  Protection against man-in-the-middle attacks.  This corresponds
+        to the "Cryptographic binding", "Integrity protection", "Replay
+        protection", and "Session independence" security claims defined
+        in [RFC3748], Section 7.2.1.
+
+
+
+Stanley, et al.              Informational                      [Page 4]
+
+RFC 4017       EAP Method Requirements for Wireless LANs      March 2005
+
+
+   [7]  Protected ciphersuite negotiation.  If the method negotiates the
+        ciphersuite used to protect the EAP conversation, then it MUST
+        support the "Protected ciphersuite negotiation" security claim
+        defined in [RFC3748], Section 7.2.1.
+
+2.3.  Recommended Requirements
+
+   EAP authentication methods used for wireless LAN authentication
+   SHOULD support the following features:
+
+   [8]  Fragmentation.  This implies support for the "Fragmentation"
+        claim defined in [RFC3748], Section 7.2.1.  [RFC3748], Section
+        3.1 states:  "EAP methods can assume a minimum EAP MTU of 1020
+        octets, in the absence of other information.  EAP methods SHOULD
+        include support for fragmentation and reassembly if their
+        payloads can be larger than this minimum EAP MTU."
+
+   [9]  End-user identity hiding.  This corresponds to the
+        "Confidentiality" security claim defined in [RFC3748], Section
+        7.2.1.
+
+2.4.  Optional Features
+
+   EAP authentication methods used for wireless LAN authentication MAY
+   support the following features:
+
+   [10] Channel binding.  This corresponds to the "Channel binding"
+        security claim defined in [RFC3748], Section 7.2.1.
+
+   [11] Fast reconnect.  This corresponds to the "Fast reconnect"
+        security claim defined in [RFC3748], Section 7.2.1.
+
+2.5.  Non-compliant EAP Authentication Methods
+
+   EAP-MD5-Challenge (the current mandatory-to-implement EAP
+   authentication method), is defined in [RFC3748], Section 5.4.  As
+   defined in [RFC3748], EAP-MD5-Challenge, One-Time Password (Section
+   5.5), and Generic Token Card (Section 5.6) are non-compliant with the
+   requirements specified in this document.  As noted in [RFC3748],
+   these methods do not support any of the mandatory requirements
+   defined in Section 2.2, including key derivation and mutual
+   authentication.  In addition, these methods do not support any of the
+   recommended features defined in Section 2.3 or any of the optional
+   features defined in Section 2.4.
+
+
+
+
+
+
+
+Stanley, et al.              Informational                      [Page 5]
+
+RFC 4017       EAP Method Requirements for Wireless LANs      March 2005
+
+
+3.  Security Considerations
+
+   Within [IEEE802.11i], EAP is used for both authentication and key
+   exchange between the EAP peer and server.  Given that wireless local
+   area networks provide ready access to an attacker within range, EAP
+   usage within [IEEE802.11i] is subject to the threats outlined in
+   [RFC3748], Section 7.1.  Security considerations relating to EAP are
+   discussed in [RFC3748], Sections 7; where an authentication server is
+   utilized, the security considerations described in [RFC3579], Section
+   4, will apply.
+
+   The system security properties required to address the threats
+   described in [RFC3748], Section 7.1, are noted in [Housley56].  In
+   the material below, the requirements articulated in [Housley56] are
+   listed, along with the corresponding recommendations.
+
+   Algorithm independence
+      Requirement: "Wherever cryptographic algorithms are chosen, the
+      algorithms must be negotiable, in order to provide resilience
+      against compromise of a particular cryptographic algorithm."
+
+      This issue is addressed by mandatory requirement [7] in Section
+      2.2.  Algorithm independence is one of the EAP invariants
+      described in [KEYFRAME].
+
+   Strong, fresh session keys
+      Requirement: "Session keys must be demonstrated to be strong and
+      fresh in all circumstances, while at the same time retaining
+      algorithm independence."
+
+      Key strength is addressed by mandatory requirement [2] in Section
+      2.2.  Recommendations for ensuring the Freshness of keys derived
+      by EAP methods are discussed in [RFC3748], Section 7.10.
+
+   Replay protection
+      Requirement: "All protocol exchanges must be replay protected."
+
+      This is addressed by mandatory requirement [6] in Section 2.2.
+
+   Authentication
+      Requirements: "All parties need to be authenticated.  The
+      confidentiality of the authenticator must be maintained.  No
+      plaintext passwords are allowed."
+
+
+
+
+
+
+
+
+Stanley, et al.              Informational                      [Page 6]
+
+RFC 4017       EAP Method Requirements for Wireless LANs      March 2005
+
+
+      Mutual authentication is required as part of mandatory requirement
+      [3] in Section 2.2.  Identity protection is a recommended
+      capability, described in requirement [9] in Section 2.3.  EAP does
+      not support plaintext passwords, as noted in [RFC3748], Section
+      7.14.
+
+   Authorization
+      Requirement: "EAP peer and authenticator authorization must be
+      performed."
+
+      Authorization issues are discussed in [RFC3748], Sections 1.2 and
+      7.16.  Authentication, Authorization, and Accounting (AAA)
+      protocols such as RADIUS [RFC2865][RFC3579] may be used to enable
+      authorization of EAP peers by a central authority.  AAA
+      authorization issues are discussed in [RFC3579], Sections 2.6.3
+      and 4.3.7.
+
+   Session keys
+      Requirement: "Confidentiality of session keys must be maintained."
+
+      Issues relating to Key Derivation are described in [RFC3748],
+      Section 7.10, as well as in [KEYFRAME].
+
+   Ciphersuite negotiation
+      Requirement: "The selection of the "best" ciphersuite must be
+      securely confirmed."
+
+      This is addressed in mandatory requirement [7] in Section 2.2.
+
+   Unique naming
+      Requirement: "Session keys must be uniquely named."
+
+      Key naming issues are addressed in [KEYFRAME].
+
+   Domino effect
+      Requirement: "Compromise of a single authenticator cannot
+      compromise any other part of the system, including session keys
+      and long-term secrets."
+
+      This issue is addressed by mandatory requirement [6] in Section
+      2.2.
+
+   Key binding
+      Requirement: "The key must be bound to the appropriate context."
+
+      This issue is addressed in optional requirement [10] in Section
+      2.4.  Channel binding is also discussed in Section 7.15 of
+      [RFC3748] and Section 4.3.7 of [RFC3579].
+
+
+
+Stanley, et al.              Informational                      [Page 7]
+
+RFC 4017       EAP Method Requirements for Wireless LANs      March 2005
+
+
+4.  References
+
+4.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2865]     Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+                 "Remote Authentication Dial In User Service (RADIUS)",
+                 RFC 2865, June 2000.
+
+   [RFC3579]     Aboba, B. and P. Calhoun, "RADIUS (Remote
+                 Authentication Dial In User Service) Support For
+                 Extensible Authentication Protocol (EAP)", RFC 3579,
+                 September 2003.
+
+   [RFC3748]     Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
+                 H. Levkowetz, "Extensible Authentication Protocol
+                 (EAP)", RFC 3748, June 2004.
+
+   [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
+                 Physical Layer (PHY) Specifications, IEEE Std. 802.11-
+                 2003, 2003.
+
+   [IEEE802.1X]  IEEE Standards for Local and Metropolitan Area
+                 Networks: Port based Network Access Control, IEEE Std
+                 802.1X-2004,  December 2004.
+
+   [IEEE802.11i] Institute of Electrical and Electronics Engineers,
+                 "Supplement to Standard for Telecommunications and
+                 Information Exchange Between Systems - LAN/MAN Specific
+                 Requirements - Part 11:  Wireless LAN Medium Access
+                 Control (MAC) and Physical Layer (PHY) Specifications:
+                 Specification for Enhanced Security", IEEE 802.11i,
+                 July 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stanley, et al.              Informational                      [Page 8]
+
+RFC 4017       EAP Method Requirements for Wireless LANs      March 2005
+
+
+4.2.  Informative References
+
+   [Housley56]   Housley, R., "Key Management in AAA", Presentation to
+                 the AAA WG at IETF 56,
+                 http://www.ietf.org/proceedings/03mar/slides/aaa-
+                 5/index.html, March 2003.
+
+   [RFC2716]     Aboba, B. and D. Simon, "PPP EAP TLS Authentication
+                 Protocol", RFC 2716, October 1999.
+
+   [PEAP]        Palekar, A., et al., "Protected EAP Protocol (PEAP)",
+                 Work in Progress, July 2004.
+
+   [TTLS]        Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
+                 Authentication Protocol (EAP-TTLS)", Work in Progress,
+                 August 2004.
+
+   [EAPSIM]      Haverinen, H. and J. Salowey, "EAP SIM Authentication",
+                 Work in Progress, April 2004.
+
+   [KEYFRAME]    Aboba, B., et al., "EAP Key Management Framework", Work
+                 in Progress, July 2004.
+
+Acknowledgements
+
+   The authors would like to acknowledge contributions to this document
+   from members of the IEEE 802.11i Task Group, including Russ Housley
+   of Vigil Security, David Nelson of Enterasys Networks and Clint
+   Chaplin of Symbol Technologies, as well as members of the EAP WG
+   including Joe Salowey of Cisco Systems, Pasi Eronen of Nokia, Jari
+   Arkko of Ericsson, and Florent Bersani of France Telecom.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stanley, et al.              Informational                      [Page 9]
+
+RFC 4017       EAP Method Requirements for Wireless LANs      March 2005
+
+
+Authors' Addresses
+
+   Dorothy Stanley
+   Agere Systems
+   2000 North Naperville Rd.
+   Naperville, IL 60566
+
+   Phone: +1 630 979 1572
+   EMail: dstanley@agere.com
+
+
+   Jesse R. Walker
+   Intel Corporation
+   2111 N.E. 25th Avenue
+   Hillsboro, OR  97214
+
+   EMail: jesse.walker@intel.com
+
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 818 4011
+   Fax:   +1 425 936 7329
+   EMail: bernarda@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stanley, et al.              Informational                     [Page 10]
+
+RFC 4017       EAP Method Requirements for Wireless LANs      March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Stanley, et al.              Informational                     [Page 11]
+