idnits 2.17.1 draft-calhoun-diameter-authent-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 52 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 53 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '... MUST This word, or the adject...' RFC 2119 keyword, line 130: '... MUST NOT This phrase means that t...' RFC 2119 keyword, line 133: '... SHOULD This word, or the adject...' RFC 2119 keyword, line 139: '... MAY This word, or the adject...' RFC 2119 keyword, line 141: '...hich does not include this option MUST...' (194 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 2369, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 2395, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-08 -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2486 (ref. '3') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '4') == Outdated reference: A later version (-03) exists of draft-calhoun-diameter-eap-01 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1717 (ref. '9') (Obsoleted by RFC 1990) == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-02 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-01 -- Possible downref: Normative reference to a draft: ref. '11' Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-authent-05.txt William Bulley 5 Date: February 1999 Merit Network, Inc. 7 DIAMETER 8 User Authentication Extensions 10 Status of this Memo 12 This document is an individual contribution for consideration by the 13 AAA Working Group of the Internet Engineering Task Force. Comments 14 should be submitted to the diameter@ipass.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Abstract 39 DIAMETER is a Policy and AAA protocol which can be used for a variety 40 of services. This document defines DIAMETER messages that are used 41 for the authentication, authorization and accounting of users. 43 A considerable amount of effort was put into the design of this 44 protocol to ensure that an implementation could support both DIAMETER 45 and RADIUS concurrently. 47 Table of Contents 49 1.0 Introduction 50 1.1 Specification of Requirements 51 2.0 Command Codes 52 2.1 AA-Request 53 2.2 AA-Answer 54 2.3 AA-Challenge-Ind 55 3.0 DIAMETER AVPs 56 3.1 User-Name 57 3.2 User-Password 58 3.3 CHAP-Password 59 3.4 NAS-Port 60 3.5 Service-Type 61 3.6 Framed-Protocol 62 3.7 Framed-IP-Address 63 3.8 Framed-IP-Netmask 64 3.9 Framed-Routing 65 3.10 Filter-Id 66 3.11 Framed-MTU 67 3.12 Framed-Compression 68 3.13 Login-IP-Host 69 3.14 Login-Service 70 3.15 Login-TCP-Port 71 3.16 Reply-Message 72 3.17 Callback-Number 73 3.18 Callback-Id 74 3.19 Framed-Route 75 3.20 Framed-IPX-Network 76 3.21 Idle-Timeout 77 3.22 Called-Station-Id 78 3.23 Calling-Station-Id 79 3.24 Login-LAT-Service 80 3.25 Login-LAT-Node 81 3.26 Login-LAT-Group 82 3.27 Framed-AppleTalk-Link 83 3.28 Framed-AppleTalk-Network 84 3.29 Framed-AppleTalk-Zone 85 3.30 CHAP-Challenge 86 3.31 NAS-Port-Type 87 3.32 Port-Limit 88 3.33 Login-LAT-Port 89 3.34 Filter-Rule 90 3.35 Framed-Password-Policy 91 3.36 Table of Attributes 92 4.0 Protocol Definition 93 4.1 Feature Advertisement/Discovery 94 4.2 Authorization Procedure 95 4.3 Integration with Resource-Management 96 4.4 RADIUS Proxies 97 4.5 DIAMETER Proxies 98 4.6 Domain Discovery 99 5.0 References 100 6.0 Acknowledgements 101 7.0 Authors' Addresses 103 1.0 Introduction 105 This document describes the DIAMETER User Authentication Extensions 106 that can be used for a variety of services including Dial-up users 107 via NAS, WWW User Authentication, Firewall User Authentication[5][6]. 109 This document describes Authentication/Authorization messages as well 110 as a set of messages which allow DIAMETER hosts to bypass proxies. 112 Since Most of the AVPs found in this document was copied from the 113 RADIUS protocol[1], it is possible to have both RADIUS and DIAMETER 114 servers read the same dictionary and users files. The backward 115 compatibility that DIAMETER offers is intended to facilitate 116 deployment. 118 The Extension number for this draft is one (1). This value is used in 119 the Extension-Id AVP as defined in [2]. 121 1.1 Specification of Requirements 123 In this document, several words are used to signify the requirements 124 of the specification. These words are often capitalized. 126 MUST This word, or the adjective "required", means that the 127 definition is an absolute requirement of the 128 specification. 130 MUST NOT This phrase means that the definition is an absolute 131 prohibition of the specification. 133 SHOULD This word, or the adjective "recommended", means that 134 there may exist valid reasons in particular circumstances 135 to ignore this item, but the full implications must be 136 understood and carefully weighed before choosing a 137 different course. 139 MAY This word, or the adjective "optional", means that this 140 item is one of an allowed set of alternatives. An 141 implementation which does not include this option MUST 142 be prepared to interoperate with another implementation 143 which does include the option. 145 2.0 Command Codes 147 This document defines the following DIAMETER Commands. All DIAMETER 148 implementations supporting this extension MUST support all of the 149 following commands: 151 Command Name Command Code 152 ----------------------------------- 153 AA-Request 263 154 AA-Answer 264 155 AA-Challenge-Ind 265 157 2.1 AA-Request (AAR) 159 Description 161 The AA-Request message is used in order to request authentication 162 and authorization for a given user. 164 If Authentication is requested the User-Name attribute MUST be 165 present. If only Authorization is required it is possible to 166 authorize based on DNIS and ANI instead. However, it is not 167 possible to authenticate using a User-Name AVP and later 168 requesting authorization based on DNIS using the same Session-Id 169 (although the inverse is legal). 171 Note that the flag field MAY be used in this command in order to 172 indicate that either Authentication-Only or Authorization-Only is 173 required for the request. If the Authentication-Only bit is set 174 the response MUST NOT include any authorization information. Both 175 the Authenticate and Authorize bits MUST NOT be set at the same 176 time. To ensure that a user is both authenticated and authorized, 177 neither flag is set. 179 The AA-Request message MUST include a unique Session-Id AVP. If 180 The AA-Request is a result of a successful AA-Challenge-Ind the 181 Session-Id MUST be identical to the one provided in the initial 182 AA-Request. 184 Message Format 186 Section 3.36 contains a complete list of all valid AVPs for this 187 message. 189 ::= 190 191 192 193 [] 194 [] 195 [] 196 [] 197 { || 198 200 201 202 { || 203 ::= 294 295 296 297 [] 298 299 [] 300 [] 301 [] 302 [] 303 [] 304 305 306 307 { || 308 397 398 399 400 [] 401 402 [] 403 [] 404 [] 405 [] 406 407 408 409 { || 410 2388 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 2389 (MP)", RFC 1717, November 1994. 2391 [10] Calhoun, Greene, "DIAMETER Resource Management Extension", 2392 draft-calhoun-diameter-res-mgmt-02.txt, Work in Progress, 2393 February 1999. 2395 [11] Calhoun, Zorn, Pan, "DIAMETER Framework", 2396 draft-calhoun-diameter-framework-01.txt, Work in Progress, 2397 December 1998. 2399 6.0 Acknowledgements 2401 The Author wishes to thank Carl Rigney since much of the text in the 2402 document was shamefully copied from [1] as well as the following 2403 people for their help in the development of this protocol: 2405 Nancy Greene, Ryan Moats 2407 7.0 Authors' Addresses 2409 Questions about this memo can be directed to: 2411 Pat R. Calhoun 2412 Network and Security Research Center, Sun Labs 2413 Sun Microsystems, Inc. 2414 15 Network Circle 2415 Menlo Park, California, 94025 2416 USA 2418 Phone: 1-650-786-7733 2419 Fax: 1-650-786-6445 2420 E-mail: pcalhoun@eng.sun.com 2422 William Bulley 2423 Merit Network, Inc. 2424 4251 Plymouth Road, Suite C 2425 Ann Arbor, Michigan, 48105-2785 2426 USA 2428 Phone: 1-734-764-9993 2429 Fax: 1-734-647-3185 2430 E-mail: web@merit.edu