doc: Add RFC documents

1 files changed, 328 insertions, 0 deletions

diff --git a/doc/rfc/rfc8940.txt b/doc/rfc/rfc8940.txt
new file mode 100644
index 0000000..d06850f
--- /dev/null
+++ b/doc/rfc/rfc8940.txt
@@ -0,0 +1,328 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. DeKok
+Request for Comments: 8940                                    FreeRADIUS
+Updates: 5247                                               October 2020
+Category: Standards Track                                               
+ISSN: 2070-1721
+
+
+ Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP
+    Subscriber Identity Module (EAP-SIM), EAP Authentication and Key
+             Agreement (EAP-AKA), and Protected EAP (PEAP)
+
+Abstract
+
+   RFC 5247 is updated to define and clarify EAP Session-Id derivation
+   for multiple Extensible Authentication Protocol (EAP) methods.  The
+   derivation of Session-Id was not given for EAP Subscriber Identity
+   Module (EAP-SIM) or EAP Authentication and Key Agreement (EAP-AKA)
+   when using the fast reconnect exchange instead of full
+   authentication.  The derivation of Session-Id for full authentication
+   is clarified for both EAP-SIM and EAP-AKA.  The derivation of
+   Session-Id for Protected EAP (PEAP) is also given.  The definition
+   for PEAP follows the definition for other TLS-based EAP methods.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8940.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Updates to RFC 5247, Appendix A
+     2.1.  EAP-AKA
+     2.2.  EAP-SIM
+     2.3.  Rationale for EAP-AKA and EAP-SIM Updates
+   3.  Session-Id for PEAP
+   4.  Security Considerations
+   5.  IANA Considerations
+   6.  References
+     6.1.  Normative References
+     6.2.  Informative References
+   Acknowledgments
+   Author's Address
+
+1.  Introduction
+
+   EAP [RFC3748] Session-Id derivation has not been defined for EAP-SIM
+   and EAP-AKA when using the fast reconnect exchange instead of full
+   authentication.  [RFC5247] defines the Session-Id for these EAP
+   methods, but that derivation is only applicable for the full
+   authentication case.  The Session-Id derivation was not defined for
+   EAP-AKA', but [AKAP] now defines it, along with other updates.  As
+   such, the definition for EAP-AKA' is not included here.
+
+   Further, the derivation of Session-Id for full authentication is
+   clarified, as the text in [RFC5247] is ambiguous.
+
+   The IEEE has defined Fast Initial Link Setup (FILS) authentication
+   [FILS], which needs the EAP Session-Id in order for the EAP Re-
+   authentication Protocol (ERP) [RFC6696] to work.  It is therefore
+   important to address the existing deficiencies in the definition of
+   EAP Session-Id.
+
+   Finally, [RFC5247] did not define Session-Id for PEAP [MS-PEAP]
+   [PEAP].  We correct these deficiencies here by updating [RFC5247]
+   with the Session-Id derivation during fast-reconnect exchange for
+   EAP-SIM and EAP-AKA; clarifying the Session-Id derivation during full
+   authentication for EAP-SIM and EAP-AKA; and defining the Session-Id
+   derivation for PEAP, which is the same for both full authentication
+   and fast reconnect.
+
+2.  Updates to RFC 5247, Appendix A
+
+   This section updates [RFC5247], Appendix A to define Session-Id for
+   fast reconnect exchange for EAP-AKA and EAP-SIM.
+
+2.1.  EAP-AKA
+
+   For EAP-AKA, [RFC5247], Appendix A says:
+
+   |  EAP-AKA
+   |     EAP-AKA is defined in [RFC4187].  The EAP-AKA Session-Id is the
+   |     concatenation of the EAP Type Code (0x17) with the contents of
+   |     the RAND field from the AT_RAND attribute, followed by the
+   |     contents of the AUTN field in the AT_AUTN attribute:
+   |  
+   |        Session-Id = 0x17 || RAND || AUTN
+
+   It should say:
+
+   |  EAP-AKA
+   |     EAP-AKA is defined in [RFC4187].  When using full
+   |     authentication, the EAP-AKA Session-Id is the concatenation of
+   |     the EAP Type Code (0x17) with the contents of the RAND field
+   |     from the AT_RAND attribute, followed by the contents of the
+   |     AUTN field in the AT_AUTN attribute:
+   |  
+   |        Session-Id = 0x17 || RAND || AUTN
+   |  
+   |     When using fast reconnect, the EAP-AKA Session-Id is the
+   |     concatenation of the EAP Type Code (0x17) with the contents of
+   |     the NONCE_S field from the AT_NONCE_S attribute, followed by
+   |     the contents of the MAC field from the AT_MAC attribute from
+   |     EAP-Request/AKA-Reauthentication:
+   |  
+   |        Session-Id = 0x17 || NONCE_S || MAC
+
+2.2.  EAP-SIM
+
+   Similarly for EAP-SIM, [RFC5247], Appendix A says:
+
+   |  EAP-SIM
+   |     EAP-SIM is defined in [RFC4186].  The EAP-SIM Session-Id is the
+   |     concatenation of the EAP Type Code (0x12) with the contents of
+   |     the RAND field from the AT_RAND attribute, followed by the
+   |     contents of the NONCE_MT field in the AT_NONCE_MT attribute:
+   |  
+   |        Session-Id = 0x12 || RAND || NONCE_MT
+
+   It should say:
+
+   |  EAP-SIM
+   |     EAP-SIM is defined in [RFC4186].  When using full
+   |     authentication, the EAP-SIM Session-Id is the concatenation of
+   |     the EAP Type Code (0x12) with the contents of the RAND field
+   |     from the AT_RAND attribute, followed by the contents of the
+   |     NONCE_MT field in the AT_NONCE_MT attribute.  RFC 4186 says
+   |     that the EAP server should obtain "n" GSM triplets where "n=2"
+   |     or "n=3".
+   |  
+   |     For "n=2", the Session-Id is therefore defined as
+   |  
+   |        Session-Id = 0x12 || RAND1 || RAND2 || NONCE_MT
+   |  
+   |     which is 49 octets in length.
+   |  
+   |     For "n=3", the Session-Id is therefore defined as
+   |  
+   |        Session-Id = 0x12 || RAND1 || RAND2 || RAND3 || NONCE_MT
+   |  
+   |     which is 65 octets in length.
+   |  
+   |     RAND1, RAND2, and RAND3 correspond to the RAND value from the
+   |     first, second, and third GSM triplet, respectively.
+   |  
+   |     When using fast reconnect, the EAP-SIM Session-Id is the
+   |     concatenation of the EAP Type Code (0x12) with the contents of
+   |     the NONCE_S field from the AT_NONCE_S attribute, followed by
+   |     the contents of the MAC field from the AT_MAC attribute from
+   |     EAP-Request/SIM/Reauthentication:
+   |  
+   |        Session-Id = 0x12 || NONCE_S || MAC
+   |  
+   |     which is 33 octets in length.
+
+2.3.  Rationale for EAP-AKA and EAP-SIM Updates
+
+   Appendix A of [RFC5247] was supposed to define exported parameters
+   for existing EAP methods.  The way Session-Id was defined for EAP-AKA
+   and EAP-SIM works only for the full authentication case, i.e., it
+   cannot be used when the optional fast reconnect case is used since
+   the used parameters (RAND, AUTN, NONCE_MT) are not used in the fast
+   reconnect case.  Based on [RFC4187], Section 5.2 and similar text in
+   [RFC4186], Section 5.2, NONCE_S corresponds to RAND and MAC in EAP-
+   Request/AKA-Reauthentication, and EAP-Request/SIM/Reauthentication
+   corresponds to AUTN.  That would seem to imply that the Session-Id
+   could be defined using NONCE_S and MAC instead of RAND and AUTN/
+   NONCE_MT.
+
+   This derivation is done via a random value created by the server,
+   along with a secret key and the peer's identity.  We believe that
+   this derivation is secure, though no formal analysis has been done.
+
+3.  Session-Id for PEAP
+
+   [RFC5247] did not define Session-Id for Microsoft's Protected EAP
+   (PEAP).  For consistency with the EAP-TLS definition given in
+   [RFC5216], Section 2.3, we define it as:
+
+      Session-Id = 0x19 || client.random || server.random
+
+   This definition is that same for both full authentication and for
+   fast reconnect.
+
+   This definition is already in widespread use in all known PEAP
+   implementations.
+
+   Note that this definition for Session-Id only applies when TLS 1.2 or
+   earlier is used.  A different derivation is defined for TLS 1.3 in
+   [TLS-EAP-TYPES].
+
+4.  Security Considerations
+
+   This specification defines EAP Session-Ids for ERP with EAP-SIM and
+   EAP-AKA.  It therefore enables ERP key hierarchy establishment using
+   fast reconnect with EAP-SIM and EAP-AKA.
+
+   The Session-Id definitions given here are unique per session,
+   unforgeable, and unguessable by an outside party, as per the
+   requirements of [RFC5247], Section 10.
+
+   The definitions used here have been widely deployed for years in all
+   major EAP implementations.  However, we acknowledge that very little
+   security analysis has been done for these definitions.  As a result,
+   any security issues would result in serious issues for the Internet
+   as a whole.
+
+   These updates do not modify the security considerations outlined in
+   [RFC5247].
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+6.  References
+
+6.1.  Normative References
+
+   [FILS]     IEEE, "IEEE Standard for 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 - Amendment
+              1: Fast Initial Link Setup",
+              DOI 10.1109/IEEESTD.2016.7792308, IEEE Std 802.11ai-2016,
+              December 2016,
+              <https://doi.org/10.1109/IEEESTD.2016.7792308>.
+
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, Ed., "Extensible Authentication Protocol
+              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
+              <https://www.rfc-editor.org/info/rfc3748>.
+
+   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
+              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
+              March 2008, <https://www.rfc-editor.org/info/rfc5216>.
+
+   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
+              Authentication Protocol (EAP) Key Management Framework",
+              RFC 5247, DOI 10.17487/RFC5247, August 2008,
+              <https://www.rfc-editor.org/info/rfc5247>.
+
+6.2.  Informative References
+
+   [AKAP]     Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
+              "Improved Extensible Authentication Protocol Method for
+              3GPP Mobile Network Authentication and Key Agreement (EAP-
+              AKA')", Work in Progress, Internet-Draft, draft-ietf-emu-
+              rfc5448bis-07, 9 March 2020, <https://tools.ietf.org/html/
+              draft-ietf-emu-rfc5448bis-07>.
+
+   [Err5011]  RFC Errata, Erratum ID 5011, RFC 5247,
+              <https://www.rfc-editor.org/errata/eid5011>.
+
+   [MS-PEAP]  Microsoft, "[MS-PEAP]: Protected Extensible Authentication
+              Protocol (PEAP)", <https://docs.microsoft.com/en-
+              us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-
+              beec-fb367325c0f9>.
+
+   [PEAP]     Palekar, A., Josefsson, S., Simon, D., and G. Zorn,
+              "Protected EAP Protocol (PEAP) Version 2", Work in
+              Progress, Internet-Draft, draft-josefsson-pppext-eap-tls-
+              eap-10, 21 October 2004, <https://tools.ietf.org/html/
+              draft-josefsson-pppext-eap-tls-eap-10>.
+
+   [RFC4186]  Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
+              Authentication Protocol Method for Global System for
+              Mobile Communications (GSM) Subscriber Identity Modules
+              (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,
+              <https://www.rfc-editor.org/info/rfc4186>.
+
+   [RFC4187]  Arkko, J. and H. Haverinen, "Extensible Authentication
+              Protocol Method for 3rd Generation Authentication and Key
+              Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
+              January 2006, <https://www.rfc-editor.org/info/rfc4187>.
+
+   [RFC6696]  Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed.,
+              "EAP Extensions for the EAP Re-authentication Protocol
+              (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012,
+              <https://www.rfc-editor.org/info/rfc6696>.
+
+   [TLS-EAP-TYPES]
+              DeKok, A., "TLS-based EAP types and TLS 1.3", Work in
+              Progress, Internet-Draft, draft-ietf-emu-tls-eap-types-01,
+              29 July 2020, <https://tools.ietf.org/html/draft-ietf-emu-
+              tls-eap-types-01>.
+
+Acknowledgments
+
+   The issue corrected in this specification was first reported by Jouni
+   Malinen in a technical erratum for RFC 5247 [Err5011].
+
+   The text in this document follows Jouni's suggestions.
+
+Author's Address
+
+   Alan DeKok
+   The FreeRADIUS Server Project
+
+   Email: aland@freeradius.org