Internet Draft R. Moskowitz draft-moskowitz-radius-client-kickstart-00.txt ICSAlabs Expires: April 2003 October 2002 RADIUS Client Kickstart Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract RADIUS servers [2] require foreknowledge of the IP address of the RADIUS clients, as the shared secret is bound to the address. This has been a manageable situation when the clients were just NASs (Network Access Servers). With the advent of IEEE 802.1x [3], there is a significant increase in RADIUS clients in organizations not prepared to have the clients use fixed IP addresses and manage the shared secret. To address the concerns of the IEEE 802.1 and 802.11 Task Groups a level of indirection is added; a Master secret bound to the name of the RADIUS client. This Master secret is created by a Diffie-Hellman exchange. It is used in an initial RADIUS exchange to create a session secret that is used as the normal RADIUS client shared secret. Conventions used in this document Moskowitz Expires - April 2003 [Page 1] RADIUS Client Kickstart October 2002 In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. Table of Contents 1. Introduction...................................................2 1.1 Problem Statement..........................................2 2. Adding a level of indirection to the Client Secret.............4 2.1 Basic components and protocols.............................4 3. Client Master Secret Bootstrap.................................5 4. Client Master Secret Change....................................5 5. Client Boot Session Secret.....................................6 Security Considerations...........................................6 References........................................................6 Acknowledgments...................................................6 Author's Addresses................................................7 1. Introduction The IEEE 802.1x Port-Based Network Access Control standard recommends the use of RADIUS for the Authentication Server, making the 802.1x Authenticators RADIUS Clients. RADIUS Clients have some well-defined security configuration requirements that will present challenges to effective 802.1x deployments as is anticipated for 802.1 compliant switches and 802.11i [5] Access Points. The RADIUS server MUST have the RADIUS Client Shared Secret bound to the ClientĘs IP Address. This normally requires the Client to have a fixed IP address, which is not a DHCP dynamically assigned address. The Client needs a method for entering the secret into the Client securely and changing it. This document discusses the RADIUS Client environment, the constraints it places on 802.1x deployments and a method to 'pumb' a RADIUS Client. The information imparted here is not expected to be included within any IEEE document, even though it impacts 802.1x, 802.11i and 802.11f implementations. If this information and methodology were included anywhere within IEEE, it would be 802.1x Annex D. 1.1 Problem Statement 802.1x states in Annex D, (informative text) Moskowitz Expires - April 2003 [Page 2] RADIUS Client Kickstart October 2002 IEEE 802.1X RADIUS Usage Guidelines D.1 Introduction IEEE Std 802.1X-2001 enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and IEEE 802.11 wireless LANs. Although RADIUS support is optional within IEEE Std 802.1X- 2001, it is expected that most IEEE Std 802.1X-2001 Authenticators will function as RADIUS clients. This functioning as RADIUS clients results in adhering to the following from RADIUS RFC (2865), Section 3. Administrative Note The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well- chosen password. It is preferred that the secret be at least 16 octets. This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks. The secret MUST NOT be empty (length 0) since this would allow packets to be trivially forged. A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied. Simply put, every AP implementing RADIUS support MUST: - Provide a secure method for entering the RADIUS Client secret that SHOULD be at least 16 bytes. - Either provide the RADIUS Server with the ClientĘs IP address, or provide a name that can be readily resolved to its IP address, for example the ClientĘs DNS name. The first casualty is the use by the switch or AP of DHCP for its IP address assignment. DHCP can only be used if the DHCP server always leases the same address to the switch or AP, or the RADIUS Server can query the DHCP Server for the switch's or AP's IP address by a DNS-styled name. The second casualty is switch or AP auto configuration for small offices. You MUST enter the shared secret into the switch or AP in addition to setting the switch's or AP's IP address information (that most small office support people are not trained for). The final casualty is network security. Secret changes after personnel changes are cumbersome and thus may not be done. Moskowitz Expires - April 2003 [Page 3] RADIUS Client Kickstart October 2002 2. Adding a level of indirection to the Client Secret This conundrum can be dealt with by adding a level of indirection: - Creation of a new RADIUS Client table in the Server, keyed by a Client 'name' and a master secret. - A Client boot protocol to update the traditional Client Database of IPaddress and shared secret. This boot protocol will use the Client name and master secret. This new Client name/secret database needs a method to effectively populate it and maintain it. This can be achieved by: - A master secret bootstrap process based on a Diffie-Hellman exchange. -A master secret change process, also based on a Diffie-Hellman exchange. 2.1 Basic components and protocols Client Master database This table consists of the following entries: Client Name Client Public Diffie-Hellman value Current Master secret Date of last Master secret change Date of last Session secret Function 1 ū Client Master Secret Bootstrap This is a protocol that will facilitate the Server's discovery of a new Access Point and provide for an over-the-wire establishment of a Master secret. This protocol MUST support multiple Servers having a Master secret with the client. Function 2 ū Client Master Secret Change This protocol will allow the Server to trigger a change of the Master Secret. It MUST provide Perfect Forward Secrecy from the current Master Secret. Function 3 ū Client Boot Session Secret Moskowitz Expires - April 2003 [Page 4] RADIUS Client Kickstart October 2002 When the Client boots, it will use its Name and Master Secret to authenticate its IPaddress to the Server and establish a Randomly selected Session Secret as the Client shared secret in RFC 2865. If the Master Secret is changed via Function 2, a new boot Session Secret will also be created. 3. Client Master Secret Bootstrap The Client Master secret will be the result of a Diffie-Hellman exchange, over SNMP between the Client and the Server. The basic protocol is: S: GET Client_Master_Public_DH-Value C: SEND Client_Master_Public_DH-Value, Nonce S: SET Server_Master_Public_DH-Value, Server_IPSaddress, Nonce, HMAC-SHA1(Server_IPSaddress|Nonce) The Master secret is: HMAC-SHA1(Client_Nonce|Server_Nonce) Where the key for the HMAC is Kij from the Diffie-Hellman exchange. This Master secret is used in the HMAC in the SET. Once a Master Secret is set, the Client will not Perform another bootstrap until it is reset to its initial status. One RADIUS Server MAY Proxy the bootstrap for another RADIUS Server. In such a case the initial RADIUS Server MUST have the other Server's Public Diffie-Hellman value. It does the following exchange: S: GET Client_Master_Public_DH-Value C: SEND Client_Master_Public_DH-Value, Nonce S: SET Server2_Master_Public_DH-Value, Server2_IPSaddress, Nonce, HMAC-SHA1(Server_IPSaddress|Nonce) The HMAC is keyed with the initial Server's Master secret. The initial server MUST have a method of communicating the information from the client and the Server Nonce to the second Server. 4. Client Master Secret Change A secret change looks just like the proxied key establishment, but it is for a RADIUS server whose IPaddress is already set in the Client. Moskowitz Expires - April 2003 [Page 5] RADIUS Client Kickstart October 2002 5. Client Boot Session Secret The Client Session Secret boot protocol uses standard RADIUS exchanges, except there is no Client Authentication attribute. There is a new attribute of a Secret request, by the client, signed with the client's Master secret, and a response from the RADIUS server with the Session Secret encyrpted, and signed with the Master secret. Security Considerations This protocol uses an un-authenticated Diffie-Hellman exchange. This is open to a Man-in-the-Middle attack. This requires either the operator of the RADIUS server to know that there is no possibility for a system between the RADIUS server and the client (e.g. operator can see the cross-over cable between the two devices), or the operator validates the fingerprint of the Client's public Diffie-Hellman value. If the server operator detects a middleman, it can back off of the exchange. The client is indirectly protected by the server in this manner. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Rigney, C., etal, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000 3 IEEE Std 802.1X-2001, "Port-Based Network Access Control", June 2001 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 IEEE DRAFT Std 802.11i, "Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications -- Specification for Enhanced Security", April 2002 Acknowledgments Moskowitz Expires - April 2003 [Page 6] RADIUS Client Kickstart October 2002 This document is the result of discussions at IEEE 802.11i and 802.1 meetings. John Vollbrecht of Interlink Networks has been of invaluable assistance in focusing the problem statement and the solution methodology. At the October 2002 meeting of IEEE 802.1, a straw vote passed unanimously to back addressing the RADIUS Client deployment problem as covered here. Author's Addresses Robert Moskowitz TruSecure/ICSAlabs 1000 Bent Creek Blvd, Suite 200 Mechanicsburg, PA Email: rgm@trusecure.com Moskowitz Expires - April 2003 [Page 7]