Overview, details and analysis of Radius protocol

Jaakko Tuomimki Helsinki University of Technology Telecommunications Software and Multimedia Laboratory May 28, 2003

Abstract This document is an overview to Remote Authentication Dial In User Service protocol, the RADIUS. RADIUS is protocol that enables Network Access Server to use shared authentication server for user authentication and authorization. In this document RADIUS authentication procedure is described and some features examined in more detail. This paper is, as name implies, mainly an overview of RADIUS protocol. Although some details of the RADIUS are studied, the main focus is not in the details. For those readers wanting more details about specic information, the references are suggested. Although this paper contains some analysis of RADIUS protocol, this paper is not meant to be a broad all-enclosing analysis of the RADIUS protocol. First comes the overview of RADIUS protocol where basic operation of RADIUS protocol is studied. Different parties of RADIUS authentication and authorization procedure are introduced and the roles of these parties are dened. RADIUS packet is studied and all the elds of the packet are introduced. Authentication and authorization, accounting and proxy RADIUS functionality are also all reviewed. More detail is given to different RADIUS packet types. All RADIUS packet types are introduced and types dened in RADIUS standard are described in more detail. Also all RADIUS attributes are listed along with some basic information about these attributes. Readers are also informed where to look for more details about specic attributes. Analysis part of RADIUS is short and focuses in security issues. Main purpose of this security review is to give the reader some idea about RADIUS security. Focus of the analysis is in the security, because the security need of network is the problem that RADIUS was designed to solve.

1 Introduction
In networks having multiple users and resources shared through network the need for centralized user authentication and authorization is high. Centralization reduces need for administrative support and increases the network security. In networks that also have dial-in users through modem pools or other remote user, in other words users that use the network and the networks resources from another network, the security issues are even more important. To solve these problems Remote Authentication Dial In User Service protocol, the RADIUS, was developed. 1

HUT TML 2003

T-110.551 Seminar on Internetworking

The RADIUS protocol was rst dened in RFC 2058 [1], in January 1997, this RFC contains proposed standard. Also in January 1997 RADIUS accounting was introduced in RFC 2059 [2], status of which is informational. Later in April 1997 these RFCs were obsoleted by RFC 2138 [3] and RFC 2139 [4]. Former of these is proposed standard and latter informational. Then in June 2000 RFC 2865 [5] dened RADIUS draft standard and obsoleted RFC 2138. In same month informational RFC 2866 [6] RADIUS accounting obsoleted RFC 2139. RADIUS allows several clients to use one centralized authentication and authorization server for user authentication. User passwords transmitted to the server are encrypted and client can authenticate the server from reply. Replies are also protected from alteration. [5]

2 Operation
RADIUS protocol is used for user authentication and authorization and to pass conguration data between two servers. These servers are RADIUS server and Network Access Server (NAS) that acts as client for RADIUS server. NAS sends requests to RADIUS server which replies whether it denies or accepts the request and to pass conguration information concerning the request. [5]

2.1 System architecture

RADIUS protocol is used between two servers. RADIUS server is a shared authentication server that has a list of valid clients. There is a shared secret between the RADIUS server and these clients. This secret can not be empty, but otherwise it is not dened by the protocol standard how strong it must be. It is only recommended that it is 16 octets minimum and unguessable. This secret is used for to authenticate the RADIUS server to the NAS and to hide the user password. For these purposes the secret is part of value that is hashed and the hash value is sent. [5] RADIUS server also has a database of users containing their passwords, possible other requirements for these users to gain access and conguration data. According to information in this database the RADIUS server accepts or rejects the request or sends a challenge to user. RADIUS server can also act as a proxy relaying requests to other RADIUS server and to NAS. [5] When acting as proxy RADIUS server relies messages between the NAS and other RADIUS server. There can be many RADIUS servers as proxies between the NAS and the RADIUS server that nally handles the authentication and authorization of the request. A more detailed look at proxing will be taken in section 2.5. [5] Network Access Server (NAS) acts as a client to the RADIUS server. Users call in and NAS prompts for needed authentication information, for example user name and password. The NAS then can use RADIUS server for user authentication. When doing so the NAS sends request to the RADIUS server containing attributes that have information about user that the RADIUS server needs. When sending request containing user password, the password is not sent as clear-text, instead it is encrypted as described in section 4. [5] 2

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 1: RADIUS system architecture. [5]

