CNS - 14 - RADIUS II

• Date: [2020-10-21 mer 11:30]

• Lecturer: Giuseppe Bianchi

• Slides:

• Introduction: In this lecture we finish off our discussion of the RADIUS protocol by discussing the second vulnerability of the protocol: the way passwords were encrypted.

Suppose the user sends his credentials (username:password) to the nas using a PAP protocol. Now the nas has to send these same credentials to the radius server. Notice however that, even if the communication between the end-client and the nas could be considered to be done over a secure-channel, the same cannot be said for the communication between the nas (radius-client) and the radius server.

The radius protocol thus defined a technique to encrypt the password. Consider a user password, like \(\text{ugo}\). To encrypt it the radius protocol did the following things:

1. Adds padding to reach \(16\) bytes.

2. Generate a \(16\) byte hash using the secret key and the content of the authenticator field of the request

   \[\text{MD5}(\text{secret} \,\,|\,\, \text{Request Auth}\]

3. The password is encrypted by XORing the padded password with the hash generated before.

   

Notice that if the password is longer than 16 characters. Since for security reasosn we cannot pad two blocks with the same stream, the following extra steps had to taken

1. Compute a different keystream in the following way

   \[\text{MD5}(\text{secret} \,\,|\,\, \text{result of previous XOR})\]

2. XOR with the next segment of the password.

First of all, radius is vulnerable to message sniffing and modification:

• As far as the message sniffing is concerned, since radius is a clear-text protocol, this leads to potentially significant privacy issues. The only fix in this case is to use a secure communication channel, which can be created with TLS for example.

• The message modification vulnerability is much more dangerous, because it leds to the forging of access-requests. The solution in this case is to add authentication to the requests aswell as the replies.

Observation: EAP (Extensible Authentication Protocol) is not an authentication protocol, but this is a protocol that lets you exchange authentication messages. This means that the authentication approach used inside EAP is arbitrary. For example there is EAP-TLS, EAP-AKA. For example, when you connect to the eudoroam network, you use the EAP-PEAP.

The security of radius requires the uniqueness of the request authenticator. How do we generate such request authenticator?

To answer such question consider the following question: suppose you have available a function rand() which generates \(4\) random bytes, and you have to generate \(16\) bytes. To do this you have three approaches, which are:

1. Call the function four times to generate four distinct values.

   \[R_1, R_2, R_3, R_4\]

2. Call the function one time to generate a single \(4\) byte value and fill the remaining space with zeroes.

   \[R_1, 0, 0, 0\]

3. Call the function one time to generate \(R_1\) and fill the space by comuting four times the \(\text{MD}(\cdot)\) of the single generated value.

   \[\text{MD5}(R_1), \text{MD5}(R_1), \text{MD5}(R_1), \text{MD5}(R_1)\]

Even though intuitively we'd probably answer the first strategy, the actual answer is the third one. The reason for this is that pseudo random number generators have a specified period, which is the length of the cycle such that the number do not repeat. Typically, non crypto PRNGs of \(N\) bits have a period of \(2^N\). Consider for example the following PRNG

\[0 \to 3 \to 1 \to 5 \to 6 \to 2 \to 7 \to 4 \to 0 \to 3 \to 1 \to \ldots\]

Notice the period of this PRNG is \(8\), and thus it uses \(3\) bits. Now, suppose we merge four subsequent pseudo-random numbers generated with this PRNG. We'd have that

• The first packet would have \(0, 3, 1, 5\)

• The second packet would have \(6, 2, 7, 4\)

• The third packet would have \(0, 3, 1, 5\)

So we started with a PRNG with period \(8\) and we found a repetition after \(2\) packets. We basically dropped down the period of a factor of \(4\), because we aggregated \(4\) numbers together. You thus don't want to include too many subseqeuent numbers generated from the same seed. If we define security in terms of the probability of repeating, i.e. after how much we see repetition, we have that

• The first solution repeats after roughly \(2^{30}\).

• The second and third solution repeat after roughly \(2^{32}\).

Most radius implementation were based on non-secure PRGNs. Even if a PRGNs passes statistical tests such as Kolmogorov-Smirnov tests and so on, they still might be poor from the pov of security. Often non-secure PRGNs have the following weaknesses:

• Predictabiity: Poor-PRGNs are often very predictable, meaning that if I show you a value then you can infer what will be the next value or what was the previous value; Crypto PRGNs should not allow this to be done.

• Short cycles: Sometimes it happens that the generator repeats earlier with respect to the maximum given by the number of bits of the PRGNs.

• unique values: You should also check if the values generated by the PRGN are unique values or repeated values. If you have a PRNG with a cycle \(2^N\) if the values do repeat then by the birthday paradox your security level is approximately \(2^{N/2}\).

From RADIUS we have learned the following things:

• An application protocol should not include security. The idea is to develop a protocol completely insecure, and then secure it using a protocol specific for security, like TLS.

• Remember to avoid including algorithms in protocols.