Internet Draft Jesse Walker Expiration: December 2002 Intel Corporation File: draft-walker-aaa-key-distribution-00.txt Russ Housley RSA Labs Nancy Cam-Winget AAA Key Distribution Last Updated: April 15, 2002 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo describes problems with the current AAA NASREQ key distribution mechanisms, and proposes enhancements to the NASREQ key distribution model to address these problems. Please send comments on this document to the aaa-wg@merit.edu mailing list. 1. Introduction The IETF AAA Working Group is developing solutions for Authentication, Authorization and Accounting as applied to network access. The AAA Working Group has defined protocols addressing the network access needs specified by the NASREQ, MOBILE IP, and ROAMOPS Walker et al. Expires December 2002 [Page 1]
Internet Draft AAA Key Distribution April 2002 Working Groups as well as TIA 45.6. The solution specified by the AAA Working Group is also thought to address the needs of IEEE 802.11 wireless networks. The solution is intended to augment and eventually replace RADIUS. One area under the AAA Working Group's purview is the subject of session key distribution. For the purposes here, a session key is a cryptographic key that is used either directly or indirectly to protect traffic exchanged over a link between a Network Access Server (NAS) and one of its clients. [NASREQ] describes the key exchange mechanism. This document analyzes the NASREQ key distribution mechanism, identifies a number of security weaknesses, and proposes some enhancements that rectify the identified weaknesses. 1.1. Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119]. 2. Description of NASREQ Key Distribution [NASREQ] defines session key distribution from an AAA server to a NAS. The model (or models) it uses are never explicitly specified, but it is possible to infer the model from the documentation available. The purpose of NASREQ key distribution is to securely establish a session key between the NAS and the NAS client. The AAA server may distribute more than one key to the NAS, each to provide different functions. For instance, it can distribute both encryption and data authenticity keys, or send and receive keys, or master keys that can be used to derive other keys. [NASREQ] allows the AAA server to distribute a key to the NAS client using EAP, but does not specify how this is accomplished. EAP fails to specify mechanisms. As a result, all mechanisms assume that the AAA server and the NAS client already share a key that may be used directly to protect the link between the NAS and the NAS client, and so it is unnecessary to distribute any key to the NAS client. Since no specified instances of EAP key distribution to the NAS client exist, the implicit assumption has to be that such mechanisms are unimportant and will not be deployed as part of the AAA architecture. That is, the lack of any defined EAP key distribution mechanism, and the further lack of any work on such a mechanism, implies that the AAA Working Group implicitly assumes it is only necessary to distribute the key to the NAS. This de facto NASREQ key distribution architecture is the object of our critique. To effect key distribution, at some (unspecified) point in the authentication process, the AAA server decides to distribute a key to the NAS. This is accomplished by inserting a NAS-Session-Key AVP in an Answer packet sent by the AAA server to the NAS. Each distributed key is included in its own NAS-Session-Key AVP. Walker et al. Expires December 2002 [Page 2]
Internet Draft AAA Key Distribution April 2002 The NAS-Session-Key AVP has the following structure: NAS-Session-Key ::= < AVP Header: 408 > { NAS-Key-Direction } { NAS-Key-Type } { NAS-Key } { NAS-Key-Data } [ NAS-Key-Binding ] [ NAS-Key-Lifetime ] [ NAS-IV ] Here o NAS-Key-Direction tells whether the key is bi-directional, used for upstream communication, or for downstream communication; o NAS-Key-Type tells whether the key is a cipher key, an integrity key, or some type of master key, used for further key derivation; o NAS-Key is never defined; o NAS-Key-Data is the distributed key itself; o NAS-Key-Binding indicates the cryptographic primitive to use with the key, and it is optional; o NAS-Key-Lifetime gives the number of seconds remaining before the key expires, and it is optional; and o NAS-IV may be used as an initialization vector, and it is optional. To protect the key distribution, [NASREQ] permits three different mechanisms: 1. IPsec can be used to protect the entire Answer packet conveying the NAS-Session-Key AVP. In this case, ESP would be used to provide confidentiality, integrity, and data origin authentication. 2. TLS can be used to protect the entire Answer packet, or TLS can be used to protect a portion of the packet. 3. CMS can be used to envelope any included NAS-Session-Key AVPs. [NASREQ] specifies no mandatory-to-implement protections for the key distribution. 3. Analysis of NASREQ Key Distribution This section argues there are five fundamental problems with the model assumed by the NASREQ key distribution mechanism: 1. It is incompatible with static keys. Walker et al. Expires December 2002 [Page 3]
Internet Draft AAA Key Distribution April 2002 2. It has an inadequate, non-existent key naming scheme, which opens the mechanism to numerous abuses. 3. It provides inadequate protection for distributed keys. 4. It introduces a novel key distribution architecture with poorly understood security properties, while key distribution is an area bedeviled by subtle bugs. 5. It is not feasible to design the key distribution exchange between the AAA server and the NAS in isolation of any associated handshaking between the NAS and the NAS client. 3.1. Architecture incompatible with static keys In the de facto key distribution model described above, the key distributed by the AAA server to the NAS must not ever be used again, with either the same or with any other NAS. To permit the distributed key to be reused with the same NAS, both the NAS and the NAS client would have to maintain a record of the consumed sequence spaces, nonce spaces, and replay windows used with the key, to prevent inadvertent compromise on reuse, something that is not in general feasible or desirable. To permit the key to be used by a different NAS, a mechanism to prevent the original NAS from using the key to masquerade as the NAS client would be needed. Some people may argue that this latter problem is not a genuine concern because the NAS is trusted. However, the consequences of NAS compromise must be considered. The NAS is not immune from compromise; within the past year alone, for example, the Code Red virus and SNMP buffer overrun alert have applied to nearly every NAS, and almost all NASes required patches as a consequence. Therefore, NASREQ key distribution cannot be used with static keys; all distributed keys must be fresh, never- used-before keys. Another approach exists that can safely employ static keys. Under this approach the static key remains a secret shared only between the AAA server and the NAS client; it is never shared with the NAS. The AAA server employs this static key to distribute a key to the NAS client at the same time it distributes a key to the NAS. The cost of this increased flexibility is that the AAA server generates a random key and distributes it both to the NAS client and to the NAS, not just the NAS, as in the present de facto architecture. Proponents of the NASREQ approach might argue that the use of protocols like TTLS or PEAP will alleviate this problem. They reason that TTLS derives a fresh key at initial contact, and TLS-resume can be used to derive another fresh key at the time of reattachment. This is an attractive line of thinking, but suffers from two problems. The first problem is that organizations deploying TTLS or PEAP still have to obtain an X.509 certificate for their AAA servers and deploy a trust anchor that allows the X.509 certificate to be validated on Walker et al. Expires December 2002 [Page 4]
Internet Draft AAA Key Distribution April 2002 the NAS client. The trust anchor only contains public data, but integrity must be maintained. If the trust anchor can be altered, then the NAS clients cannot properly authenticate the AAA server, and the NAS clients are subject to rogue NASes. This trust anchor provisioning can be costly. It is probably an unacceptable cost for many simple deployments, especially ad hoc wireless networks. The second problem with this reasoning is that it leads to a more complex exchange between the NAS client and the AAA server than is actually necessary. An approach distributing the derived key only to the NAS requires at least a three packet exchange between the NAS client and the AAA server (EAP-TLS actually requires a four packet exchange for TLS-resume) to generate a fresh key, while an approach distributing a fresh randomly generated key to both the NAS and the NAS client requires only a two packet exchange. This means that at the time of a reattachment, when an existing key may be used, the de facto architecture implementation is 50% more complex than necessary. A 50% reduction in complexity is a giant win for security analysis, and, when amortized over all reattachments, it provides a significant performance enhancement for the case that is most time critical. This is not to say that TTLS and PEAP do not provide any value. The argument is rather they do not solve the problem being raised here. Presumably, the NASREQ vision can be completed by enhancing EAP to distribute an analog of the NAS-Session-Key AVP, delivering a session key to the NAS client. Mandating this usage going forward would improve flexibility by restoring the use of static keys, and would simplify the overall system design. 3.2. Inadequate key naming Since NASREQ did not tackle the fundamental issue of key freshness, it also fails to address the issue of binding keys to particular sessions between particular entity pairs. The protocol fails to explicitly name the distributed keys. This is a much more serious problem than the failure to work with static keys, because the history of key distribution protocols shows that failing to properly identify keys presents a major opportunity for compromise of the distributed keys. It is a major vulnerability exploited to launch attacks. To prevent these kinds of weaknesses, it is necessary to specify both the NAS client and the NAS identities in the key distribution, to allow their peers to detect when either cheats or uses the key with unintended parties. It is further necessary to explicitly bind the key to a particular session between the NAS and the NAS client, to detect key reuse problems. The sort of key naming required represents an assertion by the AAA server that the parties may not use the key with any other party, nor with a different session. Thus, the only reasonable identification has to include the AAA identities of the intended pair of peers and some session identifier. This is not needless overhead. Walker et al. Expires December 2002 [Page 5]
Internet Draft AAA Key Distribution April 2002 The NAS-Session-Key AVP can be easily enhanced to provide this additional information. 3.3. Inadequate protections for NAS-Session-Key AVPs The NAS-Session-Key AVP does not require any explicit mandatory protection. Instead, the NASREQ specification permits implementations to rely upon TLS or IPsec to protect the AVP. The problem with this approach is a practical implementation necessity: AAA server implementations are typically software only, running under general-purpose operating systems; many NAS devices are likewise based on public domain UNIX implementation. In either environment it is usually easy for an attacker to insert a Trojan horse that intercepts the data stream between modules, e.g., between the TCP/IP stack and the socket layer. Such a Trojan horse can read and replace distributed keys if the cryptographic protections are applied by a separate module. This defect in the design may be remedied by mandating that the NAS-Session-Key AVP be CMS encapsulated and design due diligence applied to keep the cryptographic operations from crossing module boundaries. The issue is deeper than just the layer at which the cryptographic protections are applied. To minimize the immunity of a key distribution protocol to attack, it is necessary to explicitly bind together the information in a way that the recipient of the distributed key can validate, and this binding typically crosses message boundaries and often must even relate to messages from all three parties in the protocol; section 3.5 below touches further on this theme. These are application protocol issues, and it is simply not reasonable to expect that bilateral mechanisms at other layers can effectively solve these problems. [NASREQ] as it stands today does not exhibit any evidence that this issue has even been contemplated. For instance, the relationship between information in AAA Request messages and Answer messages is never spelled out, being left entirely as a method-specific detail. For some aspects of key distribution to work properly, this relationship has to be defined. Key distribution is not merely a data transport operation; it is also a mechanism for building transitive trust; it is simply infeasible to specify a secure key distribution without binding data across several messages. As an example of this complaint, even CMS wrapping the NAS-Session- Key AVP does not explicitly protect the key distribution from replay. Thus, although the NAS itself can assume a CMS-wrapped key is genuine and issued from the AAA server, the NAS cannot determine that the AVP it receives has not been issued already for some prior session. Instead, the NAS must assume that the AAA server is playing by the rules and issuing only fresh keys, and that there is no man-in-the- middle replacing AVPs before or after they are unwrapped by a lower- layer security mechanism. Many session establishment handshakes do not define adequate key confirmation handshakes, so the NAS could end up sending new data encrypted under already-used keys and IVs before the problem can be detected, potentially compromising previously sent data. What is needed to defeat this kind of attack is to require the Walker et al. Expires December 2002 [Page 6]
Internet Draft AAA Key Distribution April 2002 AAA server to incorporate a challenge from the NAS (and/or the NAS client) into the NAS-Session-Key AVP prior to wrapping. (Inserting a timestamp into the AVP is another option, but maintaining synchronized time in many of the environments served by an AAA server introduces its own problems.) Relying on TLS or IPsec does not solve the problem, because the replay protection afforded by such low-level mechanisms is not adequately bound to the AVP to prevent a Trojan horse from substituting an old AVP for the new one without detection. While it was poorly implemented, the RADIUS authenticator played a useful role. It allowed the NAS to detect replay. By removing the authenticator when going forward to DIAMETER, AAA created a structurally weaker protocol than RADIUS. This omission is an opportunity, however, because it would be better to include an authenticator field in the NAS-Session-Key AVP than as part of the larger Answer packet, so it may be more tightly bound to the distributed key. Finally, the AVP wrapping algorithm is not specified with sufficient granularity. Key distribution protocols make very specific assumption about what is encrypted, what is authenticated but not encrypted, and what must be sent without any protection. [NASREQ] appears to apply the same protection to the entire AVP. This again argues in favor of a mandatory application-specific security protocol. 3.4. Novel solution to a problem bedeviled by subtle failures The cryptographic community has not studied the de facto architecture. Key distribution as defined in [NASREQ] is a three party protocol, with the AAA server, the NAS, and the NAS client all parties with an interest in the exchange. Cryptographers have defined protocols that are known to protect the interests of all three parties in such an exchange, but the NASREQ key distribution does not resemble any of these well-studied protocols. This is particularly troubling, because three-party key distribution of this sort appears to be one of the hardest problems cryptographers have attempted to address. Almost all of the initial proposals to this problem have been flawed. There are examples where minor flaws have remained undiscovered for 20 years after the protocol was published. This repeated history of failure puts a premium on the most conservative possible design, restricting it to well scrutinized protocols. It may be possible to address many of the problems discussed here without adopting a classical, well-studied three-party protocol. It may be, for instance, feasible to clean up the NASREQ architecture to securely distribute keys in an environment where TTLS or PEAP is mandated. However, many years of analysis and scrutiny may be necessary to develop the confidence that this kind of approach is secure from practical attack. It is safer to deploy a protocol known to work correctly than to gamble that the novel design won't be broken after the NASREQ application is widely deployed in the Internet. Walker et al. Expires December 2002 [Page 7]
Internet Draft AAA Key Distribution April 2002 3.5. Key Distribution Protocols not Properly Bound The IETF and the AAA WG have followed the time-honored custom of decomposing problems into separate pieces. In the case of key distribution, the decomposition is into the NASREQ/DIAMETER exchange between the AAA server and the NAS on one hand, and the AAA server and NAS client on the other, the latter being under the purview of the EAP WG. Unfortunately, this decomposition is not correct. It is incorrect because it is difficult to create separate key distribution sub-protocols that, when reassembled into a single system, guarantee the security needs of all three parties involved. A valid key distribution protocol requires that the sub-protocols interact in subtle and non-trivial ways and thus the key distribution specification has to span the domains of at least two Working Groups. As an example of this, [NASREQ] permits the distribution of several keys for the same function, e.g., several Master session keys. On the other hand, while allowing this flexibility, it provides no means of indicating the sequence in which these keys are used, and when to change from one key to another. The point is that, to be useful, the usage of the distributed key must be synchronized on the NAS and the NAS client, and the protocol does not provide the information necessary for synchronization. As a second example, in environments such as IEEE 802.11, an EAP- Success message is inappropriate to signal the open link between the NAS and the NAS client for general traffic. Rather, a key confirmation handshake is required; it is inappropriate to open the link to data traffic until the peer has signaled that its session keys are in place. It is not feasible to design all the details of the key confirmation handshake without also binding the handshake to the details of the key distribution. The reason is that key confirmation requires additional information to be exchanged that would not be configured when there is no trusted third party. An objection has been raised that an approach based on a classical three-party protocol might be more complex than the present course of the AAA Working Group. This objection is wrong on two accounts. First, it is a necessary complexity, because composition of separately designed protocols does not necessarily lead to a secure overall protocol. Second, increasing the local complexity by binding together protocols which are intrinsically linked reduces the coupling of session key establishment from the remainder of the system, and hence also reduces global complexity. 4. NASREQ Key Distribution Requirements A key distribution protocol should provide a secure means for affecting use of the session key. In addition to the requirements already spelled out for NASREQ key distribution, the following requirements are also needed for such a key distribution mechanism: Walker et al. Expires December 2002 [Page 8]
Internet Draft AAA Key Distribution April 2002 1. Must ensure the session key is fresh; 2. Must name the key; 3. Must bind the key to the intended session between the NAS and NAS client; and 4. Must enforce protection of the session key. 4.1. Session key freshness Key distribution mechanisms must ensure that the session key distributed is statistically unique. That is, a session key must never be used again in either subsequent sessions or reused with another NAS. The protocol must allow both the NAS and the NAS client some means of verifying the freshness of the key distribution. 4.2. Key naming Each key must be properly identified to a given session corresponding to a NAS and NAS client. The protocol and key naming scheme together must allow the participants to detect the unauthorized use of a distributed key. The protocol must allow each party to verify that the session peer is the other intended recipient of the distributed key. 4.3. Key binding A key must be properly bound to a particular NAS and NAS client session. The key binding is critical to allow both the NAS and NAS client to properly synchronize to a session key. Since the key is ultimately used to establish communications between the NAS and the NAS client, the protocol must be explicit on when the distributed key becomes active as well as allowing the NAS and NAS client to validate and confirm receipt of the key. 4.4. Protection of the session key The protocol must provide assurances to all three parties (the AAA server, the NAS, and the NAS client) that no other parties have access to the distributed session key, assuming none of the three publishes it either intentionally or inadvertently. 5. Proposed NASREQ Key Distribution Architecture and Enhancements < To be supplied by 3 May 2002 > Walker et al. Expires December 2002 [Page 9]
Internet Draft AAA Key Distribution April 2002 6. Security Considerations This document concerns the security of [NASREQ]. The authors hope that the analysis presented here will be embraced by the AAA Working Group, resulting in a more secure protocol. 7. Acknowledgements 8. References [PROB] Calhoun, P., Aboba, B., Guttman, E., Mitton, D., Nelson, D., Schoenwaelder, J., Wolff, B., Zhang, X., "AAA Problem Statements", work in progress, draft-ietf-aaa-issues-05.txt, January 2002. [TRANS] Aboba, B., Wood, J., "Authentication, Authorization, and Accounting (AAA) Transport Profile", work in progress, draft-ietf-aaa-transport-05.txt, November 2001. [DIAM] Calhoun, P., Akhtar, H., Arkko, J., Guttman, E., Rubens, A., Zorn, G., "Diameter Base Protocol", work in progress, draft-ietf-aaa-diameter-08.txt, November 2001 [NASREQ] Calhoun, P., Bulley, W., Rubens, A.C., Haag, J., Zorn., G. "Diameter NASREQ Application", work in progress, draft-ietf-aaa-diameter-nasreq-08.txt, November 2001. [CMS] Calhoun, P., Farrell, S., Bulley, W., "The Diameter CMS Security Application", work in progress, draft-ietf-aaa-diameter-cms-03.txt, November 2001. [TTLS] Funk, P., Blake-Wilson, S., "EAP Tunneled TLS Authentication Protocol", work in progress, draft-ietf-pppext-eap-ttls-01.txt, February 2002 [PEAP] Anderson, H., Josefsson, S., Zorn, G., Simon, D., Palekar, A., "Protected EAP Protocol (PEAP)", work in progress, draft-josefsson-pppext-eap-tls-eap-02.txt, February 2002 9. Author Addresses Jesse Walker Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97214 USA jesse.walker@intel.com Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA rhousley@rsasecurity.com Nancy Cam-Winget Mountain View, CA 94040 USA nance@winget.net Walker et al. Expires December 2002 [Page 10]
Internet Draft AAA Key Distribution April 2002 10. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. In addition, the ASN.1 modules presented in Appendices A and B may be used in whole or in part without inclusion of the copyright notice. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Walker et al. Expires December 2002 [Page 11]