idnits 2.17.1 draft-calhoun-diameter-authent-06.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: ---------------------------------------------------------------------------- ** 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 53 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 54 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 are 20 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2432 has weird spacing: '... copied and ...' == Line 2433 has weird spacing: '...s, and deriv...' == Line 2434 has weird spacing: '...blished and...' == Line 2435 has weird spacing: '...ed, in whole...' == Line 2436 has weird spacing: '...hat the above...' == (5 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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: '11' is defined on line 2386, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2391, 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') -- Possible downref: Normative reference to a draft: ref. '5' -- 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-02 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-04) exists of draft-calhoun-diameter-proxy-02 -- Possible downref: Normative reference to a draft: ref. '13' Summary: 13 errors (**), 0 flaws (~~), 17 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Microsystems, Inc. 3 Title: draft-calhoun-diameter-authent-06.txt William Bulley 4 Date: August 1999 Merit Network, Inc. 6 DIAMETER 7 Dial-Up (ROAMOPS) Extensions 9 Status of this Memo 11 This document is an individual contribution for consideration by the 12 AAA Working Group of the Internet Engineering Task Force. Comments 13 should be submitted to the diameter@ipass.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document describes the DIAMETER Dial-up User Authentication 39 Extension that is used for ROAMOPS [4] purposes. This specification 40 was carefully designed to ease the burden of servers that must act as 41 RADIUS/DIAMETER gateways, by re-using the same address space that 42 RADIUS has defined [1]. Further, by re-using the same address space, 43 it allows a single server to read the same dictiionary for both 44 DIAMETER and RADIUS. This backward compatibility will hopefully 45 facilitate deployment of DIAMETER. 47 Table of Contents 49 1.0 Introduction 50 1.1 Requirements language 51 1.2 Changes in version -06 52 2.0 Command Codes 53 2.1 AA-Request (AAR) 54 2.2 AA-Answer (AAA) 55 2.3 AA-Challenge-Ind (ACI) 56 3.0 DIAMETER AVPs 57 3.1 User-Name 58 3.2 User-Password 59 3.3 CHAP-Password 60 3.4 NAS-Port 61 3.5 Service-Type 62 3.6 Framed-Protocol 63 3.7 Framed-IP-Address 64 3.8 Framed-IP-Netmask 65 3.9 Framed-Routing 66 3.10 Filter-Id 67 3.11 Framed-MTU 68 3.12 Framed-Compression 69 3.13 Login-IP-Host 70 3.14 Login-Service 71 3.15 Login-TCP-Port 72 3.16 Reply-Message 73 3.17 Callback-Number 74 3.18 Callback-Id 75 3.19 Framed-Route 76 3.20 Framed-IPX-Network 77 3.21 Idle-Timeout 78 3.22 Called-Station-Id 79 3.23 Calling-Station-Id 80 3.24 Login-LAT-Service 81 3.25 Login-LAT-Node 82 3.26 Login-LAT-Group 83 3.27 Framed-AppleTalk-Link 84 3.28 Framed-AppleTalk-Network 85 3.29 Framed-AppleTalk-Zone 86 3.30 CHAP-Challenge 87 3.31 NAS-Port-Type 88 3.32 Port-Limit 89 3.33 Login-LAT-Port 90 3.34 Filter-Rule 91 3.35 Framed-Password-Policy 92 3.36 Table of Attributes 93 4.0 Protocol Definition 94 4.1 Feature Advertisement/Discovery 95 4.2 Authorization Procedure 96 4.3 Integration with Resource-Management 97 5.0 References 98 6.0 Acknowledgements 99 7.0 Authors' Addresses 100 8.0 Full Copyright Statement 102 1.0 Introduction 104 This document describes the DIAMETER Dial-up User Authentication 105 Extension that is used for ROAMOPS [4] purposes. This specification 106 was carefully designed to ease the burden of servers that must act as 107 RADIUS/DIAMETER gateways, by re-using the same address space that 108 RADIUS has defined [1]. Further, by re-using the same address space, 109 it allows a single server to read the same dictiionary for both 110 DIAMETER and RADIUS. This backward compatibility will hopefully 111 facilitate deployment of DIAMETER. 113 The Extension number for this draft is one (1). This value is used in 114 the Extension-Id AVP as defined in [2]. 116 1.1 Copyright Statement 118 Copyright (C) The Internet Society 1999. All Rights Reserved. 120 1.2 Requirements language 122 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 123 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 124 described in [12]. 126 1.3 Changes in version -06 128 The following changes have been made to version 06: 130 - Changes to AVP Header Flags 132 - Change to the document title 134 - Changed the Command-Specific AVP Flags in all command codes 135 defined. 137 - Added a reference to RFC 1994 (CHAP) 139 2.0 Command Codes 141 This document defines the following DIAMETER Commands. All DIAMETER 142 implementations supporting this extension MUST support all of the 143 following commands: 145 Command Name Command Code 146 ----------------------------------- 147 AA-Request 263 148 AA-Answer 264 149 AA-Challenge-Ind 265 151 2.1 AA-Request (AAR) 153 Description 155 The AA-Request message is used in order to request authentication 156 and authorization for a given user. 158 If Authentication is requested the User-Name attribute MUST be 159 present. If only Authorization is required it is possible to 160 authorize based on DNIS and ANI instead. However, it is not 161 possible to authenticate using a User-Name AVP and later 162 requesting authorization based on DNIS using the same Session-Id 163 (although the inverse is legal). 165 Note that the flag field MAY be used in this command in order to 166 indicate that either Authentication-Only or Authorization-Only is 167 required for the request. If the Authentication-Only bit is set 168 the response MUST NOT include any authorization information. Both 169 the Authenticate and Authorize bits MUST NOT be set at the same 170 time. To ensure that a user is both authenticated and authorized, 171 neither flag is set. 173 The AA-Request message MUST include a unique Session-Id AVP. If 174 The AA-Request is a result of a successful AA-Challenge-Ind the 175 Session-Id MUST be identical to the one provided in the initial 176 AA-Request. 178 Message Format 180 Section 3.36 contains a complete list of all valid AVPs for this 181 message. 183 ::= 184 185 186 187 [] 188 [] 189 [] 190 [] 191 { || 192 194 195 196 { || 197 ::= 294 295 296 297 [] 298 299 [] 300 [] 301 [] 302 [] 303 [] 304 305 306 307 { || 308 401 402 403 404 [] 405 406 [] 407 [] 408 [] 409 [] 410 411 412 413 { || 414 2381 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 2382 (MP)", RFC 1717, November 1994. 2383 [10] Calhoun, Greene, "DIAMETER Resource Management Extension", 2384 draft-calhoun-diameter-res-mgmt-02.txt, Work in Progress, 2385 February 1999. 2386 [11] Calhoun, Zorn, Pan, "DIAMETER Framework", 2387 draft-calhoun-diameter-framework-02.txt, Work in Progress, 2388 December 1998. 2389 [12] S. Bradner, "Key words for use in RFCs to Indicate 2390 Requirement Levels", BCP 14, RFC 2119, March 1997. 2391 [13] P. Calhoun, W. Bulley, "DIAMETER Proxy Server Extensions", 2392 draft-calhoun-diameter-proxy-02.txt, Work in Progress, 2393 August 1999. 2395 6.0 Acknowledgements 2397 The Author wishes to thank Carl Rigney since much of the text in the 2398 document was shamefully copied from [1] as well as the following 2399 people for their help in the development of this protocol: 2401 Nancy Greene, Ryan Moats 2403 7.0 Authors' Addresses 2405 Questions about this memo can be directed to: 2407 Pat R. Calhoun 2408 Network and Security Research Center, Sun Labs 2409 Sun Microsystems, Inc. 2410 15 Network Circle 2411 Menlo Park, California, 94025 2412 USA 2414 Phone: 1-650-786-7733 2415 Fax: 1-650-786-6445 2416 E-mail: pcalhoun@eng.sun.com 2418 William Bulley 2419 Merit Network, Inc. 2420 4251 Plymouth Road, Suite C 2421 Ann Arbor, Michigan, 48105-2785 2422 USA 2424 Phone: 1-734-764-9993 2425 Fax: 1-734-647-3185 2426 E-mail: web@merit.edu 2428 8.0 Full Copyright Statement 2430 Copyright (C) The Internet Society (1999). All Rights Reserved. 2432 This document and translations of it may be copied and furnished to 2433 others, and derivative works that comment on or otherwise explain it 2434 or assist in its implmentation may be prepared, copied, published and 2435 distributed, in whole or in part, without restriction of any kind, 2436 provided that the above copyright notice and this paragraph are 2437 included on all such copies and derivative works. However, this docu- 2438 ment itself may not be modified in any way, such as by removing the 2439 copyright notice or references to the Internet Society or other Inter- 2440 net organizations, except as needed for the purpose of developing 2441 Internet standards in which case the procedures for copyrights defined 2442 in the Internet Standards process must be followed, or as required to 2443 translate it into languages other than English. The limited permis- 2444 sions granted above are perpetual and will not be revoked by the 2445 Internet Society or its successors or assigns. This document and the 2446 information contained herein is provided on an "AS IS" basis and THE 2447 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 2448 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 2449 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 2450 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2451 PARTICULAR PURPOSE."