1. doc.: IEEE 802.11-02/516r0-I Submission September 2002 Robert Moskowitz, ICSALabsSlide 1 RADIUS Client Kickstart Robert Moskowitz, ICSALabs John Vollbrecht, Interlink Networks

2. doc.: IEEE 802.11-02/516r0-I Submission September 2002 Robert Moskowitz, ICSALabsSlide 2 Houston, we have a problem IEEE 802.1X RADIUS Usage Guidelines –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. RFC 2865 Sec 3 –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.

3. doc.: IEEE 802.11-02/516r0-I Submission September 2002 Robert Moskowitz, ICSALabsSlide 3 Stated Simply When an AP that supports 802.1x authentication is connected to the net it must be configured with: –the IP address or DNS name of its RADIUS server. –It must also have a shared secret with the RADIUS Server which is typically hand configured. –Finally, the AP must be registered with the DNS server, or assigned a permanent IP address. –This name or address must also configured in the RADIUS Server.

4. doc.: IEEE 802.11-02/516r0-I Submission September 2002 Robert Moskowitz, ICSALabsSlide 4 What is wrong with this picture? Setting up the RADIUS Client shared secret –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. This is done manually on the RADIUS Client and Server

5. doc.: IEEE 802.11-02/516r0-I Submission September 2002 Robert Moskowitz, ICSALabsSlide 5 More Wrongness The IP address of the AP MUST be fixed –No DHCP, or use MAC controlled DHCP Same IP address always assigned to a given MAC –Or APs DNS name available DYNDNS required? No mechanism to easily rekey MANY RADIUS Clients Only the single AP with built-in RADIUS will NOT be challenged

6. doc.: IEEE 802.11-02/516r0-I Submission September 2002 Robert Moskowitz, ICSALabsSlide 6 How to fix this Kickstart a Master Secret between the AP and RADIUS Server using a guarded (e.g. SKIP) Diffie-Hellman exchange. RFC 2786 is the model –Diffie-Hellman USM Key -- SNMPv3 Key ignition –Secret is bound to APs name, i.e. BSSID AP Boot Registration –Master Secret used to establish a Boot secret bound to the APs IP address This is the RADIUS Client Shared Secret This can also plumb the 802.11f RADIUS keys

7. doc.: IEEE 802.11-02/516r0-I Submission September 2002 Robert Moskowitz, ICSALabsSlide 7 How to fix this Master Secret Change using Diffie-Hellman for Perfect Forward Secrecy –See RFC 2786 -- Key Changes –A Key Change forces a Boot Registration

8. doc.: IEEE 802.11-02/516r0-I Submission September 2002 Robert Moskowitz, ICSALabsSlide 8 Benefits No User configuration on APs –No user interface on APs Manageability of RADIUS Client secrets Support for DHCP address assignment for APs

9. doc.: IEEE 802.11-02/516r0-I Submission September 2002 Robert Moskowitz, ICSALabsSlide 9 General Approach Proposal Kickstart design using Diffie-Hellman over SNMPv2 –Controlled by MIBs (e.g. only possible in factory state) AP Boot Registration using keywrapping over RADIUS without RADIUS authentication Secret Change using Diffie-Hellman with old Diffie-Hellman (like SKIP PFS) over SNMPv2

10. doc.: IEEE 802.11-02/516r0-I Submission September 2002 Robert Moskowitz, ICSALabsSlide 10 Where will work get done IETF –Individual(s) submission -- No RADIUS workgroup Looking for community of interest Referenced by 802.1x Annex D