RADIUS ( Remote Authentication Dial-In User Service )

• Client/Server Model
  A Network Access Server (NAS) operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response which is returned.



• network Security
  Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server, to eliminate the possibility that someone snooping on an unsecure network could determine a user's password.



• Flexible Authentication Mechanisms
  The RADIUS server can support a variety of methods to authenticate a user. When it is provided with the user name and original password given by the user, it can support PPP PAP or CHAP, UNIX login, and other authentication mechanisms.



• Extensible ProtocolM
  All transactions are comprised of variable length Attribute- Length-Value 3-tuples. New attribute values can be added without disturbing existing implementations of the protocol.

• Challenge/Response
  In challenge/response authentication, the user is given an unpredictable number and challenged to encrypt it and give back the result. Authorized users are equipped with special devices such as smart cards or software that facilitate calculation of the correct response with ease. Unauthorized users, lacking the appropriate device or software and lacking knowledge of the secret key necessary to emulate such a device or software, can only guess at the response.



• Interoperation with PAP and CHAP
  For PAP, the NAS takes the PAP ID and password and sends them in an Access-Request packet as the User-Name and User-Password. The NAS MAY include the Attributes Service-Type = Framed-User and Framed-Protocol = PPP as a hint to the RADIUS server that PPP service is expected.
  For CHAP, the NAS generates a random challenge (preferably 16 octets) and sends it to the user, who returns a CHAP response along with a CHAP ID and CHAP username. The NAS then sends an Access-Request packet to the RADIUS server with the CHAP username as the User-Name and with the CHAP ID and CHAP response as the CHAP-Password.



• Proxy
  With proxy RADIUS, one RADIUS server receives an authentication (or accounting) request from a RADIUS client (such as a NAS), forwards the request to a remote RADIUS server, receives the reply from the remote server, and sends that reply to the client, possibly with changes to reflect local administrative policy. A common use for proxy RADIUS is roaming. Roaming permits two or more administrative entities to allow each other's users to dial in to either entity's network for service.



• Why UDP?
  A frequently asked question is why RADIUS uses UDP instead of TCP as a transport protocol. UDP was chosen for strictly technical reasons.
  RADIUS is a transaction based protocol which has several interesting characteristics:
  
  • A copy of the request must be kept above the transport layer to allow for alternate transmission.
  
  
  • The timing requirements of this particular protocol are significantly different than TCP provides.
  
  
  • The stateless nature of this protocol simplifies the use of UDP.
  
  
  • UDP simplifies the server implementation.
  
  
  
• Retransmission Hints
  If the RADIUS server and alternate RADIUS server share the same shared secret, it is OK to retransmit the packet to the alternate RADIUS server with the same ID and Request Authenticator, because the content of the attributes haven't changed. If you want to use a new Request Authenticator when sending to the alternate server, you may.



• Keep-Alives Considered Harmful
  Some implementers have adopted the practice of sending test RADIUS requests to see if a server is alive. This practice is strongly discouraged, since it adds to load and harms scalability without providing any additional useful information. Since a RADIUS request is contained in a single datagram, in the time it would take you to send a ping you could just send the RADIUS request, and getting a reply tells you that the RADIUS server is up.

• Code
  8 bits. Identifies the type of RADIUS packet. If a packet is received with an invalid Code field, it is silently discarded.



