idnits 2.17.1 draft-nelson-rfc2618bis-00.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 393. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC2618, updated by this document, for RFC5378 checks: 1997-08-26) -- 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 (February 8, 2005) is 7015 days in the past. Is this intentional? 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: 'RFC3418' is defined on line 335, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) -- Obsolete informational reference (is this intentional?): RFC 2618 (Obsoleted by RFC 4668) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Nelson 2 Internet-Draft Enterasys Networks 3 Updates: RFC 2618 (if approved) February 8, 2005 4 Expires: August 12, 2005 6 RADIUS Authentication Client MIB (IPv6) 7 draft-nelson-rfc2618bis-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 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 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 12, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This memo updates RFC 2618 by extending the MIB defined in RFC 2618 43 to add support for IPv6 address formats. 45 Table of Contents 47 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. The Internet-Standard Management Framework . . . . . . . . . 3 50 4. Scope of Changes . . . . . . . . . . . . . . . . . . . . . . 3 51 5. Struture of the MIB Module . . . . . . . . . . . . . . . . . 3 52 6. Deprecated Objects . . . . . . . . . . . . . . . . . . . . . 4 53 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 54 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 55 9. Security Considerations . . . . . . . . . . . . . . . . . . 7 56 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 10.1 Normative References . . . . . . . . . . . . . . . . . . 8 58 10.2 Informative References . . . . . . . . . . . . . . . . . 8 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 60 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 9 61 Intellectual Property and Copyright Statements . . . . . . . 10 63 1. Terminology 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 This document uses terminology from RFC 2618 [RFC2618] and RFC 2865 70 [RFC2865]. 72 2. Introduction 74 This memo defines a portion of the Management Information Base (MIB) 75 for use with network management protocols in the Internet community. 76 The objects defined within this memo relate to the RADIUS 77 Authentication Client as defined in RFC 2865 [RFC2865]. 79 3. The Internet-Standard Management Framework 81 For a detailed overview of the documents that describe the current 82 Internet-Standard Management Framework, please refer to section 7 of 83 RFC 3410 [RFC3410]. 85 Managed objects are accessed via a virtual information store, termed 86 the Management Information Base or MIB. MIB objects are generally 87 accessed through the Simple Network Management Protocol (SNMP). 88 Objects in the MIB are defined using the mechanisms defined in the 89 Structure of Management Information (SMI). This memo specifies a MIB 90 module that is compliant to the SMIv2, which is described in STD 58, 91 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 92 [RFC2580]. 94 4. Scope of Changes 96 This document updates RFC 2618 [RFC2618], RADIUS Authentication 97 Client MIB, by augmenting the conceptual table rows for 98 radiusAuthServerEntry, adding new columns called 99 radiusAuthServerInetAddressType, radiusAuthServerInetAddress, and 100 radiusAuthClientServerInetPortNumber. The purpose of these added MIB 101 objects is to support IPv6 addressing formats. The existing table 102 columns radiusAuthServerAddress and radiusAuthClientServerPortNumber 103 are deprecated but may continue to be used in IPv4-only deployments. 105 5. Struture of the MIB Module 107 The structure of the MIB Module defined in this memo extends the 108 structure of the MIB Module defined in RADIUS Authentication Client 109 MIB, RFC 2618 [RFC2618] using the SMI AUGMENTS syntax, but does not 110 alter that structure, except to deprecate the corresponding IPv4-only 111 address format objects. 113 6. Deprecated Objects 115 The following objects, defined in RADIUS Authentication Client MIB, 116 RFC 2618 [RFC2618] are deprecated: 118 radiusAuthServerAddress 119 radiusAuthClientServerPortNumber 121 7. Definitions 123 RADIUS-AUTH-CLIENT-MIB-IPV6 DEFINITIONS ::= BEGIN 125 IMPORTS 126 MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, 127 mib-2 FROM SNMPv2-SMI 128 InetAddressType, InetAddress, InetPortNumber 129 FROM INET-ADDRESS-MIB 130 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 131 radiusAuthServerEntry FROM RADIUS-AUTH-CLIENT-MIB; 133 radiusAuthClientExtMIB MODULE-IDENTITY 134 LAST-UPDATED "200502072051Z" -- Mon Feb 7 20:51 GMT 2005 135 ORGANIZATION "IETF RADIUS Extensions Working Group." 136 CONTACT-INFO 137 " David B. Nelson 138 Enterasys Networks 139 50 Minutemann Road 140 Andover, MA 01810 141 US 143 Phone: +1 978 684 1000 144 EMail: dnelson@eterasys.com" 145 DESCRIPTION 146 "An extension to the MIB module for entities 147 implementing the client side of the Remote Access 148 Dialin User Service (RADIUS) authentication protocol, 149 using IPv6 addressing formats. Updates RFC 2618." 150 REVISION "200502072051Z" -- Mon Feb 7 20:51 GMT 2005 151 DESCRIPTION "Initial version, published as RFC xxxx." 153 -- RFC Editor: replace xxx with actual RFC number at the time of 154 -- publication, and remove this note. 156 ::= { mib-2 TBA } 158 -- RFC Editor: replace TBA with IANA assigned OID value, and 159 -- remove this note. 161 radiusAuthClientExtMIBNotifications OBJECT IDENTIFIER 162 ::= { radiusAuthClientExtMIB 0 } 164 radiusAuthClientExtMIBObjects OBJECT IDENTIFIER 165 ::= { radiusAuthClientExtMIB 1 } 167 radiusAuthClientExtMIBConformance OBJECT IDENTIFIER 168 ::= { radiusAuthClientExtMIB 2 } 170 -- MIB objects 172 radiusAuthServerExtTable OBJECT-TYPE 173 SYNTAX SEQUENCE OF RadiusAuthServerExtEntry 174 MAX-ACCESS not-accessible 175 STATUS current 176 DESCRIPTION 177 "The (conceptual) table listing the RADIUS 178 authentication servers with which the client 179 shares a secret." 180 ::= { radiusAuthClientExtMIBObjects 1 } 182 radiusAuthServerExtEntry OBJECT-TYPE 183 SYNTAX RadiusAuthServerExtEntry 184 MAX-ACCESS not-accessible 185 STATUS current 186 DESCRIPTION 187 "An entry (conceptual row) representing a RADIUS 188 authentication server with which the client shares 189 a secret." 190 AUGMENTS { radiusAuthServerEntry } 191 ::= { radiusAuthServerExtTable 1 } 193 RadiusAuthServerExtEntry ::= SEQUENCE { 194 radiusAuthServerInetAddressType InetAddressType, 195 radiusAuthServerInetAddress InetAddress, 196 radiusAuthClientServerInetPortNumber InetPortNumber 197 } 199 radiusAuthServerInetAddressType OBJECT-TYPE 200 SYNTAX InetAddressType 201 MAX-ACCESS read-only 202 STATUS current 203 DESCRIPTION 204 "The type of address format used for the 205 radiusAuthServerInetAddress object." 206 ::= { radiusAuthServerExtEntry 1 } 208 radiusAuthServerInetAddress OBJECT-TYPE 209 SYNTAX InetAddress 210 MAX-ACCESS read-only 211 STATUS current 212 DESCRIPTION 213 "The IP address of the RADIUS authentication 214 server referred to in this table entry, using 215 the IPv6 adddess format." 216 ::= { radiusAuthServerExtEntry 2 } 218 radiusAuthClientServerInetPortNumber OBJECT-TYPE 219 SYNTAX InetPortNumber 220 MAX-ACCESS read-only 221 STATUS current 222 DESCRIPTION 223 "The UDP port the client is using to send requests 224 to this server." 225 ::= { radiusAuthServerExtEntry 3 } 227 -- conformance information 229 radiusAuthClientExtMIBCompliances OBJECT IDENTIFIER 230 ::= { radiusAuthClientExtMIBConformance 1 } 232 radiusAuthClientExtMIBGroups OBJECT IDENTIFIER 233 ::= { radiusAuthClientExtMIBConformance 2 } 235 -- compliance statements 237 radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE 238 STATUS current 239 DESCRIPTION 240 "The compliance statement for authentication 241 clients implementing the RADIUS Authentication 242 Client IPv6 Extensions MIB." 243 MODULE -- this module 244 MANDATORY-GROUPS { radiusAuthClientExtMIBGroup } 246 ::= { radiusAuthClientExtMIBCompliances 1 } 248 -- units of conformance 250 radiusAuthClientExtMIBGroup OBJECT-GROUP 251 OBJECTS { radiusAuthServerInetAddressType, 252 radiusAuthServerInetAddress, 253 radiusAuthClientServerInetPortNumber 254 } 255 STATUS current 256 DESCRIPTION 257 "The collection of extended objects providing 258 management of RADIUS Authentication Clients 259 using IPv6 address format." 260 ::= { radiusAuthClientExtMIBGroups 1 } 262 END 264 8. IANA Considerations 266 This document requires IANA assignment of a number in the MIB-2 OID 267 number space. 269 9. Security Considerations 271 There are no management objects defined in this MIB that have a MAX- 272 ACCESS clause of read-write and/or read-create. So, if this MIB is 273 implemented correctly, then there is no risk that an intruder can 274 alter or create any management objects of this MIB via direct SNMP 275 SET operations. 277 There are a number of managed objects in this MIB that may contain 278 sensitive information. These are: 280 radiusAuthServerInetAddress This can be used to determine the address 281 of the RADIUS authentication server with which the client is 282 communicating. This information could be useful in mounting an 283 attack on the authentication server. 285 radiusAuthClientServerInetPortNumber This can be used to determine 286 the port number on which the RADIUS authentication client is 287 sending. This information could be useful in impersonating the 288 client in order to send data to the authentication server. 290 It is thus important to control even GET access to these objects and 291 possibly to even encrypt the values of these object when sending them 292 over the network via SNMP. Not all versions of SNMP provide features 293 for such a secure environment. 295 SNMP versions prior to SNMPv3 do not provide a secure environment. 296 Even if the network itself is secure (for example by using IPSec), 297 there is no control as to who on the secure network is allowed to 298 access and GET/SET (read/change/create/delete) the objects in this 299 MIB. 301 It is recommended that the implementers consider the security 302 features as provided by the SNMPv3 framework. Specifically, the use 303 of the User-based Security Model [RFC2574] and the View-based Access 304 Control Model [RFC2575] is recommended. Using these security 305 features, customer/users can give access to the objects only to those 306 principals (users) that have legitimate rights to GET or SET 307 (change/create/delete) them. 309 10. References 311 10.1 Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model 317 (USM) for version 3 of the Simple Network Management 318 Protocol (SNMPv3)", April 1999. 320 [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 321 Access Control Model (VACM) for the Simple Network 322 Management Protocol (SNMP)", April 1999. 324 [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 325 "Structure of Management Information Version 2 (SMIv2)", 326 STD 58, RFC 2578, April 1999. 328 [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual 329 Conventions for SMIv2", STD 58, RFC 2579, April 1999. 331 [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 332 "Conformance Statements for SMIv2", STD 58, RFC 2580, 333 April 1999. 335 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 336 Simple Network Management Protocol (SNMP)", STD 62, 337 RFC 3418, December 2002. 339 10.2 Informative References 341 [RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client MIB", 342 RFC 2618, June 1999. 344 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 345 "Authentication Dial In User Service (RADIUS)", RFC 2865, 346 June 2000. 348 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 349 "Introduction and Applicability Statements for 350 Internet-Standard Management Framework", RFC 3410, 351 December 2002. 353 Author's Address 355 David B. Nelson 356 Enterasys Networks 357 50 Minuteman Road 358 Andover, MA 01810 359 USA 361 Email: dnelson@enterasys.com 363 Appendix A. Acknowledgments 365 The Authors of the original MIB [RFC2618] are Bernard Aboba and Glen 366 Zorn. 368 Many thanks to all reviewers, especially to David Harrington and 369 Bruno Pape. 371 Intellectual Property Statement 373 The IETF takes no position regarding the validity or scope of any 374 Intellectual Property Rights or other rights that might be claimed to 375 pertain to the implementation or use of the technology described in 376 this document or the extent to which any license under such rights 377 might or might not be available; nor does it represent that it has 378 made any independent effort to identify any such rights. Information 379 on the procedures with respect to rights in RFC documents can be 380 found in BCP 78 and BCP 79. 382 Copies of IPR disclosures made to the IETF Secretariat and any 383 assurances of licenses to be made available, or the result of an 384 attempt made to obtain a general license or permission for the use of 385 such proprietary rights by implementers or users of this 386 specification can be obtained from the IETF on-line IPR repository at 387 http://www.ietf.org/ipr. 389 The IETF invites any interested party to bring to its attention any 390 copyrights, patents or patent applications, or other proprietary 391 rights that may cover technology that may be required to implement 392 this standard. Please address the information to the IETF at 393 ietf-ipr@ietf.org. 395 Disclaimer of Validity 397 This document and the information contained herein are provided on an 398 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 399 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 400 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 401 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 402 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 403 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 405 Copyright Statement 407 Copyright (C) The Internet Society (2005). This document is subject 408 to the rights, licenses and restrictions contained in BCP 78, and 409 except as set forth therein, the authors retain all their rights. 411 Acknowledgment 413 Funding for the RFC Editor function is currently provided by the 414 Internet Society.