Internet Draft R. Moskowitz A.DeKok Document: draft-moskowitz-RADIUS-Client- ICSAlabs Kickstart-01.txt IDT Expires: May 2004 November 2003 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 RADIUS 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 RADIUS 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 the Shared Secret Provisioning Protocol [4]. For RADIUS Client Kickstart, SSPP is run over SNMP [5]. The Master Secret is used in an initial RADIUS exchange to create a session Moskowitz, DeKok Expires - May 2003 [Page 1] RADIUS Client Kickstart November 2003 secret that is used as the normal RADIUS client shared secret. SSPP can be used to change the Master Secret whenever required. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the RADIUS 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 [6]. Table of Contents 1. Introduction...................................................2 1.1 Problem Statement..........................................3 2. Adding a level of indirection to the RADIUS Client Secret......4 2.1 Basic components and protocols.............................5 3. The MIB Objects................................................7 4. RADIUS Client Master Secret Bootstrap..........................8 5. RADIUS Client Master Secret Change.............................8 6. RADIUS Client Registration.....................................8 6.1 RADIUS Client Request......................................9 6.2 RADIUS Server Response....................................10 6.3 Encrypted-Data Attribute..................................10 6.4 Table of Attributes.......................................11 IANA Considerations..............................................12 Security Considerations..........................................12 Acknowledgments..................................................12 Author's Addresses...............................................13 References.......................................................13 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 [7] Access Points. The RADIUS server MUST have the RADIUS Client Shared Secret bound to the RADIUS ClientĘs IP Address. This normally requires the RADIUS Client to have a fixed IP address, which is not a DHCP dynamically assigned address. The RADIUS Client needs a method for entering the secret into the RADIUS Client securely and changing it. This Moskowitz, DeKok Expires - May 2003 [Page 2] RADIUS Client Kickstart November 2003 document discusses the RADIUS Client environment, the constraints it places on 802.1x deployments and a method to 'plumb' 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) 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 text has been replaced in the 802.1x update, 802.1aa with: In situations where it is desirable to centrally manage authentication, authorization and accounting (AAA) for IEEE 802 networks, deployment of a backend authentication and accounting server is desirable. In such situations, it is expected that IEEE 802.1X Authenticators will function as AAA clients. This only generalizes Annex D for any AAA client/server, including the aforementioned RADIUS usage. 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 RADIUS 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. Moskowitz, DeKok Expires - May 2003 [Page 3] RADIUS Client Kickstart November 2003 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 RADIUS ClientĘs IP address, or provide a name that can be readily resolved to its IP address, for example the RADIUS 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. 2. Adding a level of indirection to the RADIUS 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 RADIUS Client 'name' and a master secret. - A RADIUS Client boot or registration protocol to update the traditional RADIUS Client Database of IPaddress and shared secret. This registration protocol will use the RADIUS Client name and master secret. This new RADIUS 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 SSPP over SNMP. - A master secret change process, also based on SSPP over SNMP. Moskowitz, DeKok Expires - May 2003 [Page 4] RADIUS Client Kickstart November 2003 2.1 Basic components and protocols When SSPP is used for maintaining the RADIUS Client name/secret database, the RADIUS client is the SSPP server and the RADIUS server is the SSPP client. The SSPP domain parameters will be the Diffie-Hellman fixed field, g and p. Q is not needed in the protocol as it is only used in the calculation of p, and all values of p used are set below, provided from work in IPsec [8]. The cyrptographic community has produced many estimates of Diffie-Hellman key size to provide 128 bits of symmetric key strength. The generally agreed range is from a Diffie-Hellman size of 2048 to 3072. The 3072 length SHOULD be used unless the RADIUS Client is so constrained, as this is not practical, then the 2048 length MAY be used. It should be noted that Kickstart is a very infrequently used protocol and that in many cases, a long computational time will not be an impediment to its use. Parameter Value Key length 2048 P is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 } Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF g 2 (decimal) Key length 3072 P is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] + 1690314 } Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 Moskowitz, DeKok Expires - May 2003 [Page 5] RADIUS Client Kickstart November 2003 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF g 2 (decimal) These are the same values as IKE Oakley Groups 14 and 15. RADIUS Client Master database: This table consists of the following entries: RADIUS Client Name RADIUS Client Public Diffie-Hellman value Current Master secret Date of last Master secret change Date of last Session secret Function 1 ū RADIUS Client Master Secret Bootstrap This is a protocol that will facilitate the RADIUS Server's discovery of a new Access Point or NAS and provide for an over-the- wire establishment of a Master secret. This protocol MUST support multiple RADIUS Servers each having a unique Master secret with the RADIUS Client. Function 2 ū RADIUS Client Master Secret Change This protocol will allow the RADIUS Server to trigger a change of the Master Secret. This is provided by the SSPP over SNMP changing a secret exchange. After the Master Secret is changed, the RADIUS Client MUST establish a new RADIUS Client Secret via the RADIUS Client Registration Session Secret. Function 3 ū RADIUS Client Boot Session Secret When the RADIUS Client boots, it MUST use its Name and Master Secret to authenticate its IPaddress to the Server and establish a Randomly Moskowitz, DeKok Expires - May 2003 [Page 6] RADIUS Client Kickstart November 2003 selected Session Secret as the RADIUS 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. The MIB Objects The SSPP Server has some specific MIB objects and two tables of objects for each SSPP Client. The SSPP Proxy also has a table of objects. The SSPP Server specific objects are: Domain Parameters: g and p Diffie-Hellman key pair (the private key MUST be protected from reading) SSPP Server Address Nonce The SSPP Server's SSPP Client table objects are: SSPP Client Address SSPP Client Diffie-Hellman public key SSPP Client Nonce SSPP Client Signature SSPP Server Signature Change Flag Shared Secret (MUST be protected from reading) The SSPP Server's Proxied SSPP Client table is a temporary table with objects: SSPP Proxy Address SSPP Proxy Signature SSPP Client Address SSPP Client Diffie-Hellman public key SSPP Client Nonce SSPP Client Signature SSPP Server Signature Shared Secret (MUST be protected from reading) The SSPP Proxy's SSPP Client table is a temporary table with objects: SSPP Client Address SSPP Client Diffie-Hellman public key SSPP Client Nonce SSPP Client Signature ForwardFlag Proxy Signature Moskowitz, DeKok Expires - May 2003 [Page 7] RADIUS Client Kickstart November 2003 A SSPP Client SHOULD keep the following objects in the MIB: Domain Parameters Diffie-Hellman key pair (the private key MUST be protected from reading) SSPP Client Address Nonce SSPP Server Address SSPP Server Signature SSPP Proxy Address Shared Secret (MUST be protected from reading) 4. RADIUS Client Master Secret Bootstrap The RADIUS Client Master secret will be the result of an SSPP basic exchange over SNMP between the SSPP Client and the SSPP Server. The RADIUS Server is the SSPP Client and the RADIUS Client is the SSPP Server. Once a Master Secret is set, the RADIUS Client MUST not perform another bootstrap until it is reset to its initial status. The RADIUS Server SHOULD have an SNMP based discovery process, identifying potential clients by the presence of the RADIUS Client MIB objects. The RADIUS Server MUST support the SSPP client function, both of the basic and the proxy exchanges. The RADIUS Server SHOULD support the SSPP proxy function. The RADIUS Client MUST restrict the SSPP basic exchange to one RADIUS Server. After the first server performs the basic exchange, the RADIUS Client MUST reject any other RADIUS server performing the basic exchange, and MUST only accept the change secret and proxy exchanges. The RADIUS Client MUST have a 'local' function, like a reset button, to remove all RADIUS Server associations. 5. RADIUS Client Master Secret Change A Master Secret change uses the SSPP over SNMP changing a secret exchange. The RADIUS Server initiates it. 6. RADIUS Client Registration The RADIUS Client Registration process uses new RADIUS packets: Access-Boot and Access-Booted. These RADIUS packets are NEVER proxied across RADIUS servers. The Access-Boot is similar to the Access-Request. The Access-Booted is similar to the Access-Accept. Moskowitz, DeKok Expires - May 2003 [Page 8] RADIUS Client Kickstart November 2003 6.1 RADIUS Client Request For this process, the RADIUS client has a Master shared secret, an IP address, and that it knows the IP address of the RADIUS server it will use. The purpose of RADIUS client registration is to allow the client to inform the RADIUS server of its new IP address. Once it has received an IP address (via some method outside of this specification), the RADIUS client "registers" with the RADIUS server. It does this by sending a self-signed RADIUS packet, of type Access-Boot, to the RADIUS server. The packet contains the IPv4 (or IPv6) address of the NAS, along with the UDP source port, an identifier for the NAS (usually MAC address, or name), and a timestamp. This packet is signed with a Message-Authenticator attribute. The RADIUS server uses the Calling-Station-Id (usually containing the MAC address of the client), or the NAS-Identifier, to look up the shared secret in its database. The Master shared secret is then used to validate the Message-Authenticator attribute in the request. This process ensures that the RADIUS server can verify that the client possesses the same correct secret. If the source IP (or IPv6) address of the Access-Boot packet does not match the contents of the NAS-IP-Address (or NAS-IPv6-Attribute) packet, then the request MUST be silently discarded, and a response MUST NOT be sent back to the NAS. Access-Boot packets MAY NOT be proxied. If the source UDP port of the Access-Boot packet does not match the contents of the NAS-Port attribute, then the request MUST be silently discarded, and a response MUST NOT be sent back to the NAS. Access-Boot packets MAY NOT be sent from being a NAT gateway. If the client is unknown (contents of Calling-Station-ID or NAS- Identifier are unknown), then the request MUST be silently discarded, and a response MUST NOT be sent back to the NAS. Request from unknown clients may be attacks, and must not compromise the server. If the Access-Boot packet is badly formed, or does not contain a Message-Authenticator attribute, or the Message-Authenticator attribute fails validation, then the request MUST be silently discarded, and a response MUST NOT be sent back to the NAS. The contents of the Called-Station-Id attribute SHOULD be an identifier of the RADIUS server to which the client is attempting to register. This attribute helps verify that the request is being Moskowitz, DeKok Expires - May 2003 [Page 9] RADIUS Client Kickstart November 2003 sent to the correct RADIUS server. The RADIUS server MAY ignore the contents of this attribute. The Event-Timestamp attribute should be used to help prevent replays. We may want a separate "boot number" attribute, instead... The Access-Boot packet MUST also contain a State attribute. The State attribute is sent by the client to the server, and is used by the client to associate Access-Booted packets with Access-Boot requests. If the server replies with an Access-Booted packet, then the State attribute MUST be copied unmodified from the Access-Boot packet to the Access-Booted packet. The client SHOULD create a State attribute at least 16 octets in length, using a CSPRNG. 6.2 RADIUS Server Response If the RADIUS server validates the Access-Boot request, then it MUST add the IP (or IPv6) address of the client, from the NAS-IP-Address (or NAS-IPv6-Address) attribute to its list of addresses for allowed RADIUS clients. From this point on, the RADIUS server may treat the RADIUS client in the same manner as a client with a static IP, configured on the RADIUS server. The RADIUS server responds to the client with an Access-Booted packet. This packet MUST echo back to the client the State attribute from the Access-Boot request. The server MAY also include a Session-Timeout attribute. After this timeout, the client MUST re-authenticate itself to the server, and the server MUST NOT process any more RADIUS requests from the client. The client SHOULD re-authenticate itself prior to this timeout, to ensure that it does not lose access to the RADIUS server, while it has outstanding Access-Requests to that server. The Access-Booted packet SHOULD also contain the RADIUS Client Session Shared Secret. This Secret will be at least 16 octets in length, using a CSPRNG. It will be used as the regular RADIUS Client secret for this session. The secret will be transmitted in a new encrypted-data attribute. The Access-Booted packet MUST contain a Message-Authenticator attribute, to sign the packet contents. The Access-Booted packet also SHOULD contain a "boot number" attribute, which is echoed from the Access-Boot packet. 6.3 Encrypted-Data Attribute Moskowitz, DeKok Expires - May 2003 [Page 10] RADIUS Client Kickstart November 2003 The Encrypted-Data Attribute is an AES Key-wrap Attribute containing the encrypted data, in this case just the RADIUS Client Session Secret encrypted by the Master Secret: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client Session Secret | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client Session Secret | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client Session Secret | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client Session Secret | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Author's Note: Need AES Key Wrap format here. The Authenticator is LTRUNC-96(HMAC-SHA1(Master-Secret,(encrypted- data))). 6.4 Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Boot Booted # Attribute 0-1 0 4 NAS-IP-Address [ Note 1 ] 1 0 5 NAS-Port 1 1 24 State [ Note 2] 0 0-1 27 Session-Timeout 0-1 0 30 Called-Station-Id 1 0 31 Calling-Station-Id 0-1 0 32 NAS-Identifier 1 1 55 Event-Timestamp 1 1 80 Message-Authenticator 0-1 0 96 NAS-IPv6-Address [ Note 1 ] 0 0-1 TBD Encrypted-Data Moskowitz, DeKok Expires - May 2003 [Page 11] RADIUS Client Kickstart November 2003 Note 1: An Access-Boot packet MUST contain either a NAS-IP-Address or a NAS-IPv6-Address attribute. An Access-Boot packet MUST NOT contain both attributes. Note 2: The client sends The State attribute in an Access-Boot packet to the server. If the server replies with an Access-Booted packet, then the State attribute MUST be copied unmodified from the Access-Boot packet to the Access-Booted packet. The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 1 Exactly one instance of this attribute MUST be present in packet. IANA Considerations Allocate RADIUS codes for Access-Boot and Access-Booted. Allocate RADIUS Attribute types for Encrypted-Data. 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, as discussed in [5]. If the server operator detects a middleman, it can back off of the exchange. There is a potential replay DOS attack against the Client Session Secret boot protocol. The inclusion of a Boot Number in the Client- Boot and Client-Booted attributes effectively blocks a replayed Access-Boot packet. Acknowledgments Moskowitz, DeKok Expires - May 2003 [Page 12] RADIUS Client Kickstart November 2003 This document is the result of discussions at IEEE 802.11i and 802.1 meetings. John Vollbrecht was 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 Alan DeKok Email: aland@ox.org 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 Moskowitz, R., "The Shared Secret Provisioning Protocol", Internet Draft draft-moskowitz-shared-secret-provprotocol-01.txt, November 2003. 5 Moskowitz, R., "SSPP over SNMP", Internet Draft draft-moskowitz- sspp-snmp-01.txt, November 2003. 6 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7 IEEE DRAFT Std 802.11i/D7, "Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications -- Specification for Enhanced Security", October 2003. 8 Kivinen, T., and Kopo, M., "More MODP Diffie-Hellman groups for IKE", Internet Draft draft-ietf-ipsec-ike-modp-groups-05.txt, January 2003. Moskowitz, DeKok Expires - May 2003 [Page 13] RADIUS Client Kickstart November 2003 Moskowitz, DeKok Expires - May 2003 [Page 14]