[NEWS] An Analysis of the RADIUS Authentication Protocol
From: support@securiteam.comDate: 11/13/01
- Previous message: support@securiteam.com: "[NEWS] Lotus Domino Web Administrator Template ReplicaID Access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Subject: [NEWS] An Analysis of the RADIUS Authentication Protocol Message-Id: <20011113181808.80783138BF@mail.der-keiler.de> Date: Tue, 13 Nov 2001 19:18:08 +0100 (CET)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
An Analysis of the RADIUS Authentication Protocol
------------------------------------------------------------------------
SUMMARY
RADIUS is a widely used protocol in network environments. It is commonly
used for embedded network devices such as routers, modem servers,
switches, etc. It is used for several reasons:
* The embedded systems generally cannot deal with a large number of users
with distinct authentication information. This requires more storage than
many embedded systems possess.
* RADIUS facilitates centralized user administration, which is important
for several of these applications. Many ISPs have tens of thousands,
hundreds of thousands, or even millions of users. Users are added and
deleted continuously throughout the day, and user authentication
information changes constantly. Centralized administration of users in
this setting is an operational requirement.
* RADIUS consistently provides some level of protection against a
sniffing, active attacker. Other remote authentication protocols provide
either intermittent protection, inadequate protection or non-existent
protection. RADIUS's primary competition for remote authentication is
TACACS+ and LDAP. LDAP natively provides no protection against sniffing or
active attackers. TACACS+ is subtly flawed, as discussed by Solar Designer
in his advisory.
* RADIUS support is nearly omni-present. Other remote authentication
protocols do not have consistent support from hardware vendors, whereas
RADIUS is uniformly supported. Because the platforms on which RADIUS is
implemented on are often embedded systems, there are limited opportunities
to support additional protocols. Any changes to the RADIUS protocol would
have to be at least minimally compatible with pre-existing (unmodified)
RADIUS clients and servers.
RADIUS is currently the de-facto standard for remote authentication. It is
very prevalent in both new and legacy systems.
The following is an in-depth analysis of the protocol, written by Joshua
Hill.
DETAILS
Applicability:
This analysis deals with some of the characteristics of the base RADIUS
protocol and of the User-Password attribute. Depending on the mode of
authentication used, the described User-Password weaknesses may or may not
compromise the security of the underlying authentication scheme. A
complete compromise of the User-Password attribute would result in the
complete compromise of the normal Username/Password or PAP authentication
schemes, because both of these systems include otherwise unprotected
authentication information in the User-Password attribute. On the other
hand, when CHAP or a Challenge/Response system is in use, a complete
compromise of the User-Password attribute would only expose the underlying
CHAP or Challenge/Response information to additional attack, which may or
may not lead to a complete compromise of the authentication system,
depending on the strength of the underlying authentication system.
This analysis does not cover the RADIUS protocol's accounting
functionality (which is, incidentally, also flawed, but normally does not
transport information that must be kept confidential).
Protocol Summary:
A summary of the RADIUS packet is below (from the RFC):
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 | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
The code establishes the type of RADIUS packet. The codes are:
Value Description
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
The identifier is a one-octet value that allows the RADIUS client to match
a RADIUS response with the correct outstanding request.
The attributes section is where an arbitrary number of attribute fields
are stored. The only pertinent attributes for this discussion are the
User-Name and User-Password attributes.
This description will concentrate on the most common type of RADIUS
exchange: An Access-Request involving a username and user password,
followed by Access-Accept, Access-Reject, or a failure. We will refer to
the two participants in this protocol as the client and the server. The
client is the entity that has authentication information that it wishes to
validate. The server is the entity that has access to a database of
authentication information that it can use to validate the client's
authentication request.
Initial Client Processing:
The client creates an Access-Request RADIUS packet, including at least the
User-Name and User-Password attributes.
The Access-Request packet's identifier field is generated by the client.
The generation process for the identifier field is not specified by the
RADIUS protocol specification, but it is usually implemented as a simple
counter that is incremented for each request.
The Access-Request packet contains a 16 octet Request Authenticator in the
authenticator field. This Request authenticator is a randomly chosen
16-octet string.
This packet is completely unprotected, except for the User-Password
attribute, which is protected as follows:
The client and server share a secret. That shared secret followed by the
Request Authenticator is put through an MD5 hash to create a 16-octet
value that is XORed with the password entered by the user. If the user
password is greater than 16 octets, additional MD5 calculations are
performed, using the previous cipher text instead of the Request
Authenticator.
More formally:
Call the shared secret S and the pseudo-random 128-bit Request
Authenticator RA. The password is broken into 16-octet blocks p1, p2, ...
pn, with the last block padded at the end with '0's to a 16-octet
boundary. The cipher text blocks are c1, c2... cn.
c1 = p1 XOR MD5(S + RA)
c2 = p2 XOR MD5(S + c1)
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[NEWS] Lotus Domino Web Administrator Template ReplicaID Access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