NAS then waits for reply from the RADIUS server. Server can accept or reject the request or present a challenge for the user to respond. If request is accepted the server can also provide the NAS with conguration data and type of service granted for the user. If RADIUS server does not response in given time, NAS can retransmit the request or it can also use possible alternate RADIUS servers. In gure 1 basic RADIUS system architecture operation is shown. [5] RADIUS protocol uses UDP as its means of transport. UDP port assigned for RADIUS protocol is 1812. Previously RADIUS used UDP port 1645, but usage of this port conicted with datametrics service. Choice for using UDP instead of TCP is mainly for the reason that UDP is lighter protocol than more reliable TCP. RADIUS is a stateless protocol that does not carry much data as maximum size for UDP packet 4096 octets. As RADIUS is used for user authentication, few seconds delay is acceptable. In addition to complete the authentication and authorization does not need many RADIUS messages to be sent. Therefore choice for UDP over TCP is justied. [5]

2.2 Packet format

As previously stated RADIUS uses UDP to carry its packets. One UDP datagram contains exactly one RADIUS packet. RADIUS packet consists of ve different elds: Code, Identier, Length, Authenticator and Attributes. Figure 2 shows RADIUS packet format. Length of the entire RADIUS packet is 20 octets for the Code, Identier, Length and Authenticator. In addition to these various number of Attributes can be included, and the total length of the RADIUS packet is in the Length eld. [5] First eld in RADIUS packet is the Code. It is one octet long. This eld determines the type of the RADIUS packet. Originally six Code values were dened (four for authentication and authorization plus two for accounting), with two values reserved for possible use in the future. Also value 255 was reserved. Later further 26 new RADIUS packet Code values were dened by various vendors. A better look at different RADIUS packet types will in the section 3. All packets with invalid Code are not processed and no error message is sent. [5, 10, 6] Second eld in RADIUS packet is the Identier. The Identier is one octet long. Purpose of this eld is to match the requests and replies. The source IP address UDP port of the client are also used for match identication. Each request must have new identier value, if for the previous request a proper reply was received or if there is any changes in the Attributes of that request. The RADIUS server replies with the same Identier value in the 3

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 2: RADIUS packet format. [5]

reply as was in the request. [5] The Length eld is third eld in the RADIUS packet and it is two octets long. For all RADIUS packets have the Code, Identier, Length and Authenticator elds, the minimum length of the RADIUS packet 20 octets and therefore the minimum value for Length is 20. Maximum value is 4096. If the RADIUS packet is longer than Length eld states, all data that is outside the stated length is ignored. This is done to avoid overows. If the RADIUS packet is longer than Length eld states, the packet is not processed and no error message is sent. [5] Fourth eld in RADIUS packet is the Authenticator. This eld is 16 octets and the most signicant octet comes rst. This eld is used for two security functions. It authenticates the reply from the RADIUS server to the NAS and is also used in encryption of UserPassword attribute. More details on User-Password attribute can be found in section 4. Two different kinds of Authenticator elds are dened. [5] Request Authenticator is the name of the Authenticator eld in Access-Request type packets. Request Authenticator is a random number that the NAS generates in order to be able to authenticate that the reply is intended exactly for the request that the Request Authenticator was generated for. Therefore it must be unique and unpredictable. NAS also uses Request Authenticator when encrypting User-Password attribute. [5] Response Authenticator is the name of the Authenticator eld in Access-Accept, AccessReject and Access-Challenge type packets. The value of the Response Authenticator is calculated by the RADIUS server. For this calculation the RADIUS server uses the values of the Code, Identier and Length elds of the response being made, the Request Authenticator of the request, the Attributes of the response being made and the shared secret. These are concatenated in this order and then MD5 [17] hash is calculated of this concatenated string. The hash value is the Response Authenticator. Equation 1 shows formula for Response Authenticator. [5]

In addition to previous four elds RADIUS packet can contain a number of attributes. 4

h ) e B ) & e D  b# )  D )  &#     X !gcfCgHfGEdYcIaI$RG`YH'%$"YRYQ D  U S D )# P# B F D B @8 6 4 2 0 )  &#     W!HVETRIQ$I"(HGECA97531$('%$"!

(1)

HUT TML 2003

T-110.551 Seminar on Internetworking

Closer review of RADIUS attributes will be in section 4.

2.3 Authentication and Authorization

