idnits 2.17.1 draft-calhoun-diameter-authent-00.txt: 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** 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 an Authors' Addresses Section. ** There are 15 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 61: '... MUST This word, or the adje...' RFC 2119 keyword, line 65: '... MUST NOT This phrase means that...' RFC 2119 keyword, line 68: '... SHOULD This word, or the adje...' RFC 2119 keyword, line 74: '... MAY This word, or the adje...' RFC 2119 keyword, line 76: '...hich does not include this option MUST...' (8 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.) -- The document date (March 1997) is 9904 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 265 looks like a reference -- Missing reference section? '2' on line 266 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 0 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Pat R. Calhoun 2 Category: Experimental US Robotics Access Corp. 3 expires in six months Allan Rubens 4 Merit Network Inc. 5 March 1997 7 DIAMETER 8 Authentication Extensions 9 11 Status of this Memo 13 Distribution of this memo is unlimited. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 Abstract 33 DIAMETER is a management protocol used between Network Access Servers 34 and DIAMETER Servers for authentication, authorization, accounting of 35 dial-up users. A considerable amount of effort was put into the design 36 of this protocol to ensure that an implementation could support both 37 DIAMETER and RADIUS at the same time. 39 This document details the RADIUS authentication messages and how they 40 may be used with the DIAMETER protocol. 42 1. Introduction 44 This document specifies extensions to the original RADIUS[1] 45 authentication messages. 47 There exists a scenario where services providers wish to proxy the 48 authentication of a user to a remote DIAMETER Server, yet wishes 49 to perform the authorization for the said user. 51 There are also many instances where a NAS may wish to simply 52 authenticate a user and not have any authorization assigned to the 53 request. 55 1.1. Specification of Requirements 57 In this document, several words are used to signify the 58 requirements of the specification. These words are often 59 capitalized. 61 MUST This word, or the adjective "required", means that the 62 definition is an absolute requirement of the 63 specification. 65 MUST NOT This phrase means that the definition is an absolute 66 prohibition of the specification. 68 SHOULD This word, or the adjective "recommended", means that 69 there may exist valid reasons in particular circumstances 70 to ignore this item, but the full implications must be 71 understood and carefully weighed before choosing a 72 different course. 74 MAY This word, or the adjective "optional", means that this 75 item is one of an allowed set of alternatives. An 76 implementation which does not include this option MUST 77 be prepared to interoperate with another implementation 78 which does include the option. 80 2. Command Name and Command Code 82 Command Name: Access-Request 83 Command Code: 1 85 Command Name: Access-Accept 86 Command Code: 2 88 3. Command Meanings 90 3.1 Access-Request 92 Description 94 The Access-Request message is used by RADIUS/DIAMETER in order to 95 request that a user be authenticated. See [1] for more details. 97 The differences in the message used in RADIUS and the one for 98 DIAMETER are the flags which may be used with the message. If the 99 Authenticate-Only bit is set, then the Server which is 100 authenticating the user MUST NOT return any authorization 101 information. 103 Similarly if the Authorize-Only bit is set, the Client is 104 requesting that authorization information be returned for the user. 106 A summary of the Access-Request packet format is shown below. The 107 fields are transmitted from left to right. 109 0 1 2 3 110 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Code | Flags | Ver | Command | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Identifier | Length | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | | 117 | Authenticator | 118 | | 119 | | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | | 122 | Message Integrity Code | 123 | | 124 | | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Attributes ... 127 +-+-+-+-+-+-+-+-+-+-+-+-+- 129 Code 131 254 for DIAMETER. 133 Flags 135 The Following bits MAY be used in the Access-Request: 137 0x1 - (Bit 12) TimeStamp is included in the Authenticator Field. 138 0x2 - (Bit 11) All attributes in packets are encrypted. 139 0x4 - (Bit 10) Authenticate-Only 140 0x8 - (Bit 9) Authorize-Only 142 See [2] for more information on the encryption algorithm used. 144 Version 146 MUST be set to 2 148 Command 150 1 for Access-Request 152 Identifier 154 The Identifier field MUST be changed whenever the content of the 155 Attributes field changes, and whenever a valid reply has been 156 received for a previous request. For retransmissions, the 157 Identifier MAY remain unchanged. 159 Length 161 The total length of the message, including this header. 163 Authenticator 165 The Authenticator field is a random 16 octet value. If the 166 Timestamp option is supported, the first four octets contain a 167 timestamp of when the packet was sent from the peer. 169 Message Integrity Code 171 This field contains an MD5 hash of the following: 173 MD5( packet | Shared Secret ) 175 Attributes 177 The attributes in this message should be sent as defined in [1]. 179 3.1 Access-Accept 181 Description 183 The Access-Accept message is used by RADIUS/DIAMETER in order to 184 request that a user be authenticated. See [1] for more details. 186 The differences in the message used in RADIUS and the one for 187 DIAMETER are the flags which may be used with the message. The 188 Access-Accept SHOULD contain the SAME flags which were set in the 189 original Access-Request. The failure to do so implies that the 190 Server does not support the feature. 192 A summary of the Access-Request packet format is shown below. The 193 fields are transmitted from left to right. 195 0 1 2 3 196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Code | Flags | Ver | Command | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Identifier | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 | Authenticator | 204 | | 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 | Message Integrity Code | 209 | | 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Attributes ... 213 +-+-+-+-+-+-+-+-+-+-+-+-+- 215 Code 217 254 for DIAMETER. 219 Flags 221 The Following bits MAY be used in the Access-Request: 223 0x1 - (Bit 12) TimeStamp is included in the Authenticator Field. 224 0x2 - (Bit 11) All attributes in packets are encrypted. 225 0x4 - (Bit 10) User Authenticated Only 226 0x8 - (Bit 9) User Authorized Only 228 See [2] for more information on the encryption algorithm used. 230 Version 232 MUST be set to 2 234 Command 236 2 for Access-Accept 238 Identifier 240 The Identifier field is a copy of the Identifier field of the 241 Access-Request. 243 Length 245 The total length of the message, including this header. 247 Authenticator 249 The Authenticator field is a random 16 octet value. If the 250 Timestamp option is supported, the first four octets contain a 251 timestamp of when the packet was sent from the peer. 253 Message Integrity Code 255 This field contains an MD5 hash of the following: 257 MD5( packet | Shared Secret ) 259 Attributes 261 The attributes in this message should be sent as defined in [1]. 263 4. References 265 [1] Rigney, et alia, "RADIUS", RFC-2058, Livingston, January 1997 266 [2] Calhoun, Rubens, "DIAMETER", Internet-Draft, March 1997. 268 5. Authors' Addresses 270 Pat R. Calhoun 271 US Robotics Access Corp. 272 8100 N. McCormick Blvd. 273 Skokie, IL 60076-2999 275 Phone: 847-342-6898 276 EMail: pcalhoun@usr.com 278 Allan C. Rubens 279 Merit Network, Inc. 280 4251 Plymouth Rd. 281 Ann Arbor, MI 48105-2785 283 Phone: 313-647-0417 284 EMail: acr@merit.edu