idnits 2.17.1 draft-zorn-radius-err-msg-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 418. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2865, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2866, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) -- 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 (November 17, 2008) is 5610 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn, Ed. 3 Internet-Draft Network Zen 4 Updates: 2865, 2866 November 17, 2008 5 (if approved) 6 Intended status: Informational 7 Expires: May 21, 2009 9 RADIUS Error Messages 10 draft-zorn-radius-err-msg-10.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 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 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 21, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document describes new RADIUS protocol elements designed to 44 allow the communication of packet and attribute errors between RADIUS 45 servers and clients. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 51 3. RADIUS Packet Format . . . . . . . . . . . . . . . . . . . . . 3 52 4. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4.1. Error-Notification . . . . . . . . . . . . . . . . . . . . 6 54 5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 5.1. Error-Code . . . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Attribute Values . . . . . . . . . . . . . . . . . . . . . . . 8 57 6.1. Acct-Error-Notification . . . . . . . . . . . . . . . . . 9 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 Intellectual Property and Copyright Statements . . . . . . . . . . 11 64 1. Introduction 66 The RADIUS protocol [RFC2865] is defined to allow most errors to be 67 ignored and to silently discard unrecognized or erroneous packets. 68 In many cases, this behavior is beneficial or at least innocuous. 69 For example, it's probably a good idea to discard messages from 70 unknown clients and server messages having incorrect authenticators, 71 and discarding short packets doesn't seem to hurt anything. In some 72 cases, however, this policy can cause interoperability problems and 73 may result in the provision of incorrect services to users, 74 particularly in roaming situations. 76 Because RADIUS packets having unknown values in the Code field of the 77 header are silently discarded it is difficult to ascertain whether a 78 new packet type is considered invalid by the remote client/server or 79 if the message was simply lost. Similarly, RFC 2865 allows clients 80 to ignore unrecognized attributes, which can lead to incorrect 81 service provisioning. 83 This document defines a set of messages and attributes that can be 84 used to notify a RADIUS client or server of various message errors. 86 Discussion of this draft may be directed to the author. 88 2. Specification of Requirements 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 3. RADIUS Packet Format 96 Exactly one RADIUS packet is encapsulated in the UDP Data field 97 [RFC0768] where the UDP Destination Port field indicates 1812 98 (decimal). 100 When a reply is generated, the source and destination ports are 101 reversed. 103 A summary of the RADIUS data format is shown below. The fields are 104 transmitted from left to right. 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Code | Identifier | Length | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | | 112 | Authenticator | 113 | | 114 | | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Attributes ... 117 +-+-+-+-+-+-+-+-+-+-+-+-+- 119 Code 121 The Code field is one octet, and identifies the type of RADIUS 122 packet. When a client receives a packet with an invalid Code 123 field, it is silently discarded. If a server receives a packet 124 with an invalid Code field from a valid client, it SHOULD reply 125 with an Error-Notification packet (section 4.1); if the server 126 does not support the Error Notification packet, it MUST 127 silently discard the received packet. 129 The RADIUS Codes (decimal) defined in this document are as 130 follows: 132 Error-Notification 134 Identifier 136 The Identifier field is one octet, and aids in matching 137 requests, replies and notifications. The RADIUS server can 138 detect a duplicate request if it has the same client source IP 139 address, source UDP port and Identifier within a short span of 140 time. 142 Length 144 The Length field is two octets. It indicates the length of the 145 packet including the Code, Identifier, Length, Authenticator 146 and Attribute fields. Octets outside the range of the Length 147 field MUST be treated as padding and ignored on reception. If 148 the packet is shorter than the Length field indicates, it MUST 149 be silently discarded. The minimum length is 20 and maximum 150 length is 4096. 152 Authenticator 154 The Authenticator field is sixteen (16) octets. The most 155 significant octet is transmitted first. This value is used to 156 authenticate the reply from the RADIUS server. 158 Notification Authenticator 160 The value of the Authenticator field in the Error- 161 Notification packet is called the Notification 162 Authenticator, and contains a one-way MD5 hash calculated 163 over a stream of octets consisting of: the RADIUS packet, 164 beginning with the Code field, including the Identifier, the 165 Length, the Authenticator field from the packet to which 166 this packet is a response, and the response Attributes, 167 followed by the shared secret. That is, 169 Notification Auth = 170 MD5(Code+ID+Length+RequestAuth+Attributes+Secret) 171 where '+' denotes concatenation. 173 Administrative Note 175 The secret shared between the client and the RADIUS server 176 SHOULD be at least as large and unguessable as a well-chosen 177 password. It is preferred that the secret be at least 16 178 octets. This is to ensure a sufficiently large range for the 179 secret to provide protection against exhaustive search attacks. 180 The secret MUST NOT be empty (length 0) since this would allow 181 packets to be trivially forged. 183 A RADIUS server MUST use the source IP address of the RADIUS 184 UDP packet to decide which shared secret to use, so that RADIUS 185 requests can be proxied. 187 When using a forwarding proxy, the proxy must be able to alter 188 the packet as it passes through in each direction - when the 189 proxy forwards the request, the proxy MAY add a Proxy-State 190 Attribute, and when the proxy forwards a response, it MUST 191 remove its Proxy-State Attribute if it added one. Proxy-State 192 is always added or removed after any other Proxy-States, but no 193 other assumptions regarding its location within the list of 194 attributes can be made. Since Access-Accept and Access-Reject 195 replies are authenticated on the entire packet contents, the 196 stripping of the Proxy-State attribute invalidates the 197 signature in the packet - so the proxy has to re-sign it. 199 Further details of RADIUS proxy implementation are outside the 200 scope of this document. 202 4. Packet Types 204 The RADIUS Packet type is determined by the Code field in the first 205 octet of the Packet. 207 4.1. Error-Notification 209 Description 211 Error-Notification packets are sent by a RADIUS server as an 212 indication that a previous request contained one or more errors. 213 A RADIUS server wishing to notify a client that one or more errors 214 occurred MUST transmit a RADIUS packet with the Code field set to 215 (Error-Notification). 217 Error-Notification packets MUST contain at least one Error-Code 218 Attribute. 220 A summary of the Error-Notification packet format is shown below. 221 The fields are transmitted from left to right. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Code | Identifier | Length | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | | 229 | Notification Authenticator | 230 | | 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Attributes ... 234 +-+-+-+-+-+-+-+-+-+-+-+-+- 236 Code 238 for Error-Notification 240 Identifier 242 The Identifier field is a copy of the Identifier field of the 243 packet which caused this Error-Notification packet to be 244 created. 246 Notification Authenticator 248 The Notification Authenticator value is calculated from the 249 Error-Notification packet, as described above. 251 Attributes 253 The Attribute field is variable in length, and contains any 254 desired optional Attributes in addition to the required 255 Attributes. 257 5. Attributes 259 5.1. Error-Code 261 Description 263 This attribute contains a code identifying the class of error that 264 occurred, a code signifying the error itself and an optional text 265 description of the error. 267 The Error-Code Attribute MUST be included in Error-Notification 268 packets sent from a server. 270 RADIUS Accounting [RFC2866] clients MUST include this Attribute in 271 Accounting-Request packets in which the Acct-Status-Type Attribute 272 has a value of Acct-Error-Notification (see below). 274 A summary of the Error-Code Attribute format is shown below. The 275 fields are transmitted from left to right. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type | Length | Class | Code | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Code (cont'd.)| String... 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Type 286 for Error-Code. 288 Length 290 >= 4 292 Class 294 The CLASS field contains a single ASCII character indicating 295 the severity of the error. This document defines the following 296 error classes: 298 F The error was fatal and the message causing the error was 299 discarded. 301 W Warning error: the message was processed, but the result may 302 not be as anticipated. 304 Code 306 The Code field contains an unsigned integer representing the 307 type of error that occurred. This document defines the 308 following decimal values for the Code field: 310 1 Unrecognized Packet Type 312 2 Unrecognized Vendor OUI 314 3 Unrecognized Attribute 316 4 Unknown Session Identifier 318 5 Unknown Key Identifier 320 String 322 The optional String field contains a text description of the 323 error. When the Error-Code Attribute is used in Accounting- 324 Request packets, the String field SHOULD contain a message 325 describing the error. 327 6. Attribute Values 329 The following sub-sections defines a new value for the Acct-Status- 330 Type Attribute [RFC2866]. 332 6.1. Acct-Error-Notification 334 Description 336 When the value is present in the Value field of an Acct- 337 Status-Type Attribute in an Accounting-Request packet, it 338 signifies that one or more errors have occurred on the client 339 side. 341 7. IANA Considerations 343 The criteria to be used by the Internet Assigned Numbers Authority 344 (IANA) for assignment of numbers within namespaces defined within 345 this document are identical to those given in [RFC3575]. 347 8. Security Considerations 349 None. 351 9. Normative References 353 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 354 August 1980. 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, March 1997. 359 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 360 "Remote Authentication Dial In User Service (RADIUS)", 361 RFC 2865, June 2000. 363 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 365 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 366 Authentication Dial In User Service)", RFC 3575, 367 July 2003. 369 Author's Address 371 Glen Zorn (editor) 372 Network Zen 373 1310 East Thomas Street 374 Seattle, Washington 98102 375 US 377 Phone: +1 (206) 377-9035 378 Email: gwz@net-zen.net 380 Full Copyright Statement 382 Copyright (C) The IETF Trust (2008). 384 This document is subject to the rights, licenses and restrictions 385 contained in BCP 78, and except as set forth therein, the authors 386 retain all their rights. 388 This document and the information contained herein are provided on an 389 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 390 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 391 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 392 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 393 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 394 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 396 Intellectual Property 398 The IETF takes no position regarding the validity or scope of any 399 Intellectual Property Rights or other rights that might be claimed to 400 pertain to the implementation or use of the technology described in 401 this document or the extent to which any license under such rights 402 might or might not be available; nor does it represent that it has 403 made any independent effort to identify any such rights. Information 404 on the procedures with respect to rights in RFC documents can be 405 found in BCP 78 and BCP 79. 407 Copies of IPR disclosures made to the IETF Secretariat and any 408 assurances of licenses to be made available, or the result of an 409 attempt made to obtain a general license or permission for the use of 410 such proprietary rights by implementers or users of this 411 specification can be obtained from the IETF on-line IPR repository at 412 http://www.ietf.org/ipr. 414 The IETF invites any interested party to bring to its attention any 415 copyrights, patents or patent applications, or other proprietary 416 rights that may cover technology that may be required to implement 417 this standard. Please address the information to the IETF at 418 ietf-ipr@ietf.org. 420 Acknowledgment 422 Funding for the RFC Editor function is provided by the IETF 423 Administrative Support Activity (IASA).