When NAS wishes to authenticate user via RADIUS, the NAS sends Access-Request packet to RADIUS server. To this packet the NAS set appropriate attributes that describe the needed information about the user and the service required to the RADIUS server. User password in User-Password attribute is sent encrypted and not in clear-text. The NAS also generates unique Request Authenticator for this request and sets Identier so that the NAS can connect the reply to this request. [5] Upon receiving this request the RADIUS server checks its list of valid clients that it has a shared secret with. If the request does not come from a client in this list, the request is not handled and no error message is sent. If the client is valid, the RADIUS server decrypts the user password (if present) and checks its user database for entry for requesting user and checks whether user passwords match. [5] If user is not found, passwords do not match or the user is not allowed to specic clients or ports that may be dened listed in user entry, the RADIUS server send Access-Reject packet to the client. If user is found, passwords are equal, user is allowed to access and no challenge/response is needed, then Access-Accept packet is sent to the client. [5] For any response Response Authenticator is calculated for this packet and Identier is identical to that of the request. The Access-Accept packet can have additional information about conguration values in attributes. Access-Reject packet in the other hand can only have attribute that contains a text message to be shown to the user. Figure 3 shows RADIUS authentication and authorization procedure. [5] When the NAS receives the reply, it matches the reply to the request using the Identier. Then the NAS calculates Response Authenticator for received reply the same way the RADIUS server did and compares this value to Response Authenticator in the message. If these match the the RADIUS server is authenticated and the integrity of the reply is veried. [5] All the elds of the reply (with Request Authenticator in place of Response Authenticator that is being calculated) and attributes of the reply are concatenated with the shared secret and hash value of this concatenation is the Response Authenticator. The Response Authenticator can therefore be used for checking the integrity and to authenticate the RADIUS server, as any change in the message or mismatched shared secret, and the values would not match. [5] RADIUS protocol support also additional challenge/response authentication. In this method the RADIUS server, after receiving Access-Request and having checked the user information from user database, sends Access-Challenge packet to the client. This packet may have an attribute that is message to be displayed to the user. [5] When the NAS receives Access-Challenge packet, it displays the message to the user (if message is present in the attributes) and waits for users response to this challenge. After user has responded, the NAS resends the original Access-Request packet with new identier and the users response encrypted in User-Password attribute. If the NAS does not 5

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 3: RADIUS authentication procedure. [5]

support this challenge/response scheme, it will regard Access-Challenge as Access-Reject. [5] RADIUS server then again checks from its user database if the response to the challenge was correct. It not, then Access-Reject packet is send. If response was correct, the RADIUS server can send Access-Accept or new Access-Challenge packet. In gure 3 can RADIUS challenge/response operation be seen. [5] With this challenge/response method RADIUS protocol can use special devices such as one-time-password generators or smart cards to enforce stronger authentication for dial-in users. This enhances RADIUS authentication strength because new innovation in this eld can be added as part of RADIUS user authentication process. [5]

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 4: RADIUS accounting. [6]

2.4 Accounting
RADIUS accounting is done almost the same way as RADIUS authentication and authorization. There are some differences. RADIUS accounting uses the UDP port 1813. There are also two RADIUS message codes and 12 attributes for RADIUS accounting. In addition Request Authenticator is calculated differently when using RADIUS accounting. [6] Accounting starts with the NAS sends RADIUS packet with code Accounting-Request having Acct-Status-Type attribute for Start to the RADIUS server. In the accounting start request are attributes containing information about the user and service being used. All attributes that can be used in Access-Request can also be used in Accounting-Request with ve exceptions. These are User-Password, CHAP-Password, Reply-Message, State and CHAP-Challenge attributes. [6] When the NAS wishes to stop the accounting, it sends RADIUS packet with code AccountingRequest having Acct-Status-Type attribute for Stop to the RADIUS server. This packet can have attributes containing information about the service that was used and statistics of the use. [6] Having received a request packet the RADIUS server then records the Accounting-Request and after successfully recording the packet acknowledges it by sending Accounting-Response packet to the NAS. If the request is not successfully recorded, then no acknowledgment is sent. If the NAS does not get acknowledgment for its request, it will retransmit the request or transmit the request to other RADIUS server. In Accounting-Response packet there are no attributes, except for possible Proxy-State and Vendor-Specic. Figure 4 shows operation of RADIUS accounting. [6] In Accounting-Request packet the generation of Request Authenticator is different from the generation of Request Authenticator in Access-Request packet. In Access-Request the Request Authenticator is random number, but in Accounting-Request packet the Request Authenticator a hash value so that it will protect the integrity f the request. AccountingRequest Request Authenticator is MD5 hash over concatenation of Code, Identier, Length, 16 zero octets, attributes in the request and secret shared between the NAS and the RADIUS server. [6] Response Authenticator in Accounting-Response packet is calculated the same way as described for Response Authenticator in section 2.2. [6]

HUT TML 2003