Code	Description	References
1	Access-Request.	Access-Accept packets are sent by the RADIUS server, and provide specific configuration information necessary to begin delivery of service to the user.
2	Access-Accept.	The Identifier field is a copy of the Identifier field of the Access-Request which caused this Access-Accept.
3	Access-Reject.	If any value of the received Attributes is not acceptable, then the RADIUS server MUST transmit a packet with the Code field set to 3 (Access-Reject)
4	Accounting-Request.	Accounting-Request packets are sent from a client to a RADIUS accounting server, and convey information used to provide accounting for a service provided to a user.
5	Accounting-Response.	It is sent by the RADIUS accounting server to the client to acknowledge that the Accounting-Request has been received and recorded successfully.
6	Accounting-Status, Interim Accounting.	A RADIUS server issues an Access-Accept in response to a successful Access-Request.
7	Password-Request.
8	Password-Ack.
9	Password-Reject.
10	Accounting-Message
11	Access-Challenge.	If the RADIUS server desires to send the user a challenge requiring a response, then the RADIUS server MUST respond to the Access-Request by transmitting a packet with the Code field set to 11 (Access-Challenge).
12	Status-Server (experimental).
13	Status-Client (experimental).
14 - 20
21	Resource-Free-Request
22	Resource-Free-Response
23	Resource-Query-Request.
24	Resource-Query-Response
25	Alternate-Resource- Reclaim-Request.
26	NAS-Reboot-Request
27	NAS-Reboot-Response
28
29	Next-Passcode.
30	New-Pin.
31	Terminate-Session.
32	Password-Expired.
33	Event-Request.
34	Event-Response.
35 - 39
40	Disconnect-Request.
41	Disconnect-ACK.
42	Disconnect-NAK.
43	CoA-Request.
44	CoA-ACK.
45	CoA-NAK.
46 - 49
50	IP-Address-Allocate.
51	IP-Address-Release.
52 - 249
250 - 253	Experimental use.
254	Reserved.
255	Reserved.



• Identifier
  8 bits. Used to match RADIUS request and reply packets.



• Length
  16 bits. 20 to 4096. Indicates the length of the packet including the RADIUS header and Attribute fields. Bytes outside the range of the Length field should be treated as padding and should be ignored on reception. If the packet is shorter than the indicated length, it should be silently discarded.



• Authenticator
  16 bytes. Used to authenticate the reply from the RADIUS server and is used in the password hiding algorithm.



• Attributes
  Variable length. RADIUS Attributes carry the specific authentication, authorization and accounting details for the request and response. Some attributes MAY be included more than once. The effect of this is attribute specific, and is specified in each attribute description. The end of the list of attributes is indicated by the Length of the RADIUS packet.



8	16	32bit
Type	Length	Value



• Type
  8 bits.



• Length
  8 bits. Indicates the length of this attribute including the Type, Length and Value fields. If an attribute is received in an Accounting-Request packet with an invalid Length, the entire request should be silently discarded.



• Value
  Variable length. Contains information specific to the attribute. The format and length of this field is determined by the Type and Length fields. The format of the field can be one of the following data types:
  
  • String: 0 to 253 bytes.
  
  
  • Address: 32 bits, MSB.
  
  
  • Integer: 32 bits, MSB.
  
  
  • Time: 32 bits. seconds since 00:00:00 GMT, January 1, 1970.



