Network Working Group Glen Zorn INTERNET-DRAFT Microsoft Corporation 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 , 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]