T-110.551 Seminar on Internetworking

2.5 Proxy
RADIUS server can also act as proxy server relaying RADIUS packets between the NAS and other RADIUS server that nally handles the NASs requests. We shall call that server remote server. One RADIUS server can act both as proxy and as remote server. There is no limit to how many remote servers can one RADIUS server forward RADIUS packets. Also there is no limit for how long can the forwarding chain be. [5] When RADIUS server receives requesting packet that needs to be forwarded, the RADIUS server rst checks if User-Password attribute is present. If it is, the RADIUS server decrypts the password using the secret it shares with the requesting client and then encrypts the password using the secret it shares with the remote server. [5] Then RADIUS server way add one Proxy-State attribute to help it handling the reply from the remote server. If there are any other Proxy-State attributes in the RADIUS packet they are left untouched as well as all other attributes. Then the RADIUS server set new Identier value and sends the packet to the remote server or to the next RADIUS server that will forward the packet towards the remote server. [5] When the packet reaches the remote server, the remote server handles the request as previously described. The remote server then replies as it sees t. If the request contained Proxy-State attributes, they all are copied as such to the reply. No other attributes are copied from the request, but new ones can be added. Then the reply is sent back towards the client that sent the request. [5] As the RADIUS server that acted as proxy for that request receives the reply, it veries the reply using the Response Authenticator in the reply and the secret it shares with the RADIUS server from which it received the the reply. If this verication fails, the packet is discarded and no error message is sent. If the verication is successful, then the proxy RADIUS server removes its Proxy-State attribute if it added one and set the Identier as it was in the request. Then new Response Authenticator is calculated using the secret shared with the sender of the request and the proxy RADIUS server. Then the reply is sent to the sender of the request. [5] This RADIUS proxy is shown in gure 5. In all other ways the proxied RADIUS packets are handled in same way as described in the sections 2.3 and 2.4. One RADIUS server can act as proxy to some requests, as remote server to others and some it can reply directly. [5]

3 Packet types
RADIUS protocol standard has four different types of packets for authentication and authorization. These are Access-Request, Access-Accept, Access-Reject and Access-Challenge. For accounting RADIUS has two packet types Accounting-Request and Accounting-Response. In the RADIUS protocol standard also two types were reserved for future use, StatusServer and Status-Client. In addition to these vendors have introduced 26 more packet types. Table 1 shows these 26 vendor dened packet types. [5, 8, 10] Access-Request packet has Code value of 1. This type of packet is used by NAS whenever it wishes to authenticate its user. The NAS then sends Access-Request packet with 8

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 5: RADIUS proxy. [5]

new Identier and unique Request Authenticator to the RADIUS server. Access-Request packet has attributes that have information about the user, such as User-Name and UserPassword. Also NAS-IP-Address attribute or a NAS-Identier attribute or both are present. An Access-Request packet can also have various other attributes. [5] Access-Accept packet has Code value of 2. If the RADIUS server approves all the attributes in Access-Request packet, the RADIUS server will respond with Access-Accept packet that has same Identier as the request. Attributes in Access-Accept packet contain conguration information for the NAS about the service to be delivered to the user. Response Authenticator is calculated as described in section 2.2. [5] Access-Reject packet has Code value of 3. If the RADIUS server does not approve some attribute in Access-Request packet, the RADIUS server will respond with Access-Reject packet that has same Identier as the request. Access-Reject packet can have ReplyMessage attributes that contain a message to be showed to the user. Response Authenticator is calculated as described in section 2.2. [5] Access-Challenge packet has Code value of 11. If the RADIUS server wishes to challenge the user for response, the RADIUS server will then send Access-Challenge packet that has same Identier as the Access-Request packet did. Challenge to be shown to user is in one or more Reply-Message Attributes of the Access-Challenge packet. Also State, Vendor-Specic, Idle-Timeout, Session-Timeout and Proxy-State attributes can be in Access-Challenge packet, but no others can. Response Authenticator is calculated as described in section 2.2. [5] Accounting-Request packet has Code value of 4. When NAS wishes to start or stop accounting for a service provided to a user, it will send Accounting-Request packet with new identier to RADIUS accounting server. Accounting-Request packet has Acct-StatusType attribute that has value Start or Stop. Request Authenticator for Accounting-Request packet is calculated as described in section 2.42.4. [5] Accounting-Response packet has Code value of 5. Having received Accounting-Request packet and after successfully recording it, the RADIUS accounting server will send Accounting9

HUT TML 2003

T-110.551 Seminar on Internetworking

