Remote Authentication Dial‑In User Service, commonly known as RADIUS, is an enduringly popular AAA (Authentication, Authorization, Accounting) protocol used across Wi‑Fi, VPNs, NAS devices, and even in IoT and automotive networking systems. Although Diameter is the newer, more extensible AAA protocol, RADIUS remains widely supported and deployed, especially in environments that value interoperability, simplicity, and incremental upgrades.

Security teams, penetration testers, and device manufacturers must ensure that their RADIUS‑capable systems are hardened against attacks like buffer overflows, malformed packet exploits, replay attacks, and logic violations. This is where RADIUS fuzzing, dynamic analysis, and tools like Penzzer play key roles, particularly when aiming for ISO/SAE 21434 compliance or rigorous automotive cybersecurity readiness.

What Is RADIUS?

At a high level, RADIUS is a client/server protocol where network access servers (NAS), such as wireless controllers, VPN gateways, and routers, act as clients. They send requests to a centralized RADIUS server to authenticate, authorize, and account for users or devices.

• Authentication: Validate user credentials (user‑password, MS‑CHAPv2, EAP methods).
• Authorization: Enforce granular policies such as VLAN assignment, bandwidth limits, or service permits.
• Accounting: Log session start/end/time, input/output octets, service type, etc., often for billing or auditing.

‍

Why It Matters in 2025

• IoT security: Many connected sensors, cameras, or smart locks include RADIUS clients to integrate into enterprise access control.
• Automotive cybersecurity: Modern vehicles leverage Wi‑Fi or LTE gateways tied into enterprise VPNs or cloud backends, some using RADIUS to authenticate components or technicians, mandating robust testing for ISO/SAE 21434 compliance.
• Pen‑testing tools: Effective security assessments must evaluate RADIUS both server and client implementations to rule out exploitation paths.
• Dynamic fuzzing: Automated, parameter‑aware generators that mutate RADIUS attribute fields and deliver high‑coverage stress tests across the protocol surface.

‍

Relevant RFCs (Protocol Specifications)

RADIUS has evolved through multiple RFCs—each adding capabilities, clarifications, or new attribute types:

1. RFC 2865 (June 2000) - Remote Authentication Dial-in User Service (RADIUS)
   The core specification: packet types, ADT, AVP format, the MD5-based message authentication mechanism.
2. RFC 2866 (June 2000) - RADIUS Accounting
   Introduces ACCT‑REQ/RESP, logging attributes like Acct‑Delay‑Time, Input‑Octets, and Output‑Octets.
3. RFC 2867 (June 2000) - RADIUS Tunnel Accounting
   Defines fields for tunnel usage (Tunnel‑Type, Tunnel‑Medium‑Type, Tunnel‐Private‑Group‑ID).
4. RFC 2868 (June 2000) - RADIUS Attributes for Tunnel Protocol Support
   Adds Tunnel‑Password, Tunnel‑Client‑Endpoint, etc.
5. RFC 2869 (June 2000) - Extended RADIUS (Radius Extensions)
   Adds new packet types like Accounting‑On and new attribute ranges.
6. RFC 3579 (September 2003) - RADIUS Extensible Authentication Protocol (EAP) Transport
   Defines EAP‑Message support.
7. RFC 5176 (March 2008) - Dynamic Authorization Extensions (CoA and Disconnect‑Request)
   Enables real‑time session control.
8. RFC 6613 (May 2012) - Dynamic Authorization Extensions Update
9. RFC 6929 (April 2013) - Multiple Session‑ID Support‍

‍

RADIUS Packets: Types, Structures, Attributes

Packet Header (20 bytes)

Every RADIUS packet begins with a fixed header:

‍

Common Code values

• 1 = Access‑Request
• 2 = Access‑Accept
• 3 = Access‑Reject
• 4 = Accounting‑Request
• 5 = Accounting‑Response
• 6 = Access‑Challenge
• 7 = Status‑Server
• 8 = Status‑Client
• 16 = Accounting‑On
• 17 = Accounting‑Off
• 43 = Disconnect‑Request (RFC 5176)
• 44 = Disconnect‑ACK
• 45 = Disconnect‑NAK
• 41 = CoA‑Request
• 42 = CoA‑ACK
• 43 = CoA‑NAK

‍

Authenticator Field

• Access‑Request: a Secret‑protected 16-byte random value.
• Access‑Accept/Reject/Challenge: a response authenticator, being an MD5 digest over packet with shared secret.
• Accounting: MD5 of packet + secret (RFC 2866).

‍

Attribute-Value Pairs (AVPs)

AVPs follow the header and are defined as:

• Type: 1 byte
• Length: 1 byte (including the header)
• Value: variable, (Length - 2) bytes

Each attribute must align correctly and fit within Length.

‍

RADIUS Attributes: Field Types & Expected Values

RADIUS supports hundreds of defined attribute types. They can be categorized as:

