Great Circle Associates Firewalls
(April 1994)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Mixing Authentification Strategies
From: sangster @ reston . ans . net (Paul Sangster)
Date: Mon, 11 Apr 1994 11:03:12 +0500
To: firewalls @ greatcircle . com

 
Steve Simmons <scs @
 lokkur .
 dexter .
 mi .
 us> writes:

|> I've been looking at skey, one-time pads, etc.  One issue which doesn't
|> seem to be addressed is the mixing of authentication types.  For example,
|> inside a reasonably secure net one might chose to use `ordinary' unix
|> authentication.  When accessing from outside, one might want to normally
|> use skey, but fall back to a set of memorized one-time passwords if no
|> local/trustworthy skey generator is available.
|> 
|> The trick is how to decide on the fly which to use.  Alternate ports for
|> alternate authentications involves excessive memorization.  What I'd do
|> if I were recoding login.c is to let one modify the login id to indicate
|> desired authentication type:
|> 
|>    login: scs                # system default
|>    login: scs/skey   # skey
|>    login: scs/onetime        # one-time list
|>    login: scs/unix   # normal unix
|>    login: scs/whatever       # local custom job
 
Its seems like if you allow "scs" to have many different authentication
schemes available, the weakest form is the one which hackers will try to
attack.  Since it only takes 1 time using the "ordinary" unix password for
the password to be sniffed, I wonder if this is what you really want.  (This
partly comes down to user education issue, since many users if given the
opportunity will just choose the easiest authentication form which is
frequently also the easiest to attack, passwords.)  I guess what I am saying
is if you are going to go the extra mile for stronger authentication, you
should pick one you will always be confortable with and don't leave the
old door open.
 
|> 
|> A good implementation would refuse to do the wrong thing, eg, not permit
|> scs/unix from locations known to be outside the secured facility. If
|> anybody's thought seriously about the virtues of this or has other
|> solutions, I'd love to hear it.
 
On the InterLock, we tried to address some of these authentication mix
issue.  The approach we settled on was to provide maximum flexibility to
allow the customer to define (in our access control rule base) their
authentication policy.  What this means is that as part of each rule, the
administrator defines that "sangster" when he is connecting from a machine
(or net) on the protected network outbound will be authenticated using
standard unix passwords.  Likewise, the admin can have another rule saying
"sangster" when coming from the Internet will be required to use SecurId.
Currently we only support SecurId, Pinpad (from Security Dynamics) and the
use (or absense from protected side) of a unix password.  We also support
combinations of these authentication schemes, so you can define multiple
schemes be used on a connection (if desired) and the order which they will
occur.
 
Our changes to dynamically select and enforce the authentication policy are
to our gateways for ftp and telnet as well as in the login daemon.  This may
not be practical for admins trying to build their own firewalls, but since
were in that business ... :-).  In order to get full flexibility of
orderings, authentication schemes and tie it to connection direction it seems
reasonable and most secure to make the changes at the earliest point of entry
(the daemons).
 
However, if thats not practical you can still do some powerful things using
shell replacement.  For example, Security Dynamics has you replace your
initial shell with a special SDI card prompting shell which handles the
authentication I/O and talking with their ACE server.  Then after you are
authorized to login it runs your normal shell for you.
 
Paul
____________________________________________________________________________
                                Paul Sangster 
Advanced Network & Services                          Software Engineer
1875 Campus Commons Dr.                              sangster @
 reston .
 ans .
 net
Suite 220,  Reston VA 22091                          (703) 758-7706
____________________________________________________________________________

Indexed By Date Previous: Re: system() -> Mosaic
From: dotytr @ nscultrix2 . network . com (Ted Doty)
Next: Re: X3270 through firewall
From: sangster @ reston . ans . net (Paul Sangster)
Indexed By Thread Previous: Re: Mixing Authentification Strategies
From: alastair @ cadence . com (Alastair Young)
Next: Re: INN on a Firewall vs Socks proxy NNTP
From: Brent Chapman <brent @ mycroft . GreatCircle . COM>

Google
 
Search Internet Search www.greatcircle.com