RADIUS Client Kickstart

1
RADIUS Client Kickstart

• Robert Moskowitz, ICSALabs
• John Vollbrecht, Interlink Networks

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
Stated Simply

• When an device 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 device 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
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
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 devices DNS name available
• DYNDNS required?
• No mechanism to easily rekey MANY RADIUS Clients
• Only the single device with built-in EAP/RADIUS
  will NOT be challenged

6
How to fix this

• Kickstart a Master Secret, using SNMPv2, between
  the device and RADIUS Server using a
  Diffie-Hellman exchange with Nonces.
• Secret is bound to devices name, i.e. an APs
  BSSID
• 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(Secret,
  Server_IPSaddressNonce)
• The Master secret is HMAC-SHA1(Kij,
  Client_NonceServer_Nonce)

7
How to fix this

• Master Secret used to establish a the RADIUS
  Client Secret bound to the devices IP address
• RADIUS used for the exchange without RADIUS
  authentication
• This can also plumb other secrets, i.e. the
  802.11f RADIUS keys
• Master Secret Change using Diffie-Hellman with
  nonces for Perfect Forward Secrecy
• A Key Change forces a Boot Registration

8
Benefits

• No User configuration on Devices
• No user interface on Devices
• Manageability of RADIUS Client secrets
• Support for DHCP address assignment for Devices

9
Where will work get done

• IETF
• Individual(s) submission -- No RADIUS workgroup
• draft-ietf-moskowitz-RADIUS-Client-Kickstart-00.tx
  t
• Looking for community of interest
• Referenced by 802.1x Annex D