(RADIATOR) Testing help with new Kerberos5 Auth Module.

[Shumon Huque]

On Sat, Mar 27, 2004 at 01:20:36PM +1000, Mike McCauley wrote:
> Helo Steve,
> 
> 
> On Sat, 27 Mar 2004 11:53 am, Steve Harper wrote:
> > Hello, I work for the University of Utah where we have a site license for
> > Radiator.  I've written a Kerberos 5 Authentication module for Radiator
> > (AuthKRB5.pm) because of Authen::PAM's segfaulting on Solaris 2.8 and up.
> > Its based on AuthTEST.pm and AuthPAM.pm, and uses the CPAN Perl module
> > Authen::KRB5 V1.3 which requires MIT kerberos.
> >
> > I'm running this on Solaris 2.9, with Perl 5.8.1, MIT Kerberos 1.2.7, and
> > Radiator 3.9.
> 
> Ive just tested your module with ordinary Radius PAP, KRB5 1.2.7 and Authen 
> KRB5 1.3 and it works as you say. Nice work.

Hi Steve/Mike and others,

As currently written, your Kerberos authentication module suffers
from a security vulnerability, because you are not authenticating
the response from the KDC. Someone in collusion with an attacker
who fakes a response from the KDC could successfully authenticate
to this RADIUS module. In fact, there's a well known tool out 
there called "kdcspoof" by Dug Song that implements this attack.

In general it isn't sufficient to successfully acquire and decrypt 
the initial credentials from the KDC. You also need to use the initial 
ticket to acquire and verify credentials for an additional service
(eg. a local kerberos service whose secret key you possess.) 

Here's some relevant text from RFC 1510:

   Proper decryption of the KRB_AS_REP message is not sufficient to
   verify the identity of the user; the user and an attacker could
   cooperate to generate a KRB_AS_REP format message which decrypts
   properly but is not from the proper KDC.  If the host wishes to
   verify the identity of the user, it must require the user to present
   application credentials which can be verified using a securely-stored
   secret key.  If those credentials can be verified, then the identity
   of the user can be assured.

At Penn, we've also written a Kerberos authentication module for
Radiator, which we've been using for a number of years. In addition
to obtaining an initial ticket, it acquires credentials for a local
Kerberos service principal called "radius/f.q.d.n at REALM", and attempts 
to decrypt those credentials using the key for this principal. This
service principal and associated key are already setup on the KDC.
And the key for the principal is also stored in a local keytab file 
on the RADIUS server and is readable by the Radiator user.

It should be fairly straightforward to add the code to your module 
to perform the additional step. We could consider contributing our
module back to the Radiator folks also, but we'd have to clean it
up some, because it does a variety of other stuff (eg. returning
Penn specific VSA's as response attributes etc.)

----
Shumon Huque				3401 Walnut Street, Suite 221A,
Network Engineering			Philadelphia, PA 19104-6228, USA.
Information Systems & Computing		(215)898-2477, (215)898-9348 (Fax)
University of Pennsylvania / MAGPI.	E-mail: shuque at isc.upenn.edu

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.