1. Standard (RFC 2865)
2. Accounting (RFC 2866)
3. Tunnel (RFC 2867/2868)
4. CoA / Dynamic AuthZ (RFC 5176)
5. EAP transport (RFC 3579)
6. Vendor‑Specific Attributes (VSAs) - flexible, extensible.

‍

Highlighted Standard Attributes

‍

This is not exhaustive: VSAs, accounting, and newer attributes extend well beyond.

Value Examples

• Service‑Type (Type=6):
  • 1 = Login‑User
  • 2 = Framed
  • 3 = Callback‑Login
  • 4 = Callback‑Framed
  • ... up to 11 = Admin‑User

‍

• Termination‑Action (Type=26):
  • 1 = default
  • 2 = RADIUS‑Request (CoA‑style session‑management triggers)

‍

• NAS‑Port‑Type (Type=31):
  • 0 = unknown
  • 5 = Ethernet
  • 9 = IEEE 802.11 Wireless

‍

• Tunnel‑Type (Type=64):
  • 1 = P‑P‑T‑P
  • 7 = L2TP
  • ...

‍

Accounting Attributes

Key attributes in accounting (Access‑Request/Response) include:

• Acct‑Status‑Type (Type=40): 1=Request, 2=Start, 3=Stop, 7=Accounting‑On, etc.
• Acct‑Delay‑Time (Type=41): Seconds delay between session start and logging.
• Acct‑Input/Output‑Octets (42/43): Traffic counts (unsigned 32‑bit).
• Acct‑Session‑Time (46): Seconds session lasted.
• Acct‑Multi‑Session‑ID (50): Unique tracking ID per session.

‍

CoA / Dynamic (RFC 5176)

Key packet codes added in RFC 5176:

• Code 43 = Disconnect‑Request
• Code 44 = Disconnect‑ACK
• Code 45 = Disconnect‑NAK
• Code 41 = CoA‑Request
• Code 42 = CoA‑ACK

‍

Common attributes used in CoA:

• Acct‑Session‑ID (44)
• User‑Name (1)
• Framed‑IPAddress (8)
• Event‑Timestamp (55)
• Class (25) - used for session-matching

‍

Vendor‑Specific Attributes (VSAs)

These allow vendors (Cisco, Juniper, Microsoft) to define private AVPs.

Packet structure:

Type = 26
Length = N
Value = | 4‑byte Enterprise‑ID | data… |

Inside data…, structured sub‑fields like sub‑type, length, and data may appear.

‍

Why Fuzz RADIUS?

Fuzzing remains a cornerstone of IoT security testing, especially in automotive and embedded NAS/Wi‑Fi devices

‍

Rarity of Comprehensive Testing

Many firmware stacks implement RADIUS parsing superficially, often with C-based parsing code fraught with:

• Buffer overruns
• Integer overflows
• Null-termination and string misuse
• Missing length validation between nested AVPs

‍

Potential Failure Modes

• Malformed AVP length: crash or memory leak
• Duplicated AVPs: logic bypass or state-confusion
• Chunked EAP messages: error handling misaddressed
• Invalid Vendor‑Specific content: opaque data may include unvalidated offsets
• Replay of dynamic CoA: unauthorized session kill/reset

‍

Crash, Denial‑of‑Service, or Logic Bugs

Commonly found:

• RADIUS server daemons crash due to malformed X attributes
• IoT gateway firmware enters boot loop
• Exposed debug interfaces via malformed EAP messages
• RADIUS failure leads to policy bypass in automotive modules

‍

How RADIUS Fuzzing Works

To fuzz RADIUS, one must simulate the behavior of a malicious or unexpected NAS:

1. Choose packet types: Access‑Request, Accounting‑Request, CoA, Disconnect, etc.
2. Generate parameters: valid AVPs, variable-length fields, EAP chunks.
3. Introduce mutations:
   • Invalid/oversized Length fields
   • Incorrect Type–Length–Value combos
   • Valid but contradictory AVPs
   • CRC/root-level hash manipulations
4. Send to target: server daemon, client stack, VPN gateway, or edge node.
5. Monitor: logs, core dumps, crash analyzer, debug UART.
6. Classify vulnerability: trump crash, DoS, unauthorized access, etc.

‍

Multiple tools support RADIUS fuzzing:

• Scapy‑based scripts
• Penzzer, Peach or Boofuzz
• PyFuzz, radb scripts

Each has limitations, generally, protocol coverage is limited, or integration with dynamic monitoring is manual.

‍

Meet Penzzer: Fuzzing & Pen‑Testing for RADIUS

Penzzer is a next-generation fuzzing and pen‑testing tool that combines:

• Dynamic protocol grammar parsing (helper modules for RADIUS)
• Smart packet generation engines (field-specific, type-aware)
• Crash detection (OSECheck, trace-based coverage)
• Integration into CI/CD (continuous IoT security testing)
• Modular templates (network scans, CoA workflows, JSON-based test sequences)

