Network Working Group Glen Zorn
INTERNET-DRAFT Microsoft Corporation
<draft-zorn-yaap-00.txt> 13 June 1996
YAAP: Yet Another Authentication Protocol
1. Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
zorn-yaap-00.txt>, and expires December 14, 1996. Please send com-
ments to the author.
2. Abstract
This document presents a straw-man set of requirements for a new pro-
tocol (YAAP) supporting authentication, authorization, accounting and
resource management for Network Access Server (NAS) users.
3. Rationale
3.1. Why a new protocol?
Although several protocols exist (RADIUS, TACACS+) which have the same
aims as YAAP, they all have problems. TACACS+ is widely perceived as
proprietary and RADIUS, though enjoying considerable current popular-
ity, seems to have been designed for a simpler world. Today's NAS
devices are not simply modem banks with brains: they are sophisticated
and often expensive machines which are expected to perform increas-
ingly sophisticated tasks. Given these facts, the time seems ripe to
start with a clean slate and design a protocol for today and tomorrow.
Zorn [Page 1]
INTERNET-DRAFT 13 June 1996
33..22.. WWhhyy nnoott jjuusstt eexxtteenndd RRAADDIIUUSS??
Good idea, if it can be managed. The RADIUS protocol has a few flaws
that are fundamental enough to present a puzzle to anyone who would
try to fix them through extensions, though: you would probably end up
with a new protocol anyway, so why not start from scratch and learn
from our mistakes, rather than patching them over?
33..22..11.. TThhee TTrroouubbllee wwiitthh RRAADDIIUUSS
Some of the problems with RADIUS are:
Lack of real multiprotocol support
Attributes for new protocols are added one at a time.
The attribute space is too small
Only 256 "official" attributes can be defined in RADIUS. Subtract
the experimental, implementation-specific and reserved attributes
and only 192 are left. This paucity of attributes engenders
lengthy debates over whether a new attribute should become part of
the official protocol.
No support for complex user services
Virtual Private Networks, dialup tunneling protocols, multilink
PPP...
Authorization is incomplete and insufficient
Authentication and authorization are mixed together
Sometimes it is convenient to be able to authorize a service for a
user based solely upon the user's claim of identity (e.g., start-
ing up a tunnel protocol, assuming that authentication will be
performed by the entity at the other end of the tunnel). RADIUS
insists upon authentication before authorization, however, since
authorization data is carried in the reply to a successful
authentication.
Resource management is unsupported
Accounting is unreliable and lacks update capability
All message exchanges are client-initiated
This prevents the server from taking proactive steps in response
to changing conditions.
All this should not be taken as an indictment of RADIUS; many smart
people have put a lot of effort into it and its current popularity
among users and vendors alike shows that it is definitely useful.
Zorn [Page 2]
INTERNET-DRAFT 13 June 1996
4. YAAP Requirements
The following list is very much a straw-man, gathered through conver-
sations and debates at IETF meetings, in email and elsewhere. It is
meant to be taken as a starting point and little else; comments and
constructive criticism will be highly valued.
A next-generation NAS protocol should:
1) Separate authentication, authorization and accounting
Authentication, authorization and accounting are different
things, with differing requirements. For example, the security
requirements for an accounting protocol are substantially differ-
ent for an accounting protocol than for an authentication proto-
col due to differences in the trust models.
2) Support NAS resource management
By resource management is meant things like the maximum number of
links in an MP bundle, amount of connect time allowed for a user,
etc. If these parameters change while a user session is active,
the client should be notified.
3) Be simple (as much so as is possible without compromising other
goals)
4) Be lightweight (ditto)
5) Be secure
Provision should be made for the selective encryption of
attributes, mutual authentication between server and client and
integrity protection of sensitive data (like accounting and
authorization messages). Multiple encryption mechanisms should
be supported, even within the same message, on an attribute-by-
attribute basis.
6) Be reliable, especially with respect to accounting data
To most network operators, accounting data is important: if
accounting data is lost, so is money. One way to help the relia-
bility of accounting would be to allow the NAS to hold accounting
data for later, polled retrieval by the accounting server. In
fact, given enough storage on the NAS itself, it would probably
be possible to eschew the development of an accounting protocol
altogether and just collect the data using something like HTTP.
7) Provide support for all levels of authentication, from simple to
strong
It's sometimes handy to be able to expressly accept the simple,
declarative, "I'm me" type of authentication without having to
play any "NULL password" games.
8) Support authorization/configuration 'suggestions' (e.g., LCP
parameters)
Zorn [Page 3]
INTERNET-DRAFT 13 June 1996
9) Be easily proxiable
10) Provide support for dialup roaming and other sophisticated
network services
11) Provide real support for multiple servers
12) Allow multiple message exchanges for authentication and autho-
rization
13) Support multiple authentication methods easily
At a minimum, YAAP should support everything supported by EAP.
14) Be transport independent
The protocol should work over both TCP and UDP.
15) Provide room for expansion in the attribute space
Type-length-value triples are a good way to represent almost any-
thing, but we must make sure that the type and length spaces are
large enough that they won't cripple the protocol. 16 bits is
probably a big enough; 64K provides a lot of room to spread out.
16) As much as possible, separate the protocol and payload specifica-
tions
Except for an absolute minimum, attributes should be defined out-
side of the protocol specification. A good idea is to encourage
the creation of new attributes by means of IANA registration and
the promulgation of an Informational RFC describing the new
attribute's semantics.
17) Promote the use of pre-defined or self-defining attribute identi-
fiers
I.e., IANA protocol numbers, vendor IDs, etc.
18) Use a single format for both standard and vendor-specific
attributes
Every attibute would include a vendor code; standard attributes
might be assigned the vendor code of zero. This simplifies pro-
cessing by eliminating a special case and allows for the easy
migration of generally useful attributes from the vendor-specific
space to the standard attribute space.
19) Allow unsolicited messages (including queries) to be sent from
the server to the NAS
This would allow the server to monitor the NAS and might be used
to solve most if not all of the problems associated with NAS
resource management.
20) Take design direction from the user (ISP and network operations)
community
Zorn [Page 4]
INTERNET-DRAFT 13 June 1996
5. Acknowledgements
The following people have all helped to suggest, refine or inspire the
ideas expressed in this document:
Bill Westfield
Lol Grant
Dave Nelson
Pat Calhoun
Carl Rigney
Dave Carrel
Andy Valencia
Ricky Li Fo Sjoe
Don Dumitru
Mike O'Dell
Cliff Neuman
6. Author's Address
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-703-1559
EMail: glennz@microsoft.com
Zorn [Page 5]