idnits 2.17.1 draft-calhoun-diameter-authent-08.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 21 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 2416 has weird spacing: '... copied and ...' == Line 2417 has weird spacing: '...s, and deriv...' == Line 2418 has weird spacing: '...blished and...' == Line 2419 has weird spacing: '...ed, in whole...' == Line 2420 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) == Missing Reference: '25' is mentioned on line 1893, but not defined == Unused Reference: '11' is defined on line 2344, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2350, 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' ** Downref: Normative reference to an Informational RFC: RFC 2637 (ref. '14') ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '15') ** Obsolete normative reference: RFC 2373 (ref. '17') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2401 (ref. '18') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 1827 (ref. '21') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '22') ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '23') ** Obsolete normative reference: RFC 1700 (ref. '24') (Obsoleted by RFC 3232) Summary: 21 errors (**), 0 flaws (~~), 18 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-08.txt William Bulley 4 Date: October 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 Copyright Statement 51 1.2 Requirements language 52 1.3 Changes in version -06 53 1.4 Changes in version -07 54 2.0 Command Codes 55 2.1 AA-Request (AAR) 56 2.2 AA-Answer (AAA) 57 2.3 AA-Challenge-Ind (ACI) 58 3.0 DIAMETER AVPs 59 3.1 User-Name 60 3.2 User-Password 61 3.3 CHAP-Password 62 3.4 NAS-Port 63 3.5 Service-Type 64 3.6 Framed-Protocol 65 3.7 Framed-IP-Address 66 3.8 Framed-IP-Netmask 67 3.9 Framed-Routing 68 3.10 Filter-Id 69 3.11 Framed-MTU 70 3.12 Framed-Compression 71 3.13 Login-IP-Host 72 3.14 Login-Service 73 3.15 Login-TCP-Port 74 3.16 Reply-Message 75 3.17 Callback-Number 76 3.18 Callback-Id 77 3.19 Framed-Route 78 3.20 Framed-IPX-Network 79 3.21 Idle-Timeout 80 3.22 Called-Station-Id 81 3.23 Calling-Station-Id 82 3.24 Login-LAT-Service 83 3.25 Login-LAT-Node 84 3.26 Login-LAT-Group 85 3.27 Framed-AppleTalk-Link 86 3.28 Framed-AppleTalk-Network 87 3.29 Framed-AppleTalk-Zone 88 3.30 CHAP-Challenge 89 3.31 NAS-Port-Type 90 3.32 Port-Limit 91 3.33 Login-LAT-Port 92 3.34 Tunnel-Type 93 3.35 Tunnel-Medium-Type 94 3.36 Tunnel-Client-Endpoint 95 3.37 Tunnel-Server-Endpoint 96 3.38 Tunnel-Password 97 3.39 Tunnel-Private-Group-ID 98 3.40 Tunnel-Assignment-ID 99 3.41 Tunnel-Preference 100 3.42 Tunnel-Client-Auth-ID 101 3.43 Tunnel-Server-Auth-ID 102 3.44 Filter-Rule 103 3.46 Table of AVPs 104 4.0 Protocol Definition 105 4.1 Feature Advertisement/Discovery 106 4.2 Authorization Procedure 107 4.3 Integration with Resource-Management 108 5.0 References 109 6.0 Acknowledgements 110 7.0 Authors' Addresses 111 8.0 Full Copyright Statement 113 1.0 Introduction 115 This document describes the DIAMETER Dial-up User Authentication 116 Extension that is used for ROAMOPS [4] purposes. This specification 117 was carefully designed to ease the burden of servers that must act as 118 RADIUS/DIAMETER gateways, by re-using the same address space that 119 RADIUS has defined [1]. Further, by re-using the same address space, 120 it allows a single server to read the same dictiionary for both 121 DIAMETER and RADIUS. This backward compatibility will hopefully 122 facilitate deployment of DIAMETER. 124 The Extension number for this draft is one (1). This value is used in 125 the Extension-Id AVP as defined in [2]. 127 1.1 Copyright Statement 129 Copyright (C) The Internet Society 1999. All Rights Reserved. 131 1.2 Requirements language 133 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 134 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 135 described in [12]. 137 1.3 Changes in version -06 138 The following changes have been made to version 06: 140 - Changes to AVP Header Flags 142 - Change to the document title 144 - Changed the Command-Specific AVP Flags in all command codes 145 defined. 147 - Added a reference to RFC 1994 (CHAP) 149 1.4 Changes in version -07 151 The following changes have been made to version 07: 153 - Changed the Filter-Rule AVP from 280 to 300 155 - Changed the Framed-Password-Policy AVP from 280 to 301 157 1.5 Changes in version -08 159 The following changes have been mde to version 08: 161 - Removed the Framed-Password-Policy AVP since it is no longer 162 needed with the removal of the DDR/DDA commands. 164 - Fixed up the text in most of all AVPs where the statement 165 introducing the AVP format was present prior to the header. 167 - Added the various AVPs necessary to support Tunneling. 169 2.0 Command Codes 171 This document defines the following DIAMETER Commands. All DIAMETER 172 implementations supporting this extension MUST support all of the 173 following commands: 175 Command Name Command Code 176 ----------------------------------- 177 AA-Request 263 178 AA-Answer 264 179 AA-Challenge-Ind 265 181 2.1 AA-Request (AAR) 182 Description 184 The AA-Request message is used in order to request authentication 185 and authorization for a given user. 187 If Authentication is requested the User-Name attribute MUST be 188 present. If only Authorization is required it is possible to 189 authorize based on DNIS and ANI instead. However, it is not 190 possible to authenticate using a User-Name AVP and later 191 requesting authorization based on DNIS using the same Session-Id 192 (although the inverse is legal). 194 Note that the flag field MAY be used in this command in order to 195 indicate that either Authentication-Only or Authorization-Only is 196 required for the request. If the Authentication-Only bit is set 197 the response MUST NOT include any authorization information. Both 198 the Authenticate and Authorize bits MUST NOT be set at the same 199 time. To ensure that a user is both authenticated and authorized, 200 neither flag is set. 202 The AA-Request message MUST include a unique Session-Id AVP. If 203 The AA-Request is a result of a successful AA-Challenge-Ind the 204 Session-Id MUST be identical to the one provided in the initial 205 AA-Request. 207 Message Format 209 Section 3.46 contains a complete list of all valid AVPs for this 210 message. 212 ::= 213 214 215 216 [] 217 [] 218 [] 219 [] 220 { || 221 223 224 225 { || 226 ::= 289 290 291 292 [] 293 294 [] 295 [] 296 [] 297 [] 298 [] 299 300 301 302 { || 303 365 366 367 368 [] 369 370 [] 371 [] 372 [] 373 [] 374 375 376 377 { || 378 2339 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 2340 (MP)", RFC 1717, November 1994. 2341 [10] Calhoun, Greene, "DIAMETER Resource Management Extension", 2342 draft-calhoun-diameter-res-mgmt-02.txt, Work in Progress, 2343 February 1999. 2344 [11] Calhoun, Zorn, Pan, "DIAMETER Framework", 2345 draft-calhoun-diameter-framework-02.txt, Work in Progress, 2346 December 1998. 2348 [12] S. Bradner, "Key words for use in RFCs to Indicate 2349 Requirement Levels", BCP 14, RFC 2119, March 1997. 2350 [13] P. Calhoun, W. Bulley, "DIAMETER Proxy Server Extensions", 2351 draft-calhoun-diameter-proxy-02.txt, Work in Progress, 2352 August 1999. 2353 [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 2354 Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", 2355 RFC 2637, July 1999 2356 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two 2357 Forwarding (Protocol) 'L2F'", RFC 2341, May 1998 2358 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., 2359 Zorn, G., Palter, B., "Layer Two Tunnelling Protocol 2360 (L2TP)", RFC 2661, August 1999 2361 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", 2362 RFC 2107, February 1997 2363 [18] Kent, S., Atkinson, R., "Security Architecture for the 2364 Internet Protocol", RFC 2401, November 1998 2365 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, 2366 October 1996 2367 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 2368 October 1996 2369 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", 2370 RFC 1827, August 1995 2371 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic 2372 Routing Encapsulation (GRE)", RFC 1701, October 1994 2373 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 2374 [24] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, 2375 RFC 1700, October 1994 2376 [17] Hinden, R., Deering, S., "IP Version 6 Addressing 2377 Architecture", RFC 2373, July 1998 2379 6.0 Acknowledgements 2381 The Author wishes to thank Carl Rigney since much of the text in the 2382 document was shamefully copied from [1] as well as the following 2383 people for their help in the development of this protocol: 2385 Nancy Greene, Ryan Moats 2387 7.0 Authors' Addresses 2389 Questions about this memo can be directed to: 2391 Pat R. Calhoun 2392 Network and Security Research Center, Sun Labs 2393 Sun Microsystems, Inc. 2394 15 Network Circle 2395 Menlo Park, California, 94025 2396 USA 2398 Phone: 1-650-786-7733 2399 Fax: 1-650-786-6445 2400 E-mail: pcalhoun@eng.sun.com 2402 William Bulley 2403 Merit Network, Inc. 2404 4251 Plymouth Road, Suite C 2405 Ann Arbor, Michigan, 48105-2785 2406 USA 2408 Phone: 1-734-764-9993 2409 Fax: 1-734-647-3185 2410 E-mail: web@merit.edu 2412 8.0 Full Copyright Statement 2414 Copyright (C) The Internet Society (1999). All Rights Reserved. 2416 This document and translations of it may be copied and furnished to 2417 others, and derivative works that comment on or otherwise explain it 2418 or assist in its implmentation may be prepared, copied, published and 2419 distributed, in whole or in part, without restriction of any kind, 2420 provided that the above copyright notice and this paragraph are 2421 included on all such copies and derivative works. However, this docu- 2422 ment itself may not be modified in any way, such as by removing the 2423 copyright notice or references to the Internet Society or other Inter- 2424 net organizations, except as needed for the purpose of developing 2425 Internet standards in which case the procedures for copyrights defined 2426 in the Internet Standards process must be followed, or as required to 2427 translate it into languages other than English. The limited permis- 2428 sions granted above are perpetual and will not be revoked by the 2429 Internet Society or its successors or assigns. This document and the 2430 information contained herein is provided on an "AS IS" basis and THE 2431 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 2432 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 2433 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 2434 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2435 PARTICULAR PURPOSE."