Code 6 7 8 9 10 21 22 23 24 25 26 27 29 30 31 32 33 34 40 41 42 43 44 45 50 51

Name Accounting Status Password Request Password Ack Password Reject Accounting Message Resource Free Request Resource Free Response Resource Query Request Resource Query Response Alternate Resource Reclaim Request NAS Reboot Request NAS Reboot Response Next Passcode New Pin Terminate Session Password Expired Event Request Event Response Disconnect Request Disconnect Ack Disconnect Nak Change Filters Request Change Filters Ack Change Filters Nak IP Address Allocate IP Address Release

Table 1: Vendor specied RADIUS packet types. [10]

Response packet that has same Identier as the Accounting-Request to the NAS. AccountingResponse packet can have only Proxy-State or Vendor-Specic attributes. Response Authenticator is calculated as described in section 2.2. [5]

4 Attributes
RADIUS uses attributes to carry additional information such as conguration data, information about the user and service. Standard length for RADIUS attribute is three elds, but some attributes have more elds. These elds are Type, Length and Value. Figure 6 shows RADIUS attribute. If attribute has more than three elds the additional elds are situated between Length and Value. Type and Length elds are both one octet long and Value is of variable length. The Length eld denotes the length of the entire attribute. [5] The Value eld can be of ve different data types. These types are text, string, address, integer and time. Text is 1-253 octet long chain of UTF-8 encoded characters. String is 1-253 octet long binary value. Address is 4 octet long and most signicant octet is rst 10

HUT TML 2003

T-110.551 Seminar on Internetworking

Figure 6: RADIUS attribute. [5]

but 16 octets for IPv6 address. Integer is usually unsigned 32 bit integer but may vary in length. Time is unsigned 32 bit integer of seconds since 00:00:00 UTC, January 1, 1970. [5] Table 2 shows dened RADIUS attributes between 1-48. Table 3 shows dened RADIUS attributes between 49-100. In table 2 and table 3 Type is attribute number, Name is the name of the attribute, Length is the length of entire attribute, VDT is the data type of the attribute Value eld, NoF is the number of elds in the attribute, RFC is the number of the RFC this attribute is dened, next ve columns state how many of attributes of that type can be in specic packet. A-R is Access-Request, A-A is Access-Accept, A-R is AccessReject, A-C is Access-Challenge and Acc is Accounting-Request. Here 0+ means that zero or more of this attribute type can be in that packet. Possible attributes of AccountingResponse are listed in section 3. Attribute values 1-100 are dened. Attribute values 192-223 are reserved for experimental use, values 224-240 for implementation specic use and values 241-255 are reserved and not to be used. Values 17 and 21 are unassigned. Values 54 and 56-59 are reserved for accounting but are unused. Values 89 and 92-94 are also unused. As attribute values were dened in time line between January 1997 and august 2001, vendors use values from 90255 in their implementations of RADIUS. This causes attribute value conicts and not all implementations can inter-operate. [5, 6, 7, 8, 9, 10, 11] User password in User-Password attribute is encrypted. Encryption is done as follows. First password is divided to 16 octet segments, padded is not multiple of 16. So a number of 16 octet segments is gained, now denoted as s(1), s(2)... Then MD5 hash is calculated over concatenation the secret shared between the NAS and the RADIUS server and the Request Authenticator, result now denoted as h(1). Then s1 and h(1) are XORed, the result denoted as c(1). c(1) is the placed as the rst 16 octets of the User-Password attribute. For all values of s(i), i greater than 2, MD5 hash is calculated over concatenation the secret shared between the NAS and the RADIUS server and c(i-1) and h(i) is gained. Then s(i) and h(i) are XORed and c(i) is the result. Finally the User-Password attribute contains concatenation of all c(1) to c(i) values. [5]

5 Security
RADIUS protocol used MD5 hash function and secret shared between the NAS and the RADIUS server to gain hash value that is used for checking message integrity, authenticating the RADIUS server to the NAS and to hide the user password in User-Password attribute. Therefore the this scheme is no stronger than the cryptographic strength of MD5.

11

HUT TML 2003

T-110.551 Seminar on Internetworking