• The valid attributes:
  

  Type	Length	Description	References
  1	>= 3	User-Name.	The name of the user to be authenticated. It MUST be sent in Access-Request packets if available.
  2	18 to 130	User-Password.	The password is first padded at the end with nulls to a multiple of 16 octets.
  3	19	CHAP-Password.	The response value provided by a PPP Challenge-Handshake Authentication Protocol (CHAP) user in response to the challenge.
  4	6	NAS-IP-Address.	The identifying IP Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server.
  5	6	NAS-Port.	The physical port number of the NAS which is authenticating the user.
  6	6	Service-Type.	The type of service the user has requested, or the type of service to be provided.
  7	6	Framed-Protocol.	The framing to be used for framed access. It MAY be used in both Access-Request and Access-Accept packets.
  8	6	Framed-IP-Address.	The address to be configured for the user.
  9	6	Framed-IP-Netmask.	The IP netmask to be configured for the user when the user is a router to a network. It MAY be used in Access-Accept packets.
  10	6	Framed-Routing.	The routing method for the user, when the user is a router to a network.
  11	>= 3	Filter-Id.	The name of the filter list for this user. Zero or more Filter-Id attributes MAY be sent in an Access-Accept packet.
  12	6	Framed-MTU.	The Maximum Transmission Unit to be configured for the user, when it is not negotiated by some other means (such as PPP).
  13	6	Framed-Compression.	A compression protocol to be used for the link. It MAY be used in Access-Accept packets.
  14	6	Login-IP-Host.	The system with which to connect the user, when the Login-Service Attribute is included. It MAY be used in Access-Accept packets.
  15	6	Login-Service.	The service to use to connect the user to the login host.
  16	6	Login-TCP-Port.	The TCP port with which the user is to be connected, when the Login-Service Attribute is also present.
  17
  18	>= 3	Reply-Message.	The text which MAY be displayed to the user.
  19	>= 3	Callback-Number.	A dialing string to be used for callback. It MAY be used in Access-Accept packets.
  20	>= 3	Callback-Id.	The name of a place to be called, to be interpreted by the NAS.
  21
  22	>= 3	Framed-Route.	Provides routing information to be configured for the user on the NAS.
  23	6	Framed-IPX-Network.	The IPX Network number to be configured for the user.
  24	>= 3	State.	It is sent by the server to the client in an Access-Challenge and MUST be sent unmodified from the client to the server in the new Access-Request reply to that challenge.
  25	>= 3	Class.	It is sent by the server to the client in a Access-Accept and SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported.
  26	>= 7	Vendor-Specific.	Allow vendors to support their own extended Attributes not suitable for general usage.
  27	6	Session-Timeout.	The maximum number of seconds of service to be provided to the user before termination of the session or prompt.
  28	6	Idle-Timeout.	The maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt.
  29	6	Termination-Action.	What action the NAS should take when the specified service is completed.
  30	>= 3	Called-Station-Id.	Allows the NAS to send in the Access-Request packet the phone number that the user called.
  31	>= 3	Calling-Station-Id.	Allows the NAS to send in the Access-Request packet the phone number that the call came from.
  32	>= 3	NAS-Identifier.	A string identifying the NAS originating the Access-Request.
  33	>= 3	Proxy-State.	It is sent by a proxy server to another server when forwarding an Access-Request and MUST be returned unmodified in the Access-Accept, Access-Reject or Access-Challenge.
  34	>= 3	Login-LAT-Service.	The system with which the user is to be connected by LAT.
  35	>= 3	Login-LAT-Node.	The Node with which the user is to be automatically connected by LAT.
  36	34	Login-LAT-Group.	A string identifying the LAT group codes which this user is authorized to use.
  37	6	Framed-AppleTalk-Link.	The AppleTalk network number which should be used for the serial link to the user.
  38	6	Framed-AppleTalk-Network.	The AppleTalk Network number which the NAS should probe to allocate an AppleTalk node for the user.
  39	>= 3	Framed-AppleTalk-Zone.	The AppleTalk Default Zone to be used for this user.
  40	6	Acct-Status-Type.
  41	6	Acct-Delay-Time.
  42	6	Acct-Input-Octets.
  43	6	Acct-Output-Octets.
  44	>= 3	Acct-Session-Id
  45	6	Acct-Authentic.
  46	6	Acct-Session-Time.
  47	6	Acct-Input-Packets.
  48	6	Acct-Output-Packets.
  49	6	Acct-Terminate-Cause.
  50	>= 3	Acct-Multi-Session-Id.
  51	6	Acct-Link-Count.
  52	6	Acct-Input-Gigawords.	The times the Acct-Input-Octets counter has wrapped around 2-32 over the course of this service being provided.
  53	6	Acct-Output-Gigawords.	The times the Acct-Output-Octets counter has wrapped around 2-32 in the course of delivering this service.
  54
  55	6	Event-Timestamp.	The Accounting-Request packet to record the time that this event occurred on the NAS
  56 - 59
  60	>= 7	CHAP-Challenge.	The CHAP Challenge sent by the NAS to a PPP Challenge-Handshake Authentication Protocol (CHAP) user.
  61	6	NAS-Port-Type.	The type of the physical port of the NAS which is authenticating the user.
  62	6	Port-Limit.	The maximum number of ports to be provided to the user by the NAS.
  63	>= 3	Login-LAT-Port.	The Port with which the user is to be connected by LAT.
  64	6	Tunnel-Type.	The tunneling protocol(s) to be used or the tunneling protocol in use.
  65	6	Tunnel-Medium-Type.	The transport medium to use when creating a tunnel for those protocols.
  66	>= 3	Tunnel-Client-Endpoint.	The address of the initiator end of the tunnel.
  67	>= 3	Tunnel-Server-Endpoint.	The address of the server end of the tunnel.
  68		Acct-Tunnel-Connection.
  69	>= 5	Tunnel-Password.	The password is used to authenticate to a remote server.
  70	18	ARAP-Password.	It is present in an Access-Request packet containing a Framed-Protocol of ARAP.
  71	16	ARAP-Features.	It is sent in an Access-Accept packet with Framed- Protocol of ARAP, and includes password information that the NAS should sent to the user in an ARAP "feature flags" packet.
  72	6	ARAP-Zone-Access.	How the ARAP zone list for the user should be used.
  73	6	ARAP-Security.	The ARAP Security Module to be used in an Access-Challenge packet.
  74	>= 3	ARAP-Security-Data.	The actual security module challenge or response
  75	6	Password-Retry.	The times of authentication attempts a user may be allowed to attempt before being disconnected.
  76	6	Prompt.	The NAS whether it should echo the user's response as it is entered, or not echo it.
  77	>= 3	Connect-Info.	The nature of the user's connection.
  78	>= 3	Configuration-Token.	Use in large distributed authentication networks based on proxy.
  79	>= 3	EAP-Message.	Allow the NAS to authenticate dial-in users via EAP without having to understand the EAP protocol.
  80	18	Message-Authenticator.	Sign Access-Requests to prevent spoofing Access-Requests using CHAP, ARAP or EAP authentication methods.
  81	>= 3	Tunnel-Private-Group-ID.	The group ID for a particular tunneled session.
  82	>= 3	Tunnel-Assignment-ID.	The tunnel initiator the particular tunnel to which a session is to be assigned.
  83	6	Tunnel-Preference.	The relative preference assigned to each tunnel if more than one set of tunneling attributes is returned by the RADIUS server to the tunnel initiator.
  84	10	ARAP-Challenge-Response.	It is sent in an Access-Accept packet with Framed- Protocol of ARAP, and contains the response to the dial-in client's challenge.
  85	6	Acct-Interim-Interval.	The number of seconds between each interim update in seconds for this specific session.
  86		Acct-Tunnel-Packets-Lost.
  87	>= 3	NAS-Port-Id.	A text string which identifies the port of the NAS which is authenticating the user.
  88	>= 3	Framed-Pool.	The name of an assigned address pool that SHOULD be used to assign an address for the user.
  89
  90	>= 3	Tunnel-Client-Auth-ID.	The name used by the tunnel initiator during the authentication phase of tunnel establishment.
  91	>= 3	Tunnel-Server-Auth-ID.	The name used by the tunnel terminator during the authentication phase of tunnel establishment.
  92 93
  94		Originating-Line-Info.
  95	18	NAS-IPv6-Address.	The identifying IPv6 Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server.
  96	10	Framed-Interface-Id.	The IPv6 interface identifier to be configured for the user.
  97	4 to 20	Framed-IPv6-Prefix.	The IPv6 prefix to be configured for the user.
  98	18	Login-IPv6-Host.	The system with which to connect the user, when the Login-Service Attribute is included.
  99	>= 3	Framed-IPv6-Route.	Routing information to be configured for the user on the NAS.
  100	>= 3	Framed-IPv6-Pool.	The name of an assigned pool that SHOULD be used to assign an IPv6 prefix for the user.
  101		Error-Cause Attribute.
  102 - 191
  192 - 223		Experimental.
  224 - 240		Implementation specific.
  241 - 255		Reserved.

