A>
A> -----Original Message-----
A> From: Bulgaria Online - Assen Totin [mailto:assen@online.bg]
A> Sent: Tuesday, November 23, 2004 6:08 AM
A> To: security-basics@securityfocus.com
A> Subject: Re: Basic questions about RADIUS authentication
A>
A> Hi all,
A>
A> V> Q.1- Is it not possible to sniff this communication and launch a
dictionary
A> V> attack?
A>
A> Provided the attacker pretends to be a valid RADIUS client, yes.
A> However, the RADIUS server normally responds only to clients listed
in
A> its configuration. So the attack should also come from a "valid"
(from
A> the point of view of the RADIUS server) IP address - or spoof the
A> source IP address _and_ take measures to receive the replies.
A>
A> V> After the user is authenticated, RADIUS server creates and sends
the user
A> V> and the NAS session keys.
A> V> Q.2- Is it not possible in this instance to launch a
man-in-the-middle
A> V> attack?
A>
A> I'm not sure about this. RADIUS can do not only authentication, but
A> solely accounting or authorisation. Thus "After the user is
A> authenticated" is not clear to me. From what I know, after the server
A> processes the query, it assigns a more or less unique Session-Id
A> (which is used further till the end of the session).
This varies depending on the "NAS" making the request and the RADIUS
software. I say NAS in quotes because there are LOTs of devices using
RADIUS nowadays that are not really a NAS based on the original
definition of the acronym used for dialup. The "NAS" is required to
maintain session information in the accounting data, but MAY do so in
the authentication request, provided it uses the same identifier. This
is done using the Acct-Session-Id attribute, as outlined in the RFCs.
Some RADIUS servers also use the Class attribute when sending the
authenticaion ACK back to the "NAS" to maintain some session state. If
the RADIUS server sends Class in the authentication ACK, then the "NAS"
is required to send the same attribute/value pair in all accounting
requests it makes to the RADIUS server for that session. Then the
RADIUS server can tie accounting requests to a given authentication
request for better tracking.
A>
A> V> Q.3- How is the data (userids and passwords) secured in the RADIUS
server?
A> V> Is it not possible to launch an attack at the RADIUD server
database?
A>
A> I guess depends on the RADIUS server and configuration. As far as I
A> know, RADIUS server can authenticate requests against several
sources,
A> including probably /etc/passwd, SQL database (Cistron RADIUS and its
A> successors at least), or even through an external application
A> (e.g. XtRadius). So the protection of the passwords is not really a
A> RADIUS issue, but a system administration task (of course, one should
A> take care not to configure RADIUS to show plain text passwords in its
A> log files). External attack (meaning an attack coming from a host,
A> different from the RADIUS server) would probably be a brute-force
A> one trying to guess a valid pair of username and password. However,
if
A> a potential attacker gains access (even non-privileged) to the host
A> where RADIUS server resides, his opportunities to interfere in the
A> authentication process become much broader.
It's all subjective based on every variable you could think of. OS,
data source(s), RADIUS application, DB(s), flat files, configuration, DB
encryption, etc. If the network and systems are designed well, you
should only have the RADIUS servers allowed to query the DB and the
RADIUS servers should only accept requests from specific IP addresses.
Plus any DB encryption, etc. as needed.
A>
A> WWell,
A>
A> Assen Totin
A> Development Manager
A>
A> ===============================
A> BULGARIA ONLINE
A> Your quality... Your price!
A> ===============================
A> tel. (+359 2) 973-3000 ext. 511
A> http://home.online.bg
A>
~~~~~~~~~~~~~~~~~~~~~~~~~
Ed Whitesell
Network Manager
Airpath
"Clearing the Way"
edw@airpath.com
http://www.airpath.com
~~~~~~~~~~~~~~~~~~~~~~~~~
