1 / 8

RADIUS RFC Data Model

Discover the RADIUS data model through examination of data types, dictionaries, and compound attributes. Learn how compound requests are used for authentication, vendor extensions, and tunneling. Gain insights on popular data types and potential design flaws.

wbauman
Download Presentation

RADIUS RFC Data Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RADIUS RFC Data Model IETF-60 Bernard Aboba

  2. Why Look at the RADIUS Data Model? • To examine what data types have been used so far. • To understand the logic behind this. • To see if there are unmet needs.

  3. What is the RADIUS Dictionary? • The RADIUS dictionary is not defined in any RADIUS RFCs. • The goal of the dictionary is to enable a RADIUS server implementation to add support for new attributes without changing code. • RADIUS client implementations typically do not have a dictionary – since client code always changes to support a new attribute.

  4. What We Looked At • RADIUS RFCs: • RFC 2865-2869 • RFC 3162 • RFC 3576, 3579, 3580 • Spreadsheet of attributes in Access-Request, Challenge, Accept.

  5. Results • Most popular data types: • Unsigned Integer 32 (UINT32) [41] • String [23] • Text [13] • IPv4-Address [4] • IPv6-Address [2] • UINT64 [2]

  6. Compound Data Types • CHAP-Password (CHAP Ident + String) • Vendor-Specific (Vendor-Id + String) • Tunnel attributes • Tunnel-Client-Endpoint (Tag + String) • Tunnel-Server-Endpoint (Tag + String) • Tunnel-Password (Tag + Salt + String) • Tunnel-Private-Group-ID (Tag + String) • Tunnel-Assignment-ID (Tag + String) • Tunnel-Client-Auth-ID (Tag + String) • Tunnel-Server-Auth-ID (Tag + String) • ARAP-Password (4 * UINT32) • ARAP-Features (2 * 1B + 3 * UINT32) • Framed-IPv6-Prefix (2 * 1B + UINT64)

  7. Some Observations • Compound data types sent by the Server to the Client are equivalent to a String • User can enter hex string into the dictionary • No code change required • Compound data types sent by the Client to the Server require server parsing, code changes • Tunnel attributes, Framed-IPv6-Prefix • ARAP-Password, CHAP-Password, EAP-Message • Vendor-Specific

  8. Conclusion • RADIUS RFCs have only 4 fundamental data types: UINT32, UINT64, String, Text • String type allows users to add arbitrary attributes to the Server Dictionary • Compound Requests used for authentication, vendor-extensions, tunneling. • Tunnel attribute “tagging” awkward at best • Framed-IPv6-Prefix design probably a mistake

More Related