• Access-Request
  Access-Request packets are sent to a RADIUS server, and convey information used to determine whether a user is allowed access to a specific NAS, and any special services requested for that user. An implementation wishing to authenticate a user MUST transmit a RADIUS packet with the Code field set to 1 (Access-Request).
  An Access-Request SHOULD contain a User-Name attribute. It MUST contain either a NAS-IP-Address attribute or a NAS-Identifier attribute (or both).



• Access-Accept
  Access-Accept packets are sent by the RADIUS server, and provide specific configuration information necessary to begin delivery of service to the user. If all Attribute values received in an Access-Request are acceptable then the RADIUS implementation MUST transmit a packet with the Code field set to 2 (Access-Accept).



• Access-Reject
  If any value of the received Attributes is not acceptable, then the RADIUS server MUST transmit a packet with the Code field set to 3 (Access-Reject). It MAY include one or more Reply-Message Attributes with a text message which the NAS MAY display to the user.



• Access-Challenge
  If the RADIUS server desires to send the user a challenge requiring a response, then the RADIUS server MUST respond to the Access-Request by transmitting a packet with the Code field set to 11 (Access-Challenge).
  The Attributes field MAY have one or more Reply-Message Attributes, and MAY have a single State Attribute, or none. Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State attributes MAY also be included. No other Attributes defined in this document are permitted in an Access-Challenge.

