Re: Placement of Strong Authentication Servers

["Paul D. Robertson" <proberts () clark net>]

On Mon, 1 Feb 1999, Matt McClung, CCSA/CCSE wrote:

> I haven't seen a discussion of your Strong Authentication Server on this
> list yet.  I am looking at installing a new Auth Server to provide strong
> user authentication.  My question is just where do you put it?

Depends quite a bit on the protocols, media and usage requirements.  I
won't allow external connections from the Internet into my firewall under
any circumstances, so I would require an internal auth. server and a
seperate external "extranet" auth. server.  Your premises may be very
different, and I don't tend to believe that every architechtural choice is
good for every scenerio.  MLS systems as authentication servers *could*
change my mind on this, but I only know of one I like and it's still under
evaluation.

[snip]

> I don't think that you would want that information traversing your internal
> network so that's why I would suggest the above configuration.

The information has to go from the client to the server no matter what.
The most important thing to remember about most "strong authentication"
servers is that (a) they aren't secure authentication servers, and (b) you
aren't always authenticating secure protocols.  That means that hijacking
the connection either during authentication or after a successful
authentication can be a significant risk.  Even if you go to a secure
connection, such as a VPN, if the authenticating end-node has
non-encrypted connections, tunneling out or masquerading out through the
now-authenticated pipe as the authenticating user becomes an issue.  To
me, what goes over an internal network with a topology I control is
*trivial* (and solvable for most cases of "good enough") compared to an
unathenticated or insecure client connecting from an untrusted network.

> This works great if you are only doing Internet/Extranet type
> authentication, but what do you do when you need to provide the same
> services for an inside service?

I believe highly in seperation of internal and external services, so to me
it makes the most sense to have (at the very least) an internal and
external authentication server to handle each one.  Common points of
architecture break the internal/external model too easily for my paranoia.

> Bandwidth, management and security measurements tell me the same
> configuration works well in most scenarios....

Security requirements, weak spots in things like shared media,
non-cryptographic or weak cryptographic connection mechanisms, and boundaries 
for services tend to make me leary of not providing an in-depth analysis
of each scenerio rather than trying to provide a blanket solution with a
single architecture.  

One person's "good enough" is another person's "never!"  Bandwidth for
authentication is trivial in any case I can think of that doesn't include
downloading extremely large biological mappings of the authentication
target.  

As far as "security measurements", I don't know what yard stick you're
using, but strong on-host, per-host authentication works well when you
have a trusted path, everything else is a usability or management
compromise, I don't think I'd tout them as security features.  

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () clark net      which may have no basis whatsoever in fact."
                                                                     PSB#9280