RADIUS Client Kickstart September 2002 RADIUS Client Kickstart Robert Moskowitz, ICSALabs John Vollbrecht, Interlink Networks Robert Moskowitz, ICSALabs

Houston, we have a problem September 2002 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.” Robert Moskowitz, ICSALabs

September 2002 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. Robert Moskowitz, ICSALabs

What is wrong with this picture? September 2002 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 Robert Moskowitz, ICSALabs

More Wrongness The IP address of the AP MUST be fixed September 2002 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 AP’s 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 Robert Moskowitz, ICSALabs

September 2002 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 AP’s name, i.e. BSSID AP Boot Registration Master Secret used to establish a Boot secret bound to the AP’s IP address This is the RADIUS Client Shared Secret This can also ‘plumb’ the 802.11f RADIUS keys Robert Moskowitz, ICSALabs

September 2002 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 Robert Moskowitz, ICSALabs

Benefits No User configuration on APs September 2002 Benefits No User configuration on APs No user interface on APs Manageability of RADIUS Client secrets Support for DHCP address assignment for APs Robert Moskowitz, ICSALabs

General Approach Proposal September 2002 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 Robert Moskowitz, ICSALabs

Where will work get done September 2002 Where will work get done IETF Individual(s) submission -- No RADIUS workgroup Looking for community of interest Referenced by 802.1x Annex D Robert Moskowitz, ICSALabs