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]