In Eurocrypt 96 rump session Hans Dobberting published having found a collision in the compression function of MD5 [14]. Shortly afterwards in the RSA Laboratories technical newsletter CryptoBytes [13] he published an article on status of the MD5 algorithm after this collision in the compression function. In this article he recommends that MD5 should no longer be used for signatures. This collision in the compression function does not lead to practical attacks against MD5 but it has caused the RSA to expect such development [12]. RSA therefore recommend that MD5 should not be used in roles that require collision resistance. Paul van Oorschot and Michael Wiener published in 1994 a paper containing design for custom made machine that would complete an attack against MD5 in 24 days [15]. That machine would have costed 10 million dollars. Later in 1996 they wrote a paper [16] describing a machine costing the same 10 million dollars that would have completed the task in 21 days. Today that time would be signicantly shorter. This does not present clear threat to RADIUS. Candidates for shared secret can be found by collisions. But if the secret is long and random, nding it through iterating collisions is very unlikely. Almost Known-Plain-Text attack against RADIUS shared secret nding scheme can be made by eavesdropping the trafc between the RADIUS server and the NAS. Request Authenticator and elds of the reply to the request are used with the shared secret to produce Response Authenticator. The only unknown here is the shared secret. If the attacker pretends to be a valid client by forging sender address, attacker can choose Request Authenticator for the request, and can choose part of the block that is hashed. In May 2000 Internet draft [20] that evaluated how well RADIUS met IETF Authentication Authorization Accounting Working Groups requirements for network access protocols [21]. In this Internet draft RADIUS is noted to fail many important security criteria such as data object integrity and condentiality. In February 2000 Internet draft describing RADIUSv2 was published [18]. This tells that RADIUS dened in RFC2865 was not all satisfactory. Later in June 2000 Internet draft that extended RADIUSv2 to RADIUS++ was published [18]. This extended version of RADIUS was in RFC 3127 [22] evaluated against the criteria in [21], and RADIUS++ did little better. But in RFC 3127 is stated that RADIUS++ is not an acceptable authentication and authorization protocol. But today main problems of RADIUS lie not in the security, for they arise from the fact that RADIUS was developed to authenticate dial-in users and not wast numbers of network users.

6 Summary
RADIUS protocol widely used authentication and authorization protocol. But RADIUS was originally designed to allow Network Access Server to authenticate dial-in users. Today the Internet is dominating over the use of modem pools and number of users has increased dramatically. RADIUS has no error messages and in case of problems retransmission is used. With great number of users, in case some network problem, these retransmission can themselves be a bad problem. When developed RADIUS was designed to be expendable protocol. Allowing other au-

12

HUT TML 2003

T-110.551 Seminar on Internetworking

thenticating methods than just passwords. This side RADIUS has made it so used even today. Even though RADIUS extension such as RADIUSv2 and RADIUS++ have been designed, RADIUS is soon likely to be history. A new protocol called Diameter [23] has been designed by the IETF AAA working group that is to perform same task and more as the RADIUS protocol.

References
[1] C. Rigney, A. Rubens, W. Simpson and S. Willens. RFC 2058: Remote Authentication Dial In User Service (RADIUS). http://www.ietf.org/rfc/rfc2058.txt [2] C. Rigney. RFC 2059: RADIUS Accounting. http://www.ietf.org/rfc/rfc2059.txt [3] C. Rigney, A. Rubens, W. Simpson and S. Willens. RFC 2138: Remote Authentication Dial In User Service (RADIUS). http://www.ietf.org/rfc/rfc2138.txt [4] C. Rigney. RFC 2139: RADIUS Accounting http://www.ietf.org/rfc/rfc2139.txt [5] C. Rigney, A. Rubens, W. Simpson and S. Willens. RFC 2865: Remote Authentication Dial In User Service (RADIUS). http://www.ietf.org/rfc/rfc2865.txt [6] C. Rigney. RFC 2866: RADIUS Accounting http://www.ietf.org/rfc/rfc2866.txt [7] G. Zorn, B. Aboba, D. Mitton. RFC 2867: RADIUS Accounting Modications for Tunnel Protocol Support. http://www.ietf.org/rfc/rfc2867.txt [8] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret. RFC 2868: RADIUS Attributes for Tunnel Protocol Support. http://www.ietf.org/rfc/rfc2868.txt [9] C. Rigney, W. Willats, P. Calhoun. http://www.ietf.org/rfc/rfc2869.txt RFC 2869: RADIUS Extensions.

[10] D. Mitton. RFC 2882: Network Access Servers Requirements: Extended RADIUS Practices. http://www.ietf.org/rfc/rfc2882.txt [11] B. Aboba, G. Zorn, D. Mitton. http://www.ietf.org/rfc/rfc3162.txt RFC 3162: RADIUS and IPv6.

