3. Packet Format

Packet Format

Exactly one RADIUS packet is encapsulated in the UDP Data field [4], where the UDP Destination Port field indicates 1812 (decimal).

When a reply is generated, the source and destination ports are reversed.

This memo documents the RADIUS protocol. The early deployment of RADIUS was done using UDP port number 1645, which conflicts with the "datametrics" service. The officially assigned port number for RADIUS is 1812.

A summary of the RADIUS data format is shown below. The fields are transmitted from left to right.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Code

  The Code field is one octet, and identifies the type of RADIUS
  packet.  When a packet is received with an invalid Code field, it
  is silently discarded.

  RADIUS Codes (decimal) are assigned as follows:

    1       Access-Request
    2       Access-Accept
    3       Access-Reject
    4       Accounting-Request
    5       Accounting-Response
   11       Access-Challenge
   12       Status-Server (experimental)
   13       Status-Client (experimental)
  255       Reserved

Codes 4 and 5 are covered in the RADIUS Accounting document [5]. Codes 12 and 13 are reserved for possible use, but are not further mentioned here.

Identifier

  The Identifier field is one octet, and aids in matching requests
  and replies.  The RADIUS server can detect a duplicate request if
  it has the same client source IP address and source UDP port and
  Identifier within a short span of time.

Length

  The Length field is two octets.  It indicates the length of the
  packet including the Code, Identifier, Length, Authenticator and
  Attribute fields.  Octets outside the range of the Length field
  MUST be treated as padding and ignored on reception.  If the
  packet is shorter than the Length field indicates, it MUST be
  silently discarded.  The minimum length is 20 and maximum length
  is 4096.

Authenticator

  The Authenticator field is sixteen (16) octets.  The most
  significant octet is transmitted first.  This value is used to
  authenticate the reply from the RADIUS server, and is used in the
  password hiding algorithm.

  Request Authenticator

     In Access-Request Packets, the Authenticator value is a 16
     octet random number, called the Request Authenticator.  The
     value SHOULD be unpredictable and unique over the lifetime of a
     secret (the password shared between the client and the RADIUS
     server), since repetition of a request value in conjunction
     with the same secret would permit an attacker to reply with a
     previously intercepted response.  Since it is expected that the
     same secret MAY be used to authenticate with servers in
     disparate geographic regions, the Request Authenticator field
     SHOULD exhibit global and temporal uniqueness.

     The Request Authenticator value in an Access-Request packet
     SHOULD also be unpredictable, lest an attacker trick a server
     into responding to a predicted future request, and then use the
     response to masquerade as that server to a future Access-
     Request.

     Although protocols such as RADIUS are incapable of protecting
     against theft of an authenticated session via realtime active
     wiretapping attacks, generation of unique unpredictable
     requests can protect against a wide range of active attacks
     against authentication.

     The NAS and RADIUS server share a secret.  That shared secret
     followed by the Request Authenticator is put through a one-way
     MD5 hash to create a 16 octet digest value which is xored with
     the password entered by the user, and the xored result placed

in the User-Password attribute in the Access-Request packet. See the entry for User-Password in the section on Attributes for a more detailed description.

  Response Authenticator

     The value of the Authenticator field in Access-Accept, Access-
     Reject, and Access-Challenge packets is called the Response
     Authenticator, and contains a one-way MD5 hash calculated over
     a stream of octets consisting of: the RADIUS packet, beginning
     with the Code field, including the Identifier, the Length, the
     Request Authenticator field from the Access-Request packet, and
     the response Attributes, followed by the shared secret.  That
     is, ResponseAuth =
     MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
     denotes concatenation.

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.

  When using a forwarding proxy, the proxy must be able to alter the
  packet as it passes through in each direction - when the proxy
  forwards the request, the proxy MAY add a Proxy-State Attribute,
  and when the proxy forwards a response, it MUST remove its Proxy-
  State Attribute if it added one.  Proxy-State is always added or
  removed after any other Proxy-States, but no other assumptions
  regarding its location within the list of attributes can be made.
  Since Access-Accept and Access-Reject replies are authenticated on
  the entire packet contents, the stripping of the Proxy-State
  attribute invalidates the signature in the packet - so the proxy
  has to re-sign it.

  Further details of RADIUS proxy implementation are outside the
  scope of this document.