Example 1: User Telnet to Specified Host



The NAS at 192.168.1.16 sends an Access-Request UDP packet to the RADIUS Server for a 

user named nemo logging in on port 3 with password "arctangent". The Request 

Authenticator is a 16 octet random number generated by the NAS.The User-Password is 16 

octets of password padded at end with nulls, XORed with MD5(shared secret|Request 

Authenticator).



          01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb

          98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d

          93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8

          01 10 05 06 00 00 00 03



           1 Code = Access-Request (1)

           1 ID = 0

           2 Length = 56

          16 Request Authenticator



          Attributes:

           6  User-Name = "nemo"

          18  User-Password

           6  NAS-IP-Address = 192.168.1.16

           6  NAS-Port = 3



The RADIUS server authenticates nemo, and sends an Access-Accept UDP packet to the 

NAS telling it to telnet nemo to host 192.168.1.3.



The Response Authenticator is a 16-octet MD5 checksum of the code (2), id (0), Length 

(38), the Request Authenticator from above, the attributes in this reply, and the 

shared secret.



          02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf

          9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00

          0e 06 c0 a8 01 03



           1 Code = Access-Accept (2)

           1 ID = 0 (same as in Access-Request)

           2 Length = 38

          16 Response Authenticator



          Attributes:

           6  Service-Type (6) = Login (1)

           6  Login-Service (15) = Telnet (0)

           6  Login-IP-Host (14) = 192.168.1.3

Example 2: Framed User Authenticating with CHAP



The NAS at 192.168.1.16 sends an Access-Request UDP packet to the RADIUS Server for a 

user named flopsy logging in on port 20 with PPP, authenticating using CHAP. The NAS 

sends along the Service-Type and Framed-Protocol attributes as a hint to the RADIUS 

server that this user is looking for PPP, although the NAS is not required to do so.



The Request Authenticator is a 16 octet random number generated by the NAS, and is 

also used as the CHAP Challenge.The CHAP-Password consists of a 1 octet CHAP ID, in 

this case 22, followed by the 16 octet CHAP response.



          01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e

          0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9

          75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04

          06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00

          02 07 06 00 00 00 01



           1 Code = 1     (Access-Request)

           1 ID = 1

           2 Length = 71

          16 Request Authenticator



          Attributes:

           8  User-Name (1) = "flopsy"

          19  CHAP-Password (3)

           6  NAS-IP-Address (4) = 192.168.1.16

           6  NAS-Port (5) = 20

           6  Service-Type (6) = Framed (2)

           6  Framed-Protocol (7) = PPP (1)



The RADIUS server authenticates flopsy, and sends an Access-Accept UDP packet to the 

