RADIUSEXT Working Group Paul Funk Internet-Draft Funk Software, Inc. Category: Standards Track August 2004 RADIUS Shared Secret Security Amplification Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft describes how a mechanism defined in [PKCS-5] can be used to amplify the security of a RADIUS shared secret; namely, that a precursor secret is hashed many times to produce an amplified shared secret for use in RADIUS. A dictionary attack against the resulting shared secret will be infeasible due to its high entropy. A dictionary attack against the precursor secret will require the attacker to apply the same hashing process to each candidate precursor secret to derive a candidate RADIUS shared secret, prior to applying it to the RADIUS packet. This approach allows administrators to use the same types of secrets that they are comfortable with as precursor secrets. The algorithm Internet-Draft August 2004 to generate the amplified shared secret is deterministic, so the precursor shared secret is all that needs to be remembered. Unlike approaches that require changes to RADIUS servers and clients, the amplification approach is compatible with all current equipment. It is simply a means to generate a shared secret, which then may be configured in the NAS or RADIUS server just as any shared secret would be. For example, a simple utility can accept the precursor secret, amplify it, and present it to the administrator, who may copy and paste it into the configuration application of a RADIUS server or NAS. Table of Contents 1. Introduction......................................................2 2. The Amplification Algorithm.......................................3 2.1 The Salt......................................................4 3. Deployment Options................................................5 4. Security Considerations...........................................6 5. References........................................................6 6. Author's Address..................................................7 7. Full Copyright Statement..........................................7 1. Introduction The RADIUS protocol relies on a shared secret to authenticate messages between client and server, as well as to encrypt sensitive data such as session keys. The cryptography used with shared secrets involves nothing stronger than hashing functions, making them vulnerable to off-line dictionary attack by anyone capable of eavesdropping on RADIUS traffic. Though it is often recommended that high entropy shared secrets be chosen, or that IPsec be used to provide yet stronger protection [RFC3580], such recommendations do not typically induce the hoped for behavior modification in network administrators, who by and large continue to use shared secrets they find easy to remember. This is hardly surprising. The choice of a strong password must be weighed against the likelihood of forgetting it, or the security implications of having to write it down. IPsec, for its part, is difficult to set up, nor is it even available on many NAS platforms. While these vulnerabilities and the means of exploiting them have long been understood, RADIUS shared secrets have recently become the object of renewed despite. For example, [VULN] describes how a layer 2 attack can attract RADIUS packets to the attacker's network device, after which an off-line dictionary attack may be mounted. Paul Funk expires February 2005 [Page 2] Internet-Draft August 2004 The authors of [VULN] suggest that IPsec protection of RADIUS traffic be made a requirement, not just a recommendation. But it can hardly be expected that changing a "SHOULD" to a "MUST" will alter reality. Nor would it necessarily be desirable, given the costs of introducing IPsec on NAS platforms as well as the IPsec deployment challenges that many administrators can only contemplate with dread. Fortunately, the means of mitigating this variation of the "weak password" problem is as well understood as the problem itself. This draft describes how a mechanism defined in [PKCS-5] can be used to amplify the security of a shared secret; namely, that a precursor secret is hashed many times to produce an amplified shared secret for use in RADIUS. A dictionary attack against the resulting shared secret will be infeasible due to its high entropy. A dictionary attack against the precursor secret will require the attacker to apply the same hashing process to each candidate precursor secret to derive a candidate RADIUS shared secret, prior to applying it to the RADIUS packet. This strategy effectively multiplies the difficulty in mounting a dictionary attack by the number of hash iterations used to derive the shared secret. Thus, if 1,000,000 (2 ^ 20) hash iterations are used, a unamplified shared secret that might take one hour to crack would take over a hundred years if amplified. Differently stated, 20 bits of effective entropy are added to a secret when hashed one million times; thus, a secret with 40 bits of entropy provides 60 bits of effective entropy after amplification. This approach allows administrators to use the same types of secrets that they are comfortable with as precursor secrets. The algorithm to generate the amplified shared secret is deterministic, so the precursor secret is all that needs to be remembered. Unlike approaches that require changes to RADIUS servers and NASes, the amplification approach is compatible with all current equipment. It is simply a means to generate a shared secret, which then may be configured in the NAS or RADIUS server just as any shared secret would be. For example, a simple utility can accept the precursor secret, amplify it, and present it to the administrator, who may copy and paste it into the configuration application of a RADIUS server or NAS. 2. The Amplification Algorithm The amplification algorithm applies the PBKDF2 function defined in [PKCS-5] against the precursor secret and an optional salt value to produce an octet sequence, which is then Base64-encoded to produce the RADIUS shared secret. Paul Funk expires February 2005 [Page 3] Internet-Draft August 2004 The PBKDF2 function applies an underlying pseudo-random function iteratively to produce an octet sequence of arbitrary length. The number of iterations determines the amount of security amplification that results. The PBKDF2 function takes arguments as follows: PBKDF2(P, S, c, dkLen) where: P is the precursor secret S is the optional salt c is the iteration count dkLen is the number of octets of binary output. Both precursor secret and salt are UTF-8 encoded text. Null- terminators are not included. Note that ASCII is a subset of UTF-8 and thus automatically conforms to this requirement. The salt is optional. If a salt is not provided, zero octets are used as salt. Rather than suggesting that administrators select input variables to the algorithm, this draft defines the following standard choices in the interest of interoperability: - The underlying pseudo-random function is HMAC-SHA-1 (as suggested by [PCKS-5]). - The number of iterations (c) is 2 ^ 20, or hex 100000, providing an amplification factor of over one million. - The number of octets of binary output (dkLen) is 12, resulting in a 16 character shared secret after Base64-encoding, with 96 bits of apparent entropy. 2.1 The Salt The salt input to PBKDF2 may be used to guarantee the minimum entropy of the information that is input to the amplification algorithm. For example, an administrator may select a phrase of reasonable entropy as the salt for all RADIUS equipment in a domain. This salt may be used as a permanent configuration value in a utility for generating amplified shared secrets. Other personnel may then use this utility to create shared secrets based on precursor secrets Paul Funk expires February 2005 [Page 4] Internet-Draft August 2004 they select. Even if the precursor secrets are low entropy, including the salt in the computation increases the final entropy of the shared secret. Specifically, the number of bits of effective entropy will be equal to the entropy of the salt plus the entropy of the precursor secret plus the 20 bits that result from amplification. This allows security configuration of RADIUS equipment to be delegated to personnel who may not fully appreciate the weak password problem. Salts may also be used across domains. For example, administrators of separate domains beween which RADIUS traffic flows may select a common salt to be used between their organizations. 3. Deployment Options The following mechanisms are options for deploying shared secret amplification: - Native support in RADIUS equipment The RADIUS client or server may provide shared secret amplification as part of its configuration application. The configuration application SHOULD configure the amplified shared secret, not the precursor secret, into the database of the device. This avoids having to perform amplication dynamically at run time. The amplification algorithm typically takes a number of seconds; this time is better spent once while configuring than many times while running. - Amplification utility An amplification utility may be created that administrators can run on their desktops. The amplified shared secret may be copied from the utility and pasted into the configuration application of the RADIUS device. - Web service A web service may be deployed that accepts a precursor secret and returns the amplified shared secret via a browser. This is an attractive approach when using a salt. The salt value can be configured into the web service, and the user merely enters the precursor secret. This allows the confidentiality of the salt value to be protected from users of the service. However, if a web service or any other network service is used, it MUST be made secure against eavesdroppers. For example, HTTPS should be used, and the network on which it is made available should be properly restricted. Paul Funk expires February 2005 [Page 5] Internet-Draft August 2004 If a salt is used, user authentication should be performed to preclude dictionary attacks against the salt. If a hostile user is permitted access to a web service containing a salt, and if low-entropy precursor secrets are deployed in reliance on the additional entropy provided by the salt, a combination on- line/off-line dictionary attack may be mounted: The hostile user captures a RADIUS packet, then uses the web service with a sequence of trial precursor secrets to retrieve amplified shared secrets, which it then tests against the captured RADIUS packet. While amplification is still effective, it is so in a reduced manner, as the entropy of the salt is subtracted from the total effective entropy during the dictionary attack. 4. Security Considerations The amplification algorithm described in this draft mitigates the weak shared secret problem; however it does not solve it. Administrators must still select precursor secrets of adequate entropy. A general rule for ordinary text is that each character provides about 2.5 bits of entropy. Thus, a password of 12 characters might have 30 bits of entropy. Choosing passwords that seem unreadable, that is, that don't conform to the usual conditional probabilities from one character to the next, provide greater entropy per character. Another rough statement that might be made is that 40 or fewer bits of password entropy is weak, 50 bits is reasonable, and 60 bits or greater is strong. The amplification algorithm adds 20 bits to the effective entropy of a secret. Thus, a secret with 30 bits of entropy results in an amplified shared secret with 50 bits of entropy. The recommendation for a precursor secret that looks like ordinary text is therefore that it be at least 12 characters long, for 50 bits of effective entropy after amplification, and preferably be 16 characters or longer, for 60 or more bits of effective entropy after amplification. References [VULN] Chou, R., Andrade, M., and J. Wright, "RADIUS Vulnerabilities in a Wireless Environment", http://www.drizzle.com/~aboba/RADEXT/radius_vuln_00.txt, July 2004. [PKCS-5] RSA Laboratories, "PKCS #5 v2.0: Password-Based Cryptography Standard", March 25, 1999. Paul Funk expires February 2005 [Page 6] Internet-Draft August 2004 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [SHA-1] National Institute of Standards and Technology (NIST), "FIPS Publication 180-1: Secure Hash Standard", April 1994. [RADIUS] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. 5. Author's Address Questions about this memo can be directed to: Paul Funk Funk Software, Inc. 222 Third Street Cambridge, MA 02142 USA Phone: +1 617 497-6339 E-mail: paul@funk.com 6. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be Paul Funk expires February 2005 [Page 7] Internet-Draft August 2004 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. Paul Funk expires February 2005 [Page 8]