[12] M.J.B. Robshaw. RSA Laboratories Bulletin: On Recent Results for MD2, MD4 and MD5, November 1996. ftp://ftp.rsasecurity.com/pub/pdfs/bulletn4.pdf [13] Hans Dobbertin. The Status of MD5 After a Recent Attack, CryptoBytes, volume 2, number 2, summer 1996. ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf [14] Hans Dobbertin. Cryptoanalysis of MD5 Compress, Eurocrypt 96 rump session papers, May 1996. http://www.iacr.org/conferences/ec96/rump/dobberti.ps.gz [15] Paul C. van Oorschot, Michael J. Wiener. Parallel Collision Search with Application to Hash Functions and Discrete Logarithms, proceedings, 2nd ACM Conference on Computer and Communications Security, November 1994. http://www.scs.carleton.ca/ paulv/papers/acmccs94.ps

13

HUT TML 2003

T-110.551 Seminar on Internetworking

[16] Paul C. van Oorschot, Michael J. Wiener. Parallel collision search with cryptanalytic applications, September 1996, Journal of Cryptology, vol.12 no.1 January 1999. http://www.scs.carleton.ca/ paulv/papers/JoC97.pdf [17] R. Rivest, S. Dusse. RFC 1321: http://www.ietf.org/rfc/rfc1321.txt The MD5 Message-Digest Algorithm.

[18] C. Rigney, A. Rubens, W. Simpson, S. Willens. Remote Authentication Dial In User Service (RADIUS) http://ftp.cerias.purdue.edu/pub/doc/network/radius/draftietf-radius-radius-v2-06.txt [19] Y. TJoens, R. Ekstein, M. De Vries, O. Paridaens. Framework for the extension of the RADIUS(v2) protocol http://www.interlinknetworks.com/images/resource/rfc/aaa_working_group/drafttjoens-aaa-radius-00.txt [20] Y. TJoens, R. Ekstein, M. De Vries. Comparison of RADIUS Against AAA Network Access Requirements http://www.interlinknetworks.com/images/resource/rfc/aaa_working_group/drafttjoens-aaa-rad-cmp-00.txt [21] B. Aboba et al. RFC 2989: Criteria for Evaluating AAA Protocols for Network Access. http://www.ietf.org/rfc/rfc2989.txt [22] D. Mitton et al. RFC 3127: Authentication, Authorization, and Accounting: Protocol Evaluation http://www.ietf.org/rfc/rfc3127.txt [23] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko. Diameter Base Protocol. http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-17.txt

14

HUT TML 2003

T-110.551 Seminar on Internetworking

Type 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 18 19 20 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

Name User-Name User-Password CHAP-Password NAS-IP-Address NAS-Port Service-Type Framed-Protocol Framed-IP-Address Framed-IP-Netmask Framed-Routing Filter-Id Framed-MTU Framed-Compression Login-IP-Host Login-Service Login-TCP-Port Reply-Message Callback-Number Callback-Id Framed-Route Framed-IPX-Network State Class Vendor-Specic Session-Timeout Idle-Timeout Termination-Action Called-Station-Id Calling-Station-Id NAS-Identier Proxy-State Login-LAT-Service Login-LAT-Node Login-LAT-Group Framed-AppleTalk-Link Framed-AppleTalk-Network Framed-AppleTalk-Zone Acct-Status-Type Acct-Delay-Time Acct-Input-Octets Acct-Output-Octets Acct-Session-Id Acct-Authentic Acct-Session-Time Acct-Input-Packets Acct-Output-Packets

Length >=3 18-130 19 6 6 6 6 6 6 6 >=3 6 6 6 6 6 >=3 >=3 >=3 >=3 6 >= 3 >= 3 >= 7 6 6 6 >=3 >=3 >=3 >=3 >=3 >=3 34 6 6 >=3 6 6 6 6 >=3 6 6 6 6

VDT String String String Address Integer Integer Integer Address Address Integer Text Integer Integer Address Integer Integer Text String String Text Integer String String String Integer Integer Integer String String String String String String String Integer Integer String Integer Integer Integer Integer Text Integer Integer Integer Integer

NoF 3 3 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3

RFC 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2865 2866 2866 2866 2866 2866 2866 2866 2866 2866

A-R 0-1 0-1 0-1 0-1 0-1 0-1 0-1 0-1 0-1 0 0 0-1 0+ 0+ 0 0 0 0-1 0 0 0 0-1 0 0+ 0 0 0 0-1 0-1 0-1 0+ 0-1 0-1 0-1 0 0 0 0 0 0 0 0 0 0 0 0