‍

Why Penzzer?

• Out-of-the-box RADIUS grammar support.
• Plug-and-play integration into RADIUS IoT test rigs.
• Adaptive fuzzing: state-awawre and feedback-driven packet generation to cover deep protocol branches.
• Visibility: per-attribute failure logs, packet trace replay, session re-synthesis.

‍

Penzzer's Feature Highlights

1. Field-aware fuzzing:
   • Numeric fields: boundary integers, negative values.
   • String fields: Unicode, extended-length, nulls.
   • IP address fields: embedded fragmentation.
   • Vendor‑specific nesting: hierarchical mapping.
2. Packet template engine:
   Define full RADIUS templates (Access‑Request + AVPs) that auto-increment Logic IDs to test sequence paths.
3. Protocol chaining:
   After Access‑Accept, automatically step into EAP tunnel negotiation, simulating full user login flows.
4. Server/client support:
   Fuzz both centralized (server/VM) and embedded RADIUS clients in custom IoT/automotive hubs.

‍

Workflow with Penzzer

1. Define baseline test:
   Use template engine to specify standard Access‑Request including credentials, NAS‑IP, Service‑Type, and a couple of VSAs.
2. Enable discovery:
   Penzzer enumerates the DUT (device under test) to discover the full AVP set supported.
3. Execute dynamic fuzz:
   - Numeric: TRY min/max/exhaust boundary for Session‑Timeout, Idle‑Timeout.
   - String: Oversized User‑Name (10 KB), null-injection into Calling‑Station‑ID.
   - Binary: Random bits in Message‑Authenticator, malformed Vendor‑Specific hierarchy.
   - EAP toggle: Zero-length or stuffed EAP‑Message continuation.
4. Monitor target:
   Logs syslog, pcap network traces; detect crashes or hung processes using watchdog integration.
5. Replay failing packets:
   Penzzer automatically queues failed inputs for triage - exports packet dump and re-runnable scripts for root cause work.
6. Generate report:
   Structured output: AVP name, fuzz operator, failure signature, crash stack or logging evidence.

‍

This workflow supports ISO/SAE 21434 compliance because it encourages:

• Documented test cases
• Full test coverage
• Repeatable triage and validation
• Traceability to R&D code
• Log retention and auditing

‍

Automotive Scenario: RADIUS in Vehicle Lifecycle

Many OEMs use RADIUS for vehicle factory setup, OTA update auth, and dealership diagnostics via VPN. These communications must be secure under automotive cybersecurity mandates.

Use Case: Workshop Diagnostics

1. Tech plugs into CAN network in vehicle.
2. Onboard TCU/NAS attempts RADIUS handshake with central authentication server.
3. Successful authentication allows remote diagnostics, security update, or flashing.

‍

Threats

• Malformed AVP crash: blocking workshop connectivity or rolling devices into "safe mode".
• CoA bypass: unauthenticated CoA attack resets session, triggers firmware rollback.
• EAP renegotiation logic abuse: repeated challenge loop disables remote diagnostics.

‍

Penzzer in Automotive Labs

• Environment: Test bench, ECU, TCU with ability to intercept ethernet, CAN bus, serial logs.
• Penzzer variants: Focused on embed stack vs server farm, distinct test parameters.
• Validating: Failures generate compliance reports to satisfy ISO/SAE 21434 auditing.
• Remediation: OEMs fix parsing bugs before production.

‍

IoT Security Testing: Home and Enterprise Landscapes

Home IoT, enterprise printer/NAS, and IVR systems often include built-in, low‑cost RADIUS clients.

Challenges

• RAM-limited embedded C parsers.
• No hardened libraries; lots of manual AVP logic.
• Hard-to-reproduce crash/input vectors.

‍

Penzzer’s Role

1. Boot target with system health and monitoring hooks.
2. Fuzz Access‑Request, Accounting‑Requests, CoA.
3. Capture abnormal logs or preserve corrupted state for further analysis.

‍

This form of IoT security testing is essential to raise security bar across broad device categories, not just automotive or enterprise.

‍

Defensive Guides: Hardening RADIUS Implementations

Even beyond testing, RADIUS setups should follow best practices:

1. Access‑Control:
   Only allow authorized source IPs and clients; restrict CoA endpoints.
2. Secret management:
   Ensure strong shared secrets; rotate regularly.
3. MS‑CHAPv2/EAP:
   Use MS‑CHAPv2 with strong hashing or migrate to EAP‑TLS.
4. Logging:
   Full AVP content logs, crash dumps, packet traces.
5. Patch promptly:
   Follow CVE sources; patch FreeRADIUS, libfreeradius, embedded stacks.
6. Monitor for abnormal traffic:
   Unexpected packet types, oversized AVPs, or On‑The‑Fly CoA attempts.