distributed authentication architecture framework

[John R. Vollbrecht]

FYI - John
-----
To: nas-req@merit.edu
Cc: jrv@merit.edu
Subject: distributed authentication/authorization framework for NAS
Date: Thu, 28 Oct 1993 18:18:09 -0400
From: "John R. Vollbrecht" <jrv@merit.edu>



This is to provide a framework for discussing ways to distribute the
processes which a NAS needs to perform at the time a Network Access
Client (NAC) requests connection.

This is written in the context of work done in the nasreq working group
of the ietf.

This is meant to provide input for discussion at the nasreq working
group in Houston next week - Tuesday at 4pm.


1. Cooperating routines

At authentication time the NAS supports two protocols which must interact.  
If we assume that in the NAS two different routines support the two 
protocols, then the picture would look something like this.


    ... | (NAC/NAS routine) <---->  (NAS/AuthServer routine) |... 


The NAC/NAS routine is responsible for negotiating and carrying out the
NAC/NAS protocol.  There might be different routines for PAP, CHAP, 
KAP*, PKAP*,and SCP* (* indicates that these have been proposed and 
discussed but not implemented or completely described as yet).

The NAS/AuthServer routine is responsible for sending requests to the
appropriate authentication server and interpreting and/or returning results
as appropriate.  The NAS/AuthServer routine might interact with 
Kerberos(v4 or v5), some Public Key certificate server, a host id-pw system, 
or perhaps a remote CHAP server.

The NAC/NAS routine will call the NAS/AuthServer routine when it needs
some information.  The required calls will be defined based on the needs
of the NAC/NAS routine.  While a number of calls may be defined to
support specific requirements for information, one call will always be
made by every NAC/NAS routine.  This will be a specific
authentication/authorization request.

The form of the authentication/authorization request may be different
for each NAC/NAS routine type.  That is the request may have different
number and type of arguments, but a authentication/authorization request
will always be made.  The form of the request will be something like the
following:

  authreq, id, <param- e.g. passwd> <capability req> .....

The request gives enough information to allow the appropriate
authentication to be done, and may add requests for specific capabilities
for which it needs authorization.

The NAS/AuthServer will respond to this request with a standard message.
That is, all NAS/AuthServer routines will respond to the
authentication/authorization request with the same style message.  The
form of the response will be:

  accept, <capability/restriction> ..... <capability/restriction>
  or
  reject, <reason>

The NAC/NAS routine will use this response to determine whether or not
the NAC is valid and what capabilities it is allowed to use.  (Note that
additional authorization information can be obtained by the NAS in
other ways to further qualify what the NAC is allowed to do.)

The mechanism described above allows the NAC/NAS routine to get
authentication and authorization information in a consistent way from
all NAS/AuthServ routines.

It is important to note that not all NAC/NAS protocols are able to get
information from all NAS/AuthServer routines.  The NAS/AuthServer
routines will be different for each NAC/NAS protocol/Authentication
Sever protocol combination.  

Thus there will be NAS/AuthServer routines which accept PAP calls and
interact with Kerberos, Public Key certificate systems, or Unix password
systems.  A task that needs to be done more carefully that I have done
so far is to define what each of these routines will actually do.  Still
it seems that there will be the following NAS/AuthServer routines, and
probably more.

	PAP/Kerberos
	PAP/Public Key
	PAP/Unix pw
	PAP/remote CHAP

	CHAP/remote CHAP

	KAP/Kerberos

	PKAP/Public Key

	SCAP/Smart Card



2. Selecting a NAS/AuthServer routine

When a NAS has more than one NAS/AuthServ routine that could be used,
the NAC/NAS routine must have a way to decide which of them to use.
There are a number of ways this could be done, depending on the
environment of the NAS.  

One appoach would be to have a single NAS/AuathServ for each type of
NAC/NAS authentication.  So there would be one for PAP, one for CHAP,
etc.  

A more interesting way would be have the id include an authentication
realm.  For example, rather than an id of jrv I might use jrv@umich.edu
or jrv@hack.merit.edu.  Then the NAS could have a table that associates
a NAS/AuthServ routine with each authentication realm.


2. Distributing the routines

The calls to NAS/AuthServer routines can be local or via an rpc 
mechanism to a process running on a remote machine.  When the
NAS/AuthServer routine runs on a remote server we have taken to calling
this routine a NAS "helper".

The protocol to support the rpc has been called the NAS/helper protocol.
A NAS/helper protocol rfc is being worked on to to define a standard
protocol so that any NAS could talk to any helper.

The protocol must be able to encrypt fields (especially the pw if it 
must be sent), and sign messages so the both sides can trust that they 
know the sender.  More requirements are being spelled out by the 
subgroup working on the NAS/helper rpc protocol.

In order to have secure communication between between NAS and helper
they will need to have a shared secret.   This could be configured, but
more likely would be obtained from a Kerberos server on which both were
registered.

Having the NAS/AuthServ routines on a helper is a good idea if the
number of routines to be supported gets large.  The helper can be a Unix
platform with lots of memory and CPU while the NAS may want to be a much
more lean machine.

3. Adding more helpers

Given that an rpc protocol is used to pass calls and responses, and that
an authentication realm is used as the way to select which NAS/AuthServ
routine will be called by the NAC/NAS routine, it would be possible to
relay protocol messages between helpers.  For example, it would be
possible to have a structure of helpers as shown below.

  NAC -- NAS ** helperA ** helperB ** helperC -- authentication-server

The NAC and NAS interact with a PPP authentication protocol.  The
NAC/NAS routine in the NAS does rpc calls with the NAS/AuthServer
routine in helperC.  helperA and helperB forward the rpc protocol
messages to the next helper, based on a table showing the "next step"
to get to the routing domain's NAS/AuthServ routine.  

Each of the NAS-helper and helper-helper links has a secret shared by
each end that allows encrypting of fields (pws) and signing of messages.
At each step the message signature needs to be checked and encrypted
fields decrypted before encrypting and signing and sending to the next
step.

This mechanism might be useful in building fairly large systems of
authentication servers.  Discussion of how this might be done is left
for a follow on writeup.


4. Summary

This has described the interactions between NAC and NAS and those
between NAS and Authentication Server as being managed by two different
processes.  The processes communicate with procedure calls.  By
implementing an appropriate remote procedure protocol the processes can
be run on separate machines.

By adding an appropriate "next Step" lookup to determine where the rpc
information should be passed next, the procedures could be on a number
of different machines.

A rpc relay could also be effected by using the "next Step" table
mechanism.  Such a relay capability could allow some fairly
sophisticated distributed authentication domains to be implemented.
Discussion of such domains is left for a follow on document.








------- End of Forwarded Message

- - - - - - - - - - - - - - - - -