idnits 2.17.1 draft-zorn-yaap-01.txt: ** The Status of Memo section seems to be numbered ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 56 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 87 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...), its areas...' == Line 12 has weird spacing: '... its worki...' == Line 16 has weird spacing: '... and may ...' == Line 17 has weird spacing: '...afts as refer...' == Line 20 has weird spacing: '... To learn...' == (51 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (30 June 1996) is 10162 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Glen Zorn 3 INTERNET-DRAFT Microsoft Corporation 4 30 June 1996 6 YAAP: Yet Another Authentication Protocol 8 1. Status of This Memo 10 This document is an Internet-Draft. Internet-Drafts are working docu- 11 ments of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute work- 13 ing documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference mate- 18 rial or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 The distribution of this memo is unlimited. It is filed as , and expires January 4, 199&. Please send comments 27 to the author. 29 2. Abstract 31 This document presents a straw-man set of requirements for a new pro- 32 tocol (YAAP) supporting authentication, authorization, accounting and 33 resource management for Network Access Server (NAS) users. 35 3. Rationale 37 3.1. Why a new protocol? 39 Although several protocols exist (RADIUS, TACACS+) which have the same 40 aims as YAAP, they all have problems. TACACS+ is widely perceived as 41 proprietary and RADIUS, though enjoying considerable current popular- 42 ity, seems to have been designed for a simpler world. Today's NAS 43 devices are not simply modem banks with brains: they are sophisticated 44 and often expensive machines which are expected to perform increas- 45 ingly sophisticated tasks. Given these facts, the time seems ripe to 46 start with a clean slate and design a protocol for today and tomorrow. 48 3.2. Why not just extend RADIUS? 50 Good idea, if it can be managed. The RADIUS protocol has a few flaws 51 that are fundamental enough to present a puzzle to anyone who would 52 try to fix them through extensions, though: you would probably end up 53 with a new protocol anyway, so why not start from scratch and learn 54 from our mistakes, rather than patching them over? 56 3.2.1. The Trouble with RADIUS 58 Some of the problems with RADIUS are: 60 Lack of real multiprotocol support 61 Attributes for new protocols are added one at a time. 63 The attribute space is too small 64 Only 256 "official" attributes can be defined in RADIUS. Subtract 65 the experimental, implementation-specific and reserved attributes 66 and only 192 are left. This paucity of attributes engenders 67 lengthy debates over whether a new attribute should become part of 68 the official protocol. 70 No support for complex user services 71 Virtual Private Networks, dialup tunneling protocols, multilink 72 PPP... 74 Authorization is incomplete and insufficient 76 Authentication and authorization are mixed together 77 Sometimes it is convenient to be able to authorize a service for a 78 user based solely upon the user's claim of identity (e.g., start- 79 ing up a tunnel protocol, assuming that authentication will be 80 performed by the entity at the other end of the tunnel). RADIUS 81 insists upon authentication before authorization, however, since 82 authorization data is carried in the reply to a successful 83 authentication. 85 Resource management is unsupported 87 Accounting is unreliable and lacks update capability 89 All message exchanges are client-initiated 90 This prevents the server from taking proactive steps in response 91 to changing conditions. 93 All this should not be taken as an indictment of RADIUS; many smart 94 people have put a lot of effort into it and its current popularity 95 among users and vendors alike shows that it is definitely useful. 97 4. YAAP Requirements 99 The following list is very much a straw-man, gathered through conver- 100 sations and debates at IETF meetings, in email and elsewhere. It is 101 meant to be taken as a starting point and little else; comments and 102 constructive criticism will be highly valued. 104 A next-generation NAS protocol should: 106 1) Separate authentication, authorization and accounting 107 Authentication, authorization and accounting are different 108 things, with differing requirements. For example, the security 109 requirements for an accounting protocol are substantially differ- 110 ent for an accounting protocol than for an authentication proto- 111 col due to differences in the trust models. 113 2) Support NAS resource management 114 By resource management is meant things like the maximum number of 115 links in an MP bundle, amount of connect time allowed for a user, 116 etc. If these parameters change while a user session is active, 117 the client should be notified. 119 3) Be simple (as much so as is possible without compromising other 120 goals) 122 4) Be lightweight (ditto) 124 5) Be secure 125 Provision should be made for the selective encryption of 126 attributes, mutual authentication between server and client and 127 integrity protection of sensitive data (like accounting and 128 authorization messages). Multiple encryption mechanisms should 129 be supported, even within the same message, on an attribute-by- 130 attribute basis. 132 6) Be reliable, especially with respect to accounting data 133 To most network operators, accounting data is important: if 134 accounting data is lost, so is money. One way to help the relia- 135 bility of accounting would be to allow the NAS to hold accounting 136 data for later, polled retrieval by the accounting server. In 137 fact, given enough storage on the NAS itself, it would probably 138 be possible to eschew the development of an accounting protocol 139 altogether and just collect the data using something like HTTP. 141 7) Provide support for all levels of authentication, from simple to 142 strong 143 It's sometimes handy to be able to expressly accept the simple, 144 declarative, "I'm me" type of authentication without having to 145 play any "NULL password" games. 147 8) Support authorization/configuration 'suggestions' (e.g., LCP 148 parameters) 150 9) Be easily proxiable 152 10) Provide support for dialup roaming and other sophisticated 153 network services 155 11) Provide real support for multiple servers 157 12) Allow multiple message exchanges for authentication and autho- 158 rization 160 13) Support multiple authentication methods easily 161 At a minimum, YAAP should support everything supported by EAP. 163 14) Be transport independent 164 The protocol should work over both TCP and UDP. 166 15) Provide room for expansion in the attribute space 167 Type-length-value triples are a good way to represent almost any- 168 thing, but we must make sure that the type and length spaces are 169 large enough that they won't cripple the protocol. 16 bits is 170 probably a big enough; 64K provides a lot of room to spread out. 172 16) As much as possible, separate the protocol and payload specifica- 173 tions 174 Except for an absolute minimum, attributes should be defined out- 175 side of the protocol specification. A good idea is to encourage 176 the creation of new attributes by means of IANA registration and 177 the promulgation of an Informational RFC describing the new 178 attribute's semantics. 180 17) Promote the use of pre-defined or self-defining attribute identi- 181 fiers 182 I.e., IANA protocol numbers, vendor IDs, etc. 184 18) Use a single format for both standard and vendor-specific 185 attributes 186 Every attibute would include a vendor code; standard attributes 187 might be assigned the vendor code of zero. This simplifies pro- 188 cessing by eliminating a special case and allows for the easy 189 migration of generally useful attributes from the vendor-specific 190 space to the standard attribute space. 192 19) Allow unsolicited messages (including queries) to be sent from 193 the server to the NAS 194 This would allow the server to monitor the NAS and might be used 195 to solve most if not all of the problems associated with NAS 196 resource management. 198 20) Take design direction from the user (ISP and network operations) 199 community 201 5. Acknowledgements 203 The following people have all helped to suggest, refine or inspire the 204 ideas expressed in this document: 205 Bill Westfield 206 Lol Grant 207 Dave Nelson 208 Pat Calhoun 209 Carl Rigney 210 Dave Carrel 211 Andy Valencia 212 Ricky Li Fo Sjoe 213 Don Dumitru 214 Mike O'Dell 215 Cliff Neuman 217 6. Author's Address 219 Glen Zorn 220 Microsoft Corporation 221 One Microsoft Way 222 Redmond, WA 98052 224 Phone: 206-703-1559 225 EMail: glennz@microsoft.com