doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc4962.txt b/doc/rfc/rfc4962.txt
new file mode 100644
index 0000000..a57fd47
--- /dev/null
+++ b/doc/rfc/rfc4962.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                         R. Housley
+Request for Comments: 4962                                Vigil Security
+BCP: 132                                                        B. Aboba
+Category: Best Current Practice                                Microsoft
+                                                               July 2007
+
+
+   Guidance for Authentication, Authorization, and Accounting (AAA)
+                             Key Management
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document provides guidance to designers of Authentication,
+   Authorization, and Accounting (AAA) key management protocols.  The
+   guidance is also useful to designers of systems and solutions that
+   include AAA key management protocols.  Given the complexity and
+   difficulty in designing secure, long-lasting key management
+   algorithms and protocols by experts in the field, it is almost
+   certainly inappropriate for IETF working groups without deep
+   expertise in the area to be designing their own key management
+   algorithms and protocols based on Authentication, Authorization, and
+   Accounting (AAA) protocols.  The guidelines in this document apply to
+   documents requesting publication as IETF RFCs.  Further, these
+   guidelines will be useful to other standards development
+   organizations (SDOs) that specify AAA key management.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley & Aboba          Best Current Practice                  [Page 1]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Requirements Specification .................................3
+      1.2. Mandatory to Implement .....................................3
+      1.3. Terminology ................................................3
+   2. AAA Environment Concerns ........................................5
+   3. AAA Key Management Requirements .................................7
+   4. AAA Key Management Recommendations .............................13
+   5. Security Considerations ........................................14
+   6. Normative References ...........................................15
+   7. Informative References .........................................15
+   Appendix: AAA Key Management History ..............................20
+   Acknowledgments ...................................................22
+
+1.  Introduction
+
+   This document provides architectural guidance to designers of AAA key
+   management protocols.  The guidance is also useful to designers of
+   systems and solutions that include AAA key management protocols.
+
+   AAA key management often includes a collection of protocols, one of
+   which is the AAA protocol.  Other protocols are used in conjunction
+   with the AAA protocol to provide an overall solution.  These other
+   protocols often provide authentication and security association
+   establishment.
+
+   Given the complexity and difficulty in designing secure, long-lasting
+   key management algorithms and protocols by experts in the field, it
+   is almost certainly inappropriate for IETF working groups without
+   deep expertise in the area to be designing their own key management
+   algorithms and protocols based on Authentication, Authorization and
+   Accounting (AAA) protocols.  These guidelines apply to documents
+   requesting publication as IETF RFCs.  Further, these guidelines will
+   be useful to other standards development organizations (SDOs) that
+   specify AAA key management that depends on IETF specifications for
+   protocols such as Extensible Authentication Protocol (EAP) [RFC3748],
+   Remote Authentication Dial-In User Service (RADIUS) [RFC2865], and
+   Diameter [RFC3588].
+
+   In March 2003, at the IETF 56 AAA Working Group Session, Russ Housley
+   gave a presentation on "Key Management in AAA" [H].  That
+   presentation established the vast majority of the requirements
+   contained in this document.  Over the last three years, this
+   collection of requirements have become known as the "Housley
+   Criteria".
+
+
+
+
+
+Housley & Aboba          Best Current Practice                  [Page 2]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+1.1.  Requirements Specification
+
+   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+   document, are to be interpreted as described in RFC 2119 [RFC2119].
+
+   An AAA key management proposal is not compliant with this
+   specification if it fails to satisfy one or more of the MUST or MUST
+   NOT statements.  An AAA key management proposal that satisfies all
+   the MUST, MUST NOT, SHOULD, and SHOULD NOT statements is said to be
+   "unconditionally compliant"; one that satisfies all the MUST and MUST
+   NOT statements but not all the SHOULD or SHOULD NOT requirements is
+   said to be "conditionally compliant".
+
+1.2.  Mandatory to Implement
+
+   The guidance provided in this document is mandatory to implement.
+   However, it is not mandatory to use.  That is, configuration at the
+   time of deployment may result in a deployed implementation that does
+   not conform with all of these requirements.
+
+   For example, [RFC4072] enables EAP keying material to be delivered
+   from a AAA server to an AAA client without disclosure to third
+   parties.  Thus, key confidentiality is mandatory to implement in
+   Diameter [RFC3588].  However, key confidentiality is not mandatory to
+   use.
+
+1.3.  Terminology
+
+   This section defines terms that are used in this document.
+
+      AAA
+         Authentication, Authorization, and Accounting (AAA).  AAA
+         protocols include RADIUS [RFC2865] and Diameter [RFC3588].
+
+      Authenticator
+         The party initiating EAP authentication.  The term
+         authenticator is used in [802.1X], and authenticator has the
+         same meaning in this document.
+
+      Backend authentication server
+         A backend authentication server is an entity that provides an
+         authentication service to an authenticator.  This terminology
+         is also used in [802.1X].
+
+
+
+
+
+
+
+Housley & Aboba          Best Current Practice                  [Page 3]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+      CHAP
+         Challenge Handshake Authentication Protocol; a one-way
+         challenge/response authentication protocol defined in
+         [RFC1994].
+
+      EAP
+         Extensible Authentication Protocol, defined in [RFC3748].
+
+      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.
+
+      Key Wrap
+         The encryption of one symmetric cryptographic key in another.
+         The algorithm used for the encryption is called a key wrap
+         algorithm or a key encryption algorithm.  The key used in the
+         encryption process is called a key-encryption key (KEK).
+
+      PAP
+         Password Authentication Protocol; a deprecated cleartext
+         password PPP authentication protocol, originally defined in
+         [RFC1334].
+
+      Party
+         A party is a processing entity that can be identified as a
+         single role in a protocol.
+
+      Peer
+         The end of the link that responds to the authenticator.  In
+         [802.1X], this end is known as the supplicant.
+
+      PPP
+         Point-to-Point Protocol, defined in [RFC1661], provides support
+         for multiprotocol serial datalinks.  PPP is the primary IP
+         datalink used for dial-in NAS connection service.
+
+      Secure Association Protocol
+         A protocol for managing security associations derived from EAP
+         and/or AAA exchanges.  The protocol establishes a security
+         association, which includes symmetric keys and a context for
+         the use of the keys.  An example of a Secure Association
+         Protocol is the 4-way handshake defined within [802.11i].
+
+
+
+
+
+
+Housley & Aboba          Best Current Practice                  [Page 4]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+      Session Keys
+         Keying material used to protect data exchanged after
+         authentication has successfully completed, using the negotiated
+         ciphersuite.
+
+      Network Access Server (NAS)
+         A device that provides an access service for a user to a
+         network.  The service may be a network connection, or a value
+         added service such as terminal emulation, as described in
+         [RFC2881].
+
+      4-Way Handshake
+         A Secure Association Protocol, defined in [802.11i], which
+         confirms mutual possession of a Pairwise Master Key by two
+         parties and distributes a Group Key.
+
+2.  AAA Environment Concerns
+
+   Examples of serious flaws plague the history of key management
+   protocol development, starting with the very first attempt to define
+   a key management protocol in the open literature, which was published
+   in 1978 [NS].  A flaw and a fix were published in 1981 [DS], and the
+   fix was broken in 1994 [AN].  In 1995 [L], a new flaw was found in
+   the original 1978 version, in an area not affected by the 1981/1994
+   issue.  All of these flaws were blindingly obvious once described,
+   yet no one spotted them earlier.  Note that the original protocol, if
+   it were revised to employ certificates, which of course had yet to be
+   invented, was only three messages.  Many proposed AAA key management
+   schemes are significantly more complicated.
+
+   This bit of history shows that key management protocols are subtle.
+   Experts can easily miss a flaw.  As a result, peer review by multiple
+   experts is essential, especially since many proposed AAA key
+   management schemes are significantly more complicated.  In addition,
+   formal methods can help uncover problems [M].
+
+   AAA-based key management is being incorporated into standards
+   developed by the IETF and other standards development organizations
+   (SDOs), such as IEEE 802.  However, due to ad hoc development of
+   AAA-based key management, AAA-based key distribution schemes have
+   poorly understood security properties, even when well-studied
+   cryptographic algorithms are employed.  More academic research is
+   needed to fully understand the security properties of AAA-based key
+   management in the diverse protocol environments where it is being
+   employed today.  In the absence of such research results, pragmatic
+   guidance based on sound security engineering principles is needed.
+
+
+
+
+
+Housley & Aboba          Best Current Practice                  [Page 5]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+   In addition to the need for interoperability, cryptographic algorithm
+   independent solutions are greatly preferable.  Without algorithm
+   independence, the AAA-based key management protocol must be changed
+   whenever a problem is discovered with any of the selected algorithms.
+   As AAA history shows, problems are inevitable.  Problems can surface
+   due to age or design failure.
+
+   DES [FIPS46] was a well-designed encryption algorithm, and it
+   provided protection for many years.  Yet, the 56-bit key size was
+   eventually overcome by Moore's Law.  No significant cryptographic
+   deficiencies have been discovered in DES.
+
+   The history of AAA underlines the importance of algorithm
+   independence as flaws have been found in authentication mechanisms
+   such as CHAP, MS-CHAPv1 [SM1], MS-CHAPv2 [SM2], Kerberos
+   [W][BM][DLS], and LEAP [B].  Unfortunately, RADIUS [RFC2865] mandates
+   use of the MD5 algorithm for integrity protection, which has known
+   deficiencies, and RADIUS has no provisions to negotiate substitute
+   algorithms.  Similarly, the vendor-specific key wrap mechanism
+   defined in [RFC2548] has no provisions to negotiate substitute
+   algorithms.
+
+   The principle of least privilege is an important design guideline.
+   This principle requires that a party be given no more privilege than
+   necessary to perform the task assigned to them.  Ensuring least
+   privilege requires clear identification of the tasks assigned to each
+   party, and explicit determination of the minimum set of privileges
+   required to perform those tasks.  Only those privileges necessary to
+   perform the tasks are granted.  By denying to parties unneeded
+   privileges, those denied privileges cannot be used to circumvent
+   security policy or enable attackers.  With this principle in mind,
+   AAA key management schemes need to be designed in a manner where each
+   party has only the privileges necessary to perform their role.  That
+   is, no party should have access to any keying material that is not
+   needed to perform their own role.  A party has access to a particular
+   key if it has access to all of the secret information needed to
+   derive it.
+
+   EAP is being used in new ways.  The inclusion of support for EAP
+   within Internet Key Exchange Protocol version 2 (IKEv2) and the
+   standardization of robust Wireless LAN security [802.11i] based on
+   EAP are two examples.  EAP has also been proposed within IEEE 802.16e
+   [802.16e] and by the IETF PANA Working Group.  AAA-based key
+   management is being incorporated into standards developed by the IETF
+   and other standards development organizations (SDOs), such as IEEE
+   802.  However, due to ad hoc development of AAA-based key management,
+   AAA-based key distribution schemes have poorly understood security
+   properties, even when well-studied cryptographic algorithms are
+
+
+
+Housley & Aboba          Best Current Practice                  [Page 6]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+   employed.  More academic research is needed to fully understand the
+   security properties of AAA-based key management in the diverse
+   protocol environments where it is being employed today.  In the
+   absence of research results, pragmatic guidance based on sound
+   security engineering principles is needed.
+
+   EAP selects one end-to-end authentication mechanism.  The mechanisms
+   defined in [RFC3748] only support unilateral authentication, and they
+   do not support mutual authentication or key derivation.  As a result,
+   these mechanisms do not fulfill the security requirements for many
+   deployment scenarios, including Wireless LAN authentication
+   [RFC4017].
+
+   To ensure adequate security and interoperability, EAP applications
+   need to specify mandatory-to-implement algorithms.  As described in
+   [RFC3748], EAP methods seeking publication as an IETF RFC need to
+   document their security claims.  However, some EAP methods are not
+   based on well-studied models, which makes the validity of these
+   security claims difficult to determine.
+
+   In the context of EAP, the EAP peer and server are the parties
+   involved in the EAP method conversation, and they gain access to key
+   material when the conversation completes successfully.  However, the
+   lower-layer needs keying material to provide the desired protection
+   through the use of cryptographic mechanisms.  As a result, a "pass-
+   through" mode is used to provide the keying material, and the lower-
+   layer keying material is replicated from the AAA server to the
+   authenticator.  The only parties authorized to obtain all of the
+   keying material are the EAP peer and server; the authenticator
+   obtains only the keying material necessary for its specific role.  No
+   other party can obtain direct access to any of the keying material;
+   however, other parties may receive keys that are derived from this
+   keying material for a specific purpose as long as the requirements
+   defined in the next section are met.
+
+3.  AAA Key Management Requirements
+
+   The overall goal of AAA key management is to provide cryptographic
+   keying material in situations where key derivation cannot be used by
+   the peer and authenticator.  It may not be possible because the
+   authenticator lacks computational power, because it lacks the
+   resources necessary to implement the various authentication
+   mechanisms that might be required, or because it is undesirable for
+   each authenticator to engage in a separate key management
+   conversation.
+
+
+
+
+
+
+Housley & Aboba          Best Current Practice                  [Page 7]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+   This section provides guidance to AAA protocol designers, EAP method
+   designers, and security association protocol designers.  Acceptable
+   solutions MUST meet all of these requirements.
+
+      Cryptographic algorithm independent
+
+         The AAA key management protocol MUST be cryptographic algorithm
+         independent.  However, an EAP method MAY depend on a specific
+         cryptographic algorithm.  The ability to negotiate the use of a
+         particular cryptographic algorithm provides resilience against
+         compromise of a particular cryptographic algorithm.  Algorithm
+         independence is also REQUIRED with a Secure Association
+         Protocol if one is defined.  This is usually accomplished by
+         including an algorithm identifier and parameters in the
+         protocol, and by specifying the algorithm requirements in the
+         protocol specification.  While highly desirable, the ability to
+         negotiate key derivation functions (KDFs) is not required.  For
+         interoperability, at least one suite of mandatory-to-implement
+         algorithms MUST be selected.  Note that without protection by
+         IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865]
+         does not meet this requirement, since the integrity protection
+         algorithm cannot be negotiated.
+
+         This requirement does not mean that a protocol must support
+         both public-key and symmetric-key cryptographic algorithms.  It
+         means that the protocol needs to be structured in such a way
+         that multiple public-key algorithms can be used whenever a
+         public-key algorithm is employed.  Likewise, it means that the
+         protocol needs to be structured in such a way that multiple
+         symmetric-key algorithms can be used whenever a symmetric-key
+         algorithm is employed.
+
+      Strong, fresh session keys
+
+         While preserving algorithm independence, session keys MUST be
+         strong and fresh.  Each session deserves an independent session
+         key.  Fresh keys are required even when a long replay counter
+         (that is, one that "will never wrap") is used to ensure that
+         loss of state does not cause the same counter value to be used
+         more than once with the same session key.
+
+         Some EAP methods are capable of deriving keys of varying
+         strength, and these EAP methods MUST permit the generation of
+         keys meeting a minimum equivalent key strength.  BCP 86
+         [RFC3766] offers advice on appropriate key sizes.  The National
+         Institute for Standards and Technology (NIST) also offers
+         advice on appropriate key sizes in [SP800-57].
+
+
+
+
+Housley & Aboba          Best Current Practice                  [Page 8]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+         A fresh cryptographic key is one that is generated specifically
+         for the intended use.  In this situation, a secure association
+         protocol is used to establish session keys.  The AAA protocol
+         and EAP method MUST ensure that the keying material supplied as
+         an input to session key derivation is fresh, and the secure
+         association protocol MUST generate a separate session key for
+         each session, even if the keying material provided by EAP is
+         cached.  A cached key persists after the authentication
+         exchange has completed.  For the AAA/EAP server, key caching
+         can happen when state is kept on the server.  For the NAS or
+         client, key caching can happen when the NAS or client does not
+         destroy keying material immediately following the derivation of
+         session keys.
+
+         Session keys MUST NOT be dependent on one another.  Multiple
+         session keys may be derived from a higher-level shared secret
+         as long as a one-time value, usually called a nonce, is used to
+         ensure that each session key is fresh.  The mechanism used to
+         generate session keys MUST ensure that the disclosure of one
+         session key does not aid the attacker in discovering any other
+         session keys.
+
+      Limit key scope
+
+         Following the principle of least privilege, parties MUST NOT
+         have access to keying material that is not needed to perform
+         their role.  A party has access to a particular key if it has
+         access to all of the secret information needed to derive it.
+
+         Any protocol that is used to establish session keys MUST
+         specify the scope for session keys, clearly identifying the
+         parties to whom the session key is available.
+
+      Replay detection mechanism
+
+         The AAA key management protocol exchanges MUST be replay
+         protected, including AAA, EAP, and Secure Association Protocol
+         exchanges.  Replay protection allows a protocol message
+         recipient to discard any message that was recorded during a
+         previous legitimate dialogue and presented as though it
+         belonged to the current dialogue.
+
+      Authenticate all parties
+
+         Each party in the AAA key management protocol MUST be
+         authenticated to the other parties with whom they communicate.
+         Authentication mechanisms MUST maintain the confidentiality of
+         any secret values used in the authentication process.
+
+
+
+Housley & Aboba          Best Current Practice                  [Page 9]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+         When a secure association protocol is used to establish session
+         keys, the parties involved in the secure association protocol
+         MUST identify themselves using identities that are meaningful
+         in the lower-layer protocol environment that will employ the
+         session keys.  In this situation, the authenticator and peer
+         may be known by different identifiers in the AAA protocol
+         environment and the lower-layer protocol environment, making
+         authorization decisions difficult without a clear key scope.
+         If the lower-layer identifier of the peer will be used to make
+         authorization decisions, then the pair of identifiers
+         associated with the peer MUST be authorized by the
+         authenticator and/or the AAA server.
+
+         AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588],
+         provide a mechanism for the identification of AAA clients;
+         since the EAP authenticator and AAA client are always co-
+         resident, this mechanism is applicable to the identification of
+         EAP authenticators.
+
+         When multiple base stations and a "controller" (such as a WLAN
+         switch) comprise a single EAP authenticator, the "base station
+         identity" is not relevant; the EAP method conversation takes
+         place between the EAP peer and the EAP server.  Also, many base
+         stations can share the same authenticator identity.  The
+         authenticator identity is important in the AAA protocol
+         exchange and the secure association protocol conversation.
+
+         Authentication mechanisms MUST NOT employ plaintext passwords.
+         Passwords may be used provided that they are not sent to
+         another party without confidentiality protection.
+
+      Peer and authenticator authorization
+
+         Peer and authenticator authorization MUST be performed.  These
+         entities MUST demonstrate possession of the appropriate keying
+         material, without disclosing it.  Authorization is REQUIRED
+         whenever a peer associates with a new authenticator.  The
+         authorization checking prevents an elevation of privilege
+         attack, and it ensures that an unauthorized authenticator is
+         detected.
+
+         Authorizations SHOULD be synchronized between the peer, NAS,
+         and backend authentication server.  Once the AAA key management
+         protocol exchanges are complete, all of these parties should
+         hold a common view of the authorizations associated with the
+         other parties.
+
+
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 10]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+         In addition to authenticating all parties, key management
+         protocols need to demonstrate that the parties are authorized
+         to possess keying material.  Note that proof of possession of
+         keying material does not necessarily prove authorization to
+         hold that keying material.  For example, within an IEEE
+         802.11i, the 4-way handshake demonstrates that both the peer
+         and authenticator possess the same EAP keying material.
+         However, by itself, this possession proof does not demonstrate
+         that the authenticator was authorized by the backend
+         authentication server to possess that keying material.  As
+         noted in RFC 3579 in Section 4.3.7, where AAA proxies are
+         present, it is possible for one authenticator to impersonate
+         another, unless each link in the AAA chain implements checks
+         against impersonation.  Even with these checks in place, an
+         authenticator may still claim different identities to the peer
+         and the backend authentication server.  As described in RFC
+         3748 in Section 7.15, channel binding is required to enable the
+         peer to verify that the authenticator claim of identity is both
+         consistent and correct.
+
+      Keying material confidentiality and integrity
+
+         While preserving algorithm independence, confidentiality and
+         integrity of all keying material MUST be maintained.
+
+      Confirm ciphersuite selection
+
+         The selection of the "best" ciphersuite SHOULD be securely
+         confirmed.  The mechanism SHOULD detect attempted roll-back
+         attacks.
+
+      Uniquely named keys
+
+         AAA key management proposals require a robust key naming
+         scheme, particularly where key caching is supported.  The key
+         name provides a way to refer to a key in a protocol so that it
+         is clear to all parties which key is being referenced.  Objects
+         that cannot be named cannot be managed.  All keys MUST be
+         uniquely named, and the key name MUST NOT directly or
+         indirectly disclose the keying material.  If the key name is
+         not based on the keying material, then one can be sure that it
+         cannot be used to assist in a search for the key value.
+
+      Prevent the Domino effect
+
+         Compromise of a single peer MUST NOT compromise keying material
+         held by any other peer within the system, including session
+         keys and long-term keys.  Likewise, compromise of a single
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 11]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+         authenticator MUST NOT compromise keying material held by any
+         other authenticator within the system.  In the context of a key
+         hierarchy, this means that the compromise of one node in the
+         key hierarchy must not disclose the information necessary to
+         compromise other branches in the key hierarchy.  Obviously, the
+         compromise of the root of the key hierarchy will compromise all
+         of the keys; however, a compromise in one branch MUST NOT
+         result in the compromise of other branches.  There are many
+         implications of this requirement; however, two implications
+         deserve highlighting.  First, the scope of the keying material
+         must be defined and understood by all parties that communicate
+         with a party that holds that keying material.  Second, a party
+         that holds keying material in a key hierarchy must not share
+         that keying material with parties that are associated with
+         other branches in the key hierarchy.
+
+         Group keys are an obvious exception.  Since all members of the
+         group have a copy of the same key, compromise of any one of the
+         group members will result in the disclosure of the group key.
+
+      Bind key to its context
+
+         Keying material MUST be bound to the appropriate context.  The
+         context includes the following.
+
+            o  The manner in which the keying material is expected to be
+               used.
+
+            o  The other parties that are expected to have access to the
+               keying material.
+
+            o  The expected lifetime of the keying material.  Lifetime
+               of a child key SHOULD NOT be greater than the lifetime of
+               its parent in the key hierarchy.
+
+         Any party with legitimate access to keying material can
+         determine its context.  In addition, the protocol MUST ensure
+         that all parties with legitimate access to keying material have
+         the same context for the keying material.  This requires that
+         the parties are properly identified and authenticated, so that
+         all of the parties that have access to the keying material can
+         be determined.
+
+
+
+
+
+
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 12]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+         The context will include the peer and NAS identities in more
+         than one form.  One (or more) name form is needed to identify
+         these parties in the authentication exchange and the AAA
+         protocol.  Another name form may be needed to identify these
+         parties within the lower layer that will employ the session
+         key.
+
+4.  AAA Key Management Recommendations
+
+   Acceptable solutions SHOULD meet all of these requirements.
+
+      Confidentiality of identity
+
+         In many environments, it is important to provide
+         confidentiality protection for identities.  However, this is
+         not important in other environments.  For this reason, EAP
+         methods are encouraged to provide a mechanism for identity
+         protection of EAP peers, but such protection is not a
+         requirement.
+
+      Authorization restriction
+
+         If peer authorization is restricted, then the peer SHOULD be
+         made aware of the restriction.  Otherwise, the peer may
+         inadvertently attempt to circumvent the restriction.  For
+         example, authorization restrictions in an IEEE 802.11
+         environment include:
+
+            o  Key lifetimes, where the keying material can only be used
+               for a certain period of time;
+
+            o  SSID restrictions, where the keying material can only be
+               used with a specific IEEE 802.11 SSID;
+
+            o  Called-Station-ID restrictions, where the keying material
+               can only be used with a single IEEE 802.11 BSSID; and
+
+            o  Calling-Station-ID restrictions, where the keying
+               material can only be used with a single peer IEEE 802 MAC
+               address.
+
+
+
+
+
+
+
+
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 13]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+5.  Security Considerations
+
+   This document provides architectural guidance to designers of AAA key
+   management protocols.  The guidance is also useful to designers of
+   systems and solutions that include AAA key management protocols.
+
+   In some deployment scenarios, more than one party in the AAA key
+   management protocol can reside on the same host.  For example, the
+   EAP authenticator and AAA client are expected to reside on the same
+   entity.  Colocation enables a single unique authenticator identity to
+   be sent by the authenticator to the AAA server as well as by the
+   authenticator to the EAP peer.  Use of the same identity in both
+   conversations enables the peer and AAA server to confirm that the
+   authenticator is consistent in its identification, avoiding potential
+   impersonation attacks.  If the authenticator and AAA client are not
+   colocated, then the authenticator and AAA client identities will
+   differ, and the key scope will not be synchronized between the EAP
+   peer, authenticator, and server.  Lack of key scope synchronization
+   enables a number of security vulnerabilities, including
+   impersonation.  For this reason, a design needs to include mechanisms
+   to ensure that the key scope and key naming are unambiguous.
+
+   The AAA server is a trusted entity.  When keying material is present
+   at all, it establishes keying material with the peer and distributes
+   keying material to the authenticator using the AAA protocol.  It is
+   trusted to only distribute keying material to the authenticator that
+   was established with the peer, and it is trusted to provide that
+   keying material to no other parties.  In many systems, keying
+   material established by the EAP peer and EAP server are combined with
+   publicly available data to derive other keys.  The AAA server is
+   trusted to refrain from deriving these same keys even though it has
+   access to the secret values that are needed to do so.
+
+   The authenticator is also a trusted party.  The authenticator is
+   trusted not to distribute keying material provided by the AAA server
+   to any other parties.  If the authenticator uses a key derivation
+   function to derive additional keying material, the authenticator is
+   trusted to distribute the derived keying material only to the
+   appropriate party that is known to the peer, and no other party.
+   When this approach is used, care must be taken to ensure that the
+   resulting key management system meets all of the principles in this
+   document, confirming that keys used to protect data are to be known
+   only by the peer and authenticator.
+
+   EAP is used to authenticate the peer to the AAA/EAP server.
+   Following successful authentication, the AAA/EAP server authorizes
+   the peer.  In many situations, this is accomplished by sending keying
+   material to the authenticator and the peer in separate protocol
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 14]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+   messages.  The authenticator is not directly authenticated to the
+   peer.  Rather, the peer determines that the authenticator has been
+   authorized by the AAA/EAP server by confirming that the authenticator
+   has the same AAA/EAP server-provided keying material.  In some
+   systems, explicit authenticator and peer mutual authentication is
+   possible.  This is desirable since it greatly improves
+   accountability.
+
+   When MIB modules are developed for AAA protocols or EAP methods,
+   these MIB modules might include managed objects for keying material.
+   The existence of managed objects associated with keying material
+   offers an additional avenue for key compromise if these objects
+   include the keying material itself.  Therefore, these MIB modules
+   MUST NOT include objects for private keys or symmetric keys.
+   However, these MIB modules MAY include management objects that expose
+   names and context associated with keys, and they MAY provide a means
+   to delete keys.
+
+6.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+7.  Informative References
+
+   [802.1X]   IEEE Standards for Local and Metropolitan Area Networks:
+              Port based Network Access Control, IEEE Std 802.1X-2004,
+              December 2004.
+
+   [802.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.
+
+   [802.16e]  Institute of Electrical and Electronics Engineers,
+              "Supplement to Standard for Telecommunications and
+              Information Exchange Between Systems -- LAN/MAN Specific
+              Requirements - Part 16: Air Interface for Fixed and Mobile
+              Broadband Wireless Access Systems -- Amendment for
+              Physical and Medium Access Control Layers for Combined
+              Fixed and Mobile Operation in Licensed Bands", Draft, IEEE
+              802.16e/D8, May 2005.
+
+
+
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 15]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+   [AN]       M. Abadi and R. Needham, "Prudent Engineering Practice for
+              Cryptographic Protocols", Proc. IEEE Computer Society
+              Symposium on Research in Security and Privacy, May 1994.
+
+   [B]        Brewin, B., "LEAP attack tool author says he wants to
+              alert users to risks", Computerworld, October 17, 2003.
+
+   [BM]       Bellovin, S. and M. Merrit, "Limitations of the Kerberos
+              authentication system", Proceedings of the 1991 Winter
+              USENIX Conference, pp. 253-267, 1991.
+
+   [DDNN39.2] DCA DDN Program Management Office, "MILNET TAC Access
+              Control", Defense Data Network Newsletter, DDN News 39,
+              Special Issue, 26 Apr 1985, <http://www.isi.edu/
+              in-notes/museum/ddn-news/ddn-news.n39.2>.
+
+   [DLS]      Dole, B., Lodin, S. and E. Spafford, "Misplaced trust:
+              Kerberos 4 session keys", Proceedings of the Internet
+              Society Network and Distributed System Security Symposium,
+              pp. 60-70, March 1997.
+
+   [DS]       D. Denning and G. Sacco.  "Timestamps in key distributed
+              protocols", Communication of the ACM, 24(8):533--535,
+              1981.
+
+   [FIPS46]   Federal Information Processing Standards Publication (FIPS
+              PUB) 46, Data Encryption Standard, 1977 January 15.
+
+   [H]        Housley, R., "Key Management in AAA", Presentation to the
+              AAA WG at IETF 56, March 2003, <http://www.ietf.org/
+              proceedings/03mar/slides/aaa-5/index.html>.
+
+   [L]        G. Lowe.  "An attack on the Needham-Schroeder public key
+              authentication protocol", Information Processing Letters,
+              56(3):131--136, November 1995.
+
+   [M]        Meadows, C., "Analysis of the Internet Key Exchange
+              Protocol using the NRL Protocol Analyser", Proceedings of
+              the 1999 IEEE Symposium on Security & Privacy, Oakland,
+              CA, USA, IEEE Computer Society, May 1999,
+              <http://chacs.nrl.navy.mil/publications/CHACS/1999/
+              1999meadows-IEEE99.pdf>.
+
+   [NS]       R. Needham and M. Schroeder. "Using encryption for
+              authentication in large networks of computers",
+              Communications of the ACM, 21(12), December 1978.
+
+
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 16]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+   [RFC0927]  Anderson, B.A., "TACACS user identification Telnet
+              option", RFC 927, December 1984.
+
+   [RFC1334]  Lloyd, B. and B. Simpson, "PPP Authentication Protocols",
+              RFC 1334, October 1992, Obsoleted by RFC 1994.
+
+   [RFC1492]  Finseth, C., "An Access Control Protocol, Sometimes Called
+              TACACS", RFC 1492, July 1993.
+
+   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
+              RFC 1661, July 1994.
+
+   [RFC1968]  Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968,
+              June 1996.
+
+   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication
+              Protocol (CHAP)", RFC 1994, August 1996.
+
+   [RFC2284]  Blunk, L. and J. Vollbrecht, "PPP Extensible
+              Authentication Protocol (EAP)", RFC 2284, March 1998.
+
+   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
+              (IKE)", RFC 2409, November 1998.
+
+   [RFC2419]  Sklower, K. and G. Meyer, "The PPP DES Encryption
+              Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
+
+   [RFC2420]  Hummert, K., "The PPP Triple-DES Encryption Protocol
+              (3DESE)", RFC 2420, September 1998.
+
+   [RFC2433]  Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC
+              2433, October 1998.
+
+   [RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
+              RFC 2548, March 1999.
+
+   [RFC2637]  Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
+              W., and G.  Zorn, "Point-to-Point Tunneling Protocol
+              (PPTP)", RFC 2637, July 1999.
+
+   [RFC2716]  Aboba, B. and D. Simon, "PPP EAP TLS Authentication
+              Protocol", RFC 2716, October 1999.
+
+   [RFC2759]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC
+              2759, January 2000.
+
+
+
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 17]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+              "Remote Authentication Dial In User Service (RADIUS)", RFC
+              2865, June 2000.
+
+   [RFC2881]  Mitton, D. and M. Beadles, "Network Access Server
+              Requirements Next Generation (NASREQNG) NAS Model", RFC
+              2881, July 2000.
+
+   [RFC3078]  Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
+              (MPPE) Protocol", RFC 3078, March 2001.
+
+   [RFC3079]  Zorn, G., "Deriving Keys for use with Microsoft Point-to-
+              Point Encryption (MPPE)", RFC 3079, March 2001.
+
+   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
+              Dial In User Service) Support For Extensible
+              Authentication Protocol (EAP)", RFC 3579, September 2003.
+
+   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
+              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
+
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
+              3748, June 2004.
+
+   [RFC3766]  Orman, H. and P. Hoffman, "Determining Strength for Public
+              Keys Used For Exchanging Symmetric Keys", BCP 86, RFC
+              3766, April 2004.
+
+   [RFC4017]  Stanley, D., Walker, J., and B. Aboba, "Extensible
+              Authentication Protocol (EAP) Method Requirements for
+              Wireless LANs", RFC 4017, March 2005.
+
+   [RFC4072]  Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
+              Extensible Authentication Protocol (EAP) Application", RFC
+              4072, August 2005.
+
+   [RFC4306]  Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
+              Protocol", RFC 4306, December 2005.
+
+   [SM1]      Schneier, B. and Mudge, "Cryptanalysis of Microsoft's
+              Point-to-Point Tunneling Protocol", Proceedings of the 5th
+              ACM Conference on Communications and Computer Security,
+              ACM Press, November 1998.
+
+   [SM2]      Schneier, B. and Mudge, "Cryptanalysis of Microsoft's PPTP
+              Authentication Extensions (MS-CHAPv2)", CQRE 99,
+              Springer-Verlag, 1999, pp. 192-203.
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 18]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+   [SP800-57] National Institute of Standards and Technology,
+              "Recommendation for Key Management", Special Publication
+              800-57, May 2006.
+
+   [W]        Wu, T., "A Real-World Analysis of Kerberos Password
+              Security", Proceedings of the 1999 ISOC Network and
+              Distributed System Security Symposium,
+              <http://www.isoc.org/isoc/conferences/ndss/99/
+              proceedings/papers/wu.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 19]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+Appendix: AAA Key Management History
+
+   Protocols for Authentication, Authorization, and Accounting (AAA)
+   were originally developed to support deployments of Network Access
+   Servers (NASes).  In the ARPAnet, the Terminal Access Controller
+   (TAC) provided a means for "dumb terminals" to access the network,
+   and the TACACS [RFC0927][RFC1492] AAA protocol was designed by BBN
+   under contract to the Defense Data Network Program Management Office
+   (DDN PMO) for this environment.  [RFC1492] documents a later version
+   of TACACS, not the original version that was widely deployed in
+   ARPAnet and MILNET [DDNN39.2].
+
+   Later, additional AAA protocols were developed to support deployments
+   of NASes providing access to the Internet via PPP [RFC1661].  In
+   deployments supporting more than a modest number of users, it became
+   impractical for each NAS to contain its own list of users and
+   associated credentials.  As a result, additional AAA protocols were
+   developed, including RADIUS [RFC2865] and Diameter [RFC3588].  These
+   protocols enabled a central AAA server to authenticate users
+   requesting network access, as well as providing authorization and
+   accounting.
+
+   While PPP [RFC1661] originally supported only PAP [RFC1334] and CHAP
+   [RFC1661] authentication, the limitations of these authentication
+   mechanisms became apparent.  For example, both PAP and CHAP are
+   unilateral authentication schemes supporting only authentication of
+   the PPP peer to the NAS.  Since PAP is a cleartext password scheme,
+   it is vulnerable to snooping by an attacker with access to the
+   conversation between the PPP peer and NAS.  In addition, the use of
+   PAP creates vulnerabilities within RADIUS as described in Section 4.3
+   of [RFC3579].  As a result, use of PAP is deprecated.  While CHAP, a
+   challenge-response scheme based on MD5, offers better security than
+   cleartext passwords, it does not provide for mutual authentication,
+   and CHAP is vulnerable to dictionary attack.
+
+   With the addition of the Encryption Control Protocol (ECP) to PPP
+   [RFC1968] as well as the definition of PPP ciphersuites in [RFC2419],
+   [RFC2420], and [RFC3078], the need arose to provide keying material
+   for use with link layer ciphersuites.  As with user authentication,
+   provisioning of static keys on each NAS did not scale well.
+
+   Additional vendor-specific PPP authentication protocols such as
+   MS-CHAP [RFC2433] and MS-CHAPv2 [RFC2759] were developed to provide
+   mutual authentication as well as key derivation [RFC3079] for use
+   with negotiated ciphersuites, and they were subsequently adapted for
+   use with PPP-based VPNs [RFC2637].  As with PAP and CHAP, flaws were
+   subsequently found in these new mechanisms [SM1][SM2].
+
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 20]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+   Even though PPP provided for negotiation of authentication
+   algorithms, addressing the vulnerabilities found in authentication
+   mechanisms still proved painful, since new code needed to be deployed
+   on PPP peers as well as on the AAA server.  In order to enable more
+   rapid deployment of new authentication mechanisms, as well as fixes
+   for vulnerabilities found in existing methods, the Extensible
+   Authentication Protocol (EAP) [RFC3748] was developed, along with
+   support for centralized authentication via RADIUS/EAP [RFC3579].
+
+   By enabling "pass through" authentication on the NAS, EAP enabled
+   deployment of new authentication methods or updates to existing
+   methods by revising code only on the EAP peer and AAA server.  The
+   initial authentication mechanisms defined in [RFC2284] (MD5-
+   Challenge, One-Time Password (OTP), and Generic Token Card (GTC))
+   only supported unilateral authentication, and these mechanisms do not
+   support key derivation.  Subsequent authentication methods such as
+   EAP-TLS [RFC2716] supported mutual authentication and key derivation.
+
+   In order to support the provisioning of dynamic keying material for
+   link layer ciphersuites in an environment supporting centralized
+   authentication, a mechanism was needed for the transport of keying
+   material between the AAA server and NAS.  Vendor-specific RADIUS
+   attributes were developed for this purpose [RFC2548].
+   Vulnerabilities were subsequently found in the key wrap technique, as
+   described in Section 4.3 of [RFC3579].
+
+   In theory, public key authentication mechanisms such as EAP-TLS are
+   capable of supporting mutual authentication and key derivation
+   between the EAP peer and NAS without requiring AAA key distribution.
+   However, in practice, such pure two-party schemes are rarely
+   deployed.  Operation of a centralized AAA server significantly
+   reduces the effort required to deploy certificates to NASes, and even
+   though an AAA server may not be required for key derivation and
+   possibly authentication, its participation is required for service
+   authorization and accounting.
+
+   "Pass-through" authentication and AAA key distribution has retained
+   popularity even in the face of rapid improvements in processor and
+   memory capabilities.  In addition to producing NAS devices of
+   increased capability for enterprise and carrier customers,
+   implementers have also produced low-cost/high-volume NAS devices such
+   as 802.11 Access Points, causing the resources available on an
+   average NAS to increase more slowly than Moore's law.  Despite
+   widespread support for certificate handling and sophisticated key
+   derivation mechanisms such as IKEv1 [RFC2409] within host operating
+   systems, these security capabilities are rarely deployed on low-end
+   NASes and clients.
+
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 21]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+   Even on more capable NASes, such as VPN servers, centralized
+   authentication and AAA key management has proven popular.  For
+   example, one of the major limitations of IKEv1 [RFC2409] was the lack
+   of integration with EAP and AAA, requiring proprietary extensions to
+   enable use of IPsec VPNs by organizations deploying password or
+   authentication tokens.  These limitations were addressed in IKEv2
+   [RFC4306], which while handling key derivation solely between the VPN
+   client and server, supports EAP methods for user authentication.  In
+   order to enable cryptographic binding of EAP user authentication to
+   keys derived within the IKEv2 exchange, the transport of EAP-derived
+   keys within AAA is required where the selected EAP method supports
+   key derivation.
+
+Acknowledgments
+
+   Many thanks to James Kempf, Sam Hartman, and Joe Salowey for their
+   quality review and encouragement.
+
+   Thanks to the IETF AAA Working Group and the IETF EAP Working Group
+   for their review and comment.  The document is greatly improved by
+   their contribution.
+
+Authors' Addresses
+
+   Russell Housley
+   Vigil Security, LLC
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   USA
+   EMail: housley@vigilsec.com
+   Phone: +1 703-435-1775
+   Fax:   +1 703-435-1274
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+   USA
+   EMail: bernarda@microsoft.com
+   Phone: +1 425-706-6605
+   Fax:   +1 425-936-7329
+
+
+
+
+
+
+
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 22]
+
+RFC 4962            Guidance for AAA Key Management            July 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+Housley & Aboba          Best Current Practice                 [Page 23]
+