A-A 0-1 0 0 0 0 0-1 0-1 0-1 0-1 0-1 0+ 0-1 0+ 0+ 0-1 0-1 0+ 0-1 0-1 0+ 0-1 0-1 0+ 0+ 0-1 0-1 0-1 0 0 0 0+ 0-1 0-1 0-1 0-1 0+ 0-1 0 0 0 0 0 0 0 0 0

A-R 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0+ 0 0 0 0 0 0 0 0 0 0 0 0 0 0+ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

A-C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0+ 0 0 0 0 0-1 0 0+ 0-1 0-1 0 0 0 0 0+ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Acc 0-1 0 0 0-1 0-1 0-1 0-1 0-1 0-1 0-1 0+ 0-1 0+ 0+ 0-1 0-1 0 0-1 0-1 0+ 0-1 0 0+ 0+ 0-1 0-1 0-1 0-1 0-1 0-1 0+ 0-1 0-1 0-1 0-1 0-1 0-1 1 0-1 0-1 0-1 1 0-1 0-1 0-1 0-1

Table 2: RADIUS attributes 1-48 15

HUT TML 2003

T-110.551 Seminar on Internetworking

Type 49 50 51 52 53 55 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 90 91 95 96 97 98 99 100

Name Acct-Terminate-Cause Acct-Multi-Session-Id Acct-Link-Count Acct-Input-Gigawords Acct-Output-Gigawords Event-Timestamp CHAP-Challenge NAS-Port-Type Port-Limit Login-LAT-Port Tunnel-Type Tunnel-Medium-Type Tunnel-Client-Endpoint Tunnel-Server-Endpoint Acct-Tunnel-Connection Tunnel-Password ARAP-Password ARAP-Features ARAP-Zone-Access ARAP-Security ARAP-Security-Data Password-Retry Prompt Connect-Info Conguration-Token EAP-Message Message-Authenticator Tunnel-Private-Group-ID Tunnel-Assignment-ID Tunnel-Preference ARAP-Challenge-Response Acct-Interim-Interval Acct-Tunnel-Packets-Lost NAS-Port-Id Framed-Pool Tunnel-Client-Auth-ID Tunnel-Server-Auth-ID NAS-IPv6-Address Framed-Interface-Id Framed-IPv6-Prex Login-IPv6-Host Framed-IPv6-Route Framed-IPv6-Pool

Length 6 >=3 6 6 6 6 >=7 6 6 >=3 6 6 >=3 >=3 >= 3 >=5 18 16 6 6 >=3 6 6 >=3 >=3 >=3 18 >=3 >=3 6 10 6 6 >=3 >=3 >=3 >=3 18 10 4-20 18 >=3 >=3

VDT Integer String Integer Integer Integer Time String Integer Integer String Integer Integer String String String String String String Integer Integer String Integer Integer Text String String String String String Integer String Integer Integer Text String String String Address Integer Address Text String

NoF 3 3 3 3 3 3 3 3 3 3 4 4 4 4 3 5 3 3 3 3 3 3 3 3 3 3 3 4 4 4 3 3 3 3 3 4 4 3 3 5 3 3 3

RFC 2866 2866 2866 2869 2869 2869 2865 2865 2865 2865 2868 2868 2868 2868 2867 2868 2869 2869 2869 2869 2869 2869 2869 2869 2869 2869 2869 2868 2868 2868 2869 2869 2867 2869 2869 2868 2868 3162 3162 3162 3162 3162 3162

A-R 0 0 0 0 0 0 0-1 0-1 0-1 0-1 0+ 0+ 0+ 0+ 0 0 0-1 0 0 0-1 0+ 0 0 0-1 0 0+ 0-1 0+ 0 0+ 0 0 0 0-1 0 0+ 0+ 0-1 0-1 0+ 0+ 0 0

A-A 0 0 0 0 0 0 0 0 0-1 0-1 0+ 0+ 0+ 0+ 0 0+ 0 0-1 0-1 0 0 0 0 0 0+ 0+ 0-1 0+ 0+ 0+ 0-1 0-1 0 0 0-1 0+ 0+ 0 0-1 0+ 0+ 0+ 0-1

A-R 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0-1 0 0 0 0+ 0-1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

A-C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0-1 0 0-1 0+ 0 0-1 0 0 0+ 0-1 0 0 0 0-1 0 0 0 0 0 0 0 0 0 0 0 0

Acc 0-1 0+ 0+ 0-1 0-1 0-1 0 0-1 0-1 0-1 0-1 0-1 0-1 0-1 0-1 0 0 0 0 0 0 0 0 0+ 0 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0-1 0-1 0-1 0-1 0+ 0+ 0+ 0-1

Table 3: RADIUS attributes 49-100

16