NAS telling it to start PPP service and assign an address for the user out of its 

dynamic address pool.



The Response Authenticator is a 16-octet MD5 checksum of the code (2), id (1), Length 

(56), the Request Authenticator from above, the attributes in this reply, and the 

shared secret.



          02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0

          3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01

          08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00

          00 01 0c 06 00 00 05 dc



           1 Code = Access-Accept (2)

           1 ID = 1 (same as in Access-Request)

           2 Length = 56

          16 Response Authenticator



          Attributes:

           6  Service-Type (6) = Framed (2)

           6  Framed-Protocol (7) = PPP (1)

           6  Framed-IP-Address (8) = 255.255.255.254

           6  Framed-Routing (10) = None (0)

           6  Framed-Compression (13) = VJ TCP/IP Header Compression (1)

           6  Framed-MTU (12) = 1500

Example 3: User with Challenge-Response card



The NAS at 192.168.1.16 sends an Access-Request UDP packet to the RADIUS Server for 

a user named mopsy logging in on port 7. The user enters the dummy password "challenge" 

in this example. The challenge and response generated by the smart card for this 

example are "32769430" and "99101462".



The Request Authenticator is a 16 octet random number generated by the NAS.



The User-Password is 16 octets of password, in this case "challenge", padded at the 

end with nulls, XORed with MD5(shared secret|Request Authenticator).



          01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9

          30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75

          73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0

          a8 01 10 05 06 00 00 00 07

           1 Code = Access-Request (1)

           1 ID = 2

           2 Length = 57

          16 Request Authenticator



          Attributes:

           7 User-Name (1) = "mopsy"

          18 User-Password (2)

           6  NAS-IP-Address (4) = 192.168.1.16

           6  NAS-Port (5) = 7



The RADIUS server decides to challenge mopsy, sending back a challenge string and 

looking for a response. The RADIUS server therefore and sends an Access-Challenge 

UDP packet to the NAS.



The Response Authenticator is a 16-octet MD5 checksum of the code (11), id (2), 

length (78), the Request Authenticator from above, the attributes in this reply, and 

the shared secret.



The Reply-Message is "Challenge 32769430.  Enter response at prompt."



The State is a magic cookie to be returned along with user's response; in this example 

8 octets of data (33 32 37 36 39 34 33 30 in hex).



      0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c

      71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20

      33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72

      20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f

      6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30



       1 Code = Access-Challenge (11)

       1 ID = 2 (same as in Access-Request)

       2 Length = 78

      16 Response Authenticator



      Attributes:

      48  Reply-Message (18)

      10  State (24)



The user enters his response, and the NAS send a new Access-Request with that 

response, and includes the State Attribute.



The Request Authenticator is a new 16 octet random number.



The User-Password is 16 octets of the user's response, in this case "99101462", padded 

at the end with nulls, XORed with MD5(shared secret|Request Authenticator). The state 

is the magic cookie from the Access-Challenge packet, unchanged.



          01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07

          c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f

          20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0

          a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39

          34 33 30



           1 Code = Access-Request (1)

           1 ID = 3 (Note that this changes.)

           2 Length = 67

          16 Request Authenticator



          Attributes:

           7  User-Name = "mopsy"

          18  User-Password

           6  NAS-IP-Address (4) = 192.168.1.16

           6  NAS-Port (5) = 7

          10  State (24)



The Response was incorrect (for the sake of example), so the RADIUS server tells the 

NAS to reject the login attempt.



The Response Authenticator is a 16 octet MD5 checksum of the code (3), id (3), 

length(20), the Request Authenticator from above, the attributes in this reply (in this 

case, none), and the shared secret.



          03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f

          9e 74 6a a0



           1 Code = Access-Reject (3)

           1 ID = 3 (same as in Access-Request)

           2 Length = 20

          16 Response Authenticator



          Attributes: (none, although a Reply-Message could be sent)

■ Parent layer
■ Child layer

UDP

RADIUS