[4955] in Kerberos
Re: Kerberos vs Radius
daemon@ATHENA.MIT.EDU (Joe Kovara)
Mon Apr 10 10:33:33 1995
To: kerberos@MIT.EDU
Date: Mon, 10 Apr 1995 06:06:16 -0700
From: Joe Kovara <joek@kerby.ocsg.com>
> Is there any work contrasting the security of authentication using
> Kerberos with the Radius protocol?
Kerberos and RADIUS (Remote Authentication Dial In User Service) are
intended to solve very different problems, and work in very different
ways. Comparing them is questionable, at best. That said, there has
been considerable interest in--and confusion about--RADIUS from various
Kerberos sites. So, at the risk of offending some (and putting foot in
mouth), I'll post here.
The rest of this verbiage is mostly a description of what Kerberos does
that RADIUS doesn't (there isn't much intersection). This is not an
indictment of RADIUS--RADIUS was not intended to solve the same problems
as Kerberos.
The only real indictment I have of RADIUS is the prominent use of the
words "Authentication" and "Dial In" in the title. RADIUS has very little
to do with nuts-and-bolts authentication. What RADIUS really does is
protect some of the communications between a RADIUS device and a RADIUS
client. (By device, I mean a terminal server or equivalent. In the spec
they are referred to as a "Network Access Server", or NAS.). Thus, RADIUS
is no better and no worse than anything else at protecting information
sent over phone lines (including passwords).
RADIUS doesn't really address how a user is to be authenticated--other
than that a network device or RADIUS server may maintain it's own
authentication information for users, or that a RADIUS server may consult
(act as a client of) an authentication server. (The RADIUS specification
mentions Kerberos as a possible authentication server.) The discussion of
authentication is actually a relatively minor part of the RADIUS
specification. Most of RADIUS is concerned with the transfer and format
of configuration information.
RADIUS is more a "secure transport" between a network device and a
RADIUS server which--among other things--is expected to authenticate the
user (or talk to an authentication server, such as a Kerberos KDC, that
can). This authentication can occur using a single exchange, or can
involve a challenge-response between the end-user and the authentication
server. The RADIUS specification does not address mutual authentication
between the end user and the RADIUS device, although a challenge-
response mechanism might be used to implement some form of mutual
authentication. I don't know of any such implementation. (I have a
problem with an unauthenticated entity asking for my password.)
Authentication between the RADIUS device and the RADIUS server is
accomplished using a shared secret key.
The secure transport provided by RADIUS is--for the most part--what
Kerberos people call "safe messages"; encryption (Kerberos "private
message") is not addressed except to protect passwords being transported
for authentication (see below). RADIUS's transport security is also not
specified for use with anything except specific RADIUS messages, and
thus does not provide security for, e.g., telnet sessions. Nor does
RADIUS address communication between anything but a RADIUS device and a
RADIUS server. Nor does RADIUS provide for the establishment of
session-keys--all communications are between the RADIUS device and
server, and most interactions are a small number of messages. (I expect
one message in each direction is typical.)
The security of RADIUS's transport is critical because RADIUS transports
the user's authentication information to the (authentication) server.
RADIUS simply delivers whatever comes from the remote (user) end to the
authentication server, and this must match what the authentication
server requires as proof of the user's identity. I say "proof of
identity" because there is nothing in the specification that requires
that a (clear-text) password be supplied to the RADIUS device and
transported to the authentication server. (I get the impression--and
it's only an impression--that the RADIUS authors expect passwords to be
transported.)
The distinction between sending a password and sending proof of identity
may seem academic. It's not if you are using RADIUS to transport
passwords and you have any doubts about the security of the network
device(s) or the security of RADIUS's transport. If you do have any
doubts, these can be addressed by having the end-points (user and
authentication server) exchange authentication information in a form
that doesn't require you to put any trust in RADIUS or the RADIUS
device. At which point you have something that looks a lot like
Kerberos. I don't know of any such mechanism implemented on top of
RADIUS. (Anyway, it seems pretty silly to have RADIUS "protecting"
Kerberos AS-REQ's and AS-REP's.). So you have to trust the devices.
Then again, Kerberos users have to trust whatever machine they type
their password at (i.e., whatever machine is running the "kinit"
program).
So how secure is RADIUS's transport? I'm not qualified to answer that,
as I'm not a crypto person. All I can say is what I know from the spec:
That it depends on a "well-chosen" key of "at least" 16-octets (this key
is shared between the network device and the server), and on MD5
(details below). It looks like the RADIUS devices also need a pretty
good random number generator to make this work.
The RADIUS specification also says nothing about key management or
protection. The administrative burden of key management could be
significant, and will vary between implementations. Given the lack of any
specification for changing keys in RADIUS, does this mean they all have to
be transported out-of-band every time you change them? For a large number
of devices, this could be a major headache (or you use the same keys
everywhere, which could be worse). Beware. Then again, Kerberos doesn't
say anything about key management. Same caveat ;-). But every Kerberos
implementation I know of provides some key management utilities. Also,
Kerberos provides for individual session keys, which RADIUS does not.
Does this imply that RADIUS keys stored in the devices need to be changed
more frequently? Maybe, but I doubt it. Again, a crypto person would
best render an opinion on that.
Would I trust a RADIUS device to transport my Kerberos password if that
device were not a part of my own realm's trusted environment (e.g., a
terminal server belonging to Fred's Internet Access Service)? No.
Would I trust a RADIUS device to transport my Kerberos password under
any conditions? Haven't decided.
I use "Kerberos password" to emphasize that Kerberos is a different
animal :), and--even if you use both RADIUS and Kerberos--the security
domains of RADIUS and Kerberos may not intersect. Kerberos has earned
people's trust by being in the field and having people beat on it for
some time; when something else is put in the authentication path, it is
treated with a great deal of skepticism. So if I were to use RADIUS and
Kerberos in the same environment, I'd probably have different passwords
for authentication through RADIUS and Kerberos. Same reason as having a
different password for your Unix login and Kerberos--because stock Unix
provides insufficient protection for the password (unless, of course,
you have a Kerberos-based single signon. :-) Then again, I'm not a
disinterested observer, and being paranoid (at least thinking that way)
is part of my job.
If I have a choice between end-to-end Kerberos (e.g., my network entry
is via PPP to a terminal server using a PC running TCP-IP with Kerberos
on it) or RADIUS (same configuration, sans Kerberos), which would I
choose? Kerberos wins, hands down--it does a lot more for me (end-to-
end authentication, mutual authentication, session key establishment,
secure services, etc.) and I don't have to trust the phone system.
However, I'm presuming that you want or need what Kerberos provides, and
I'm making a few assumptions about the configuration. The Kerberos
solution assumes that all hosts to which the terminal server has access
are running Kerberos services, and that those are the only services you'll
need. This may not be a reasonable assumption at your site. If it's host
access that is the problem, you can put a kerberized "firewall" between
the terminal server and the rest of your network. I use the term
"firewall" loosely, since we are talking about secure in- bound access,
and conventional (non-kerberized) firewalls are useless for that
purpose--with or without smart cards. (We're currently in the throes of
name-that-product for our own "kerberized firewall" product offering.) If
it's specific services you need, then you'll have to have kerberized
versions of those services; r-utils, telnet and ftp are becoming
commodities (although there are very few good implementations ;-))
Anything else may require some digging--or programming.
In nuts-and-bolts terms, RADIUS's ability to protect user's
authentication information (ok, their password) boils down to:
MD5( concatenate( X, A ) ) xor P
- P is the password being protected
- X is "at least" a 16-octet secret key shared between the
network device and server. I believe that this key should
fairly random.
- A is a 16-octet "authenticator" unique to each message,
and is generated by whichever end sends the message.
The authenticator should be "temporally and globally
unique" (good trick).
A is transmitted in the clear. We must also assume that an attacker knows
P (because they can choose one). That leaves the problem of coming up
with X. Making X longer should make an attack more difficult, which is
reasonable if you have a key management system that handles the keys for
you. Consider entering a a different 32 character hexadecimal number
at each of, say, 50 terminal servers. Ugh. (More characters if you
decide to use longer keys.)
Note that this attack is against the network device's key X, not a
specific user's key. (But once I've got the device's key, life is over
for anyone that uses that device.) I'm sure there are other attack paths
that are effective; this was simply the first (and simplest) technical
attack that came to mind.
Joe Kovara / Product Development Manager / CyberSAFE / joek@cybersafe.com
