idnits 2.17.1 draft-nelson-rfc2619bis-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 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 375. ** 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 RFC2619, 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 7017 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 317, 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 2619 (Obsoleted by RFC 4669) 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 2619 (if approved) February 8, 2005 4 Expires: August 12, 2005 6 RADIUS Authentication Server MIB (IPv6) 7 draft-nelson-rfc2619bis-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 2619 by extending the MIB defined in RFC 2619 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 . . . . . . . . . . . . . . . . . . . . 6 55 9. Security Considerations . . . . . . . . . . . . . . . . . . 7 56 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 10.1 Normative References . . . . . . . . . . . . . . . . . . 7 58 10.2 Informative References . . . . . . . . . . . . . . . . . 8 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 60 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 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 2619 [RFC2619] 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 Server 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 2619 [RFC2619], RADIUS Authentication 97 Server MIB, by augmenting the conceptual table rows for 98 radiusAuthClientEntry, adding new columns called 99 radiusAuthClientInetAddressType and radiusAuthClientInetAddress. The 100 purpose of these added MIB objects is to support IPv6 addressing 101 formats. The existing table column radiusAuthClientAddress is 102 deprecated but may continue to be used in IPv4-only deployments. 104 5. Struture of the MIB Module 106 The structure of the MIB Module defined in this memo extends the 107 structure of the MIB Module defined in RADIUS Authentication Server 108 MIB, RFC 2619 [RFC2619] using the SMI AUGMENTS syntax, but does not 109 alter that structure, except to deprecate the corresponding IPv4-only 110 address format objects. 112 6. Deprecated Objects 114 The following objects, defined in RADIUS Authentication Server MIB, 115 RFC 2619 [RFC2619] are deprecated: 117 radiusAuthClientAddress 119 7. Definitions 121 RADIUS-AUTH-SERVER-MIB-IPV6 DEFINITIONS ::= BEGIN 123 IMPORTS 124 MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, 125 mib-2 FROM SNMPv2-SMI 126 InetAddressType, InetAddress, InetPortNumber 127 FROM INET-ADDRESS-MIB 128 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 129 radiusAuthClientEntry FROM RADIUS-AUTH-SERVER-MIB; 131 radiusAuthServerExtMIB MODULE-IDENTITY 132 LAST-UPDATED "200502072051Z" -- Mon Feb 7 20:51 GMT 2005 133 ORGANIZATION "IETF RADIUS Extensions Working Group." 134 CONTACT-INFO 135 " David B. Nelson 136 Enterasys Networks 137 50 Minutemann Road 138 Andover, MA 01810 139 US 141 Phone: +1 978 684 1000 142 EMail: dnelson@eterasys.com" 143 DESCRIPTION 144 "An extension to the MIB module for entities 145 implementing the server side of the Remote Access 146 Dialin User Service (RADIUS) authentication protocol, 147 using IPv6 addressing formats. Updates RFC 2619." 148 REVISION "200502072051Z" -- Mon Feb 7 20:51 GMT 2005 149 DESCRIPTION "Initial version, published as RFC xxxx." 151 -- RFC Editor: replace xxx with actual RFC number at the time of 152 -- publication, and remove this note. 154 ::= { mib-2 TBA } 156 -- RFC Editor: replace TBA with IANA assigned OID value, and 157 -- remove this note. 159 radiusAuthServerExtMIBNotifications OBJECT IDENTIFIER 160 ::= { radiusAuthServerExtMIB 0 } 162 radiusAuthServerExtMIBObjects OBJECT IDENTIFIER 163 ::= { radiusAuthServerExtMIB 1 } 165 radiusAuthServerExtMIBConformance OBJECT IDENTIFIER 166 ::= { radiusAuthServerExtMIB 2 } 168 -- MIB objects 170 radiusAuthClientExtTable OBJECT-TYPE 171 SYNTAX SEQUENCE OF RadiusAuthClientExtEntry 172 MAX-ACCESS not-accessible 173 STATUS current 174 DESCRIPTION 175 "The (conceptual) table listing the RADIUS 176 authentication clients with which the server 177 shares a secret." 178 ::= { radiusAuthServerExtMIBObjects 1 } 180 radiusAuthClientExtEntry OBJECT-TYPE 181 SYNTAX RadiusAuthClientExtEntry 182 MAX-ACCESS not-accessible 183 STATUS current 184 DESCRIPTION 185 "An entry (conceptual row) representing a RADIUS 186 authentication client with which the server shares 187 a secret." 188 AUGMENTS { radiusAuthClientEntry } 189 ::= { radiusAuthServerExtTable 1 } 191 RadiusAuthClientExtEntry ::= SEQUENCE { 192 radiusAuthClientInetAddressType InetAddressType, 193 radiusAuthClientInetAddress InetAddress 194 } 196 radiusAuthClientInetAddressType OBJECT-TYPE 197 SYNTAX InetAddressType 198 MAX-ACCESS read-only 199 STATUS current 200 DESCRIPTION 201 "The type of address format used for the 202 radiusAuthClientInetAddress object." 203 ::= { radiusAuthClientExtEntry 1 } 205 radiusAuthClientInetAddress OBJECT-TYPE 206 SYNTAX InetAddress 207 MAX-ACCESS read-only 208 STATUS current 209 DESCRIPTION 210 "The IP address of the RADIUS authentication 211 client referred to in this table entry, using 212 the IPv6 adddess format." 213 ::= { radiusAuthClientExtEntry 2 } 215 -- conformance information 217 radiusAuthServerExtMIBCompliances OBJECT IDENTIFIER 218 ::= { radiusAuthServerExtMIBConformance 1 } 220 radiusAuthServerExtMIBGroups OBJECT IDENTIFIER 221 ::= { radiusAuthServerExtMIBConformance 2 } 223 -- compliance statements 225 radiusAuthServerExtMIBCompliance MODULE-COMPLIANCE 226 STATUS current 227 DESCRIPTION 228 "The compliance statement for authentication 229 servers implementing the RADIUS Authentication 230 Server IPv6 Extensions MIB." 231 MODULE -- this module 232 MANDATORY-GROUPS { radiusAuthServerExtMIBGroup } 234 ::= { radiusAuthServerExtMIBCompliances 1 } 236 -- units of conformance 238 radiusAuthServerExtMIBGroup OBJECT-GROUP 239 OBJECTS { radiusAuthClientInetAddressType, 240 radiusAuthClientInetAddress 241 } 242 STATUS current 243 DESCRIPTION 244 "The collection of extended objects providing 245 management of RADIUS Authentication Servers 246 using IPv6 address format." 247 ::= { radiusAuthServerExtMIBGroups 1 } 249 END 251 8. IANA Considerations 253 This document requires IANA assignment of a number in the MIB-2 OID 254 number space. 256 9. Security Considerations 258 There are no management objects defined in this MIB that have a MAX- 259 ACCESS clause of read-write and/or read-create. So, if this MIB is 260 implemented correctly, then there is no risk that an intruder can 261 alter or create any management objects of this MIB via direct SNMP 262 SET operations. 264 There are a number of managed objects in this MIB that may contain 265 sensitive information. These are: 267 radiusAuthClientInetAddress This can be used to determine the address 268 of the RADIUS authentication client with which the server is 269 communicating. This information could be useful in mounting an 270 attack on the authentication client. 272 It is thus important to control even GET access to these objects and 273 possibly to even encrypt the values of these object when sending them 274 over the network via SNMP. Not all versions of SNMP provide features 275 for such a secure environment. 277 SNMP versions prior to SNMPv3 do not provide a secure environment. 278 Even if the network itself is secure (for example by using IPSec), 279 there is no control as to who on the secure network is allowed to 280 access and GET/SET (read/change/create/delete) the objects in this 281 MIB. 283 It is recommended that the implementers consider the security 284 features as provided by the SNMPv3 framework. Specifically, the use 285 of the User-based Security Model [RFC2574] and the View-based Access 286 Control Model [RFC2575] is recommended. Using these security 287 features, customer/users can give access to the objects only to those 288 principals (users) that have legitimate rights to GET or SET 289 (change/create/delete) them. 291 10. References 293 10.1 Normative References 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model 299 (USM) for version 3 of the Simple Network Management 300 Protocol (SNMPv3)", April 1999. 302 [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 303 Access Control Model (VACM) for the Simple Network 304 Management Protocol (SNMP)", April 1999. 306 [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 307 "Structure of Management Information Version 2 (SMIv2)", 308 STD 58, RFC 2578, April 1999. 310 [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual 311 Conventions for SMIv2", STD 58, RFC 2579, April 1999. 313 [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 314 "Conformance Statements for SMIv2", STD 58, RFC 2580, 315 April 1999. 317 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 318 Simple Network Management Protocol (SNMP)", STD 62, 319 RFC 3418, December 2002. 321 10.2 Informative References 323 [RFC2619] Zorn, G. and B. Aboba, "RADIUS Authentication Server MIB", 324 RFC 2619, June 1999. 326 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 327 "Authentication Dial In User Service (RADIUS)", RFC 2865, 328 June 2000. 330 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 331 "Introduction and Applicability Statements for 332 Internet-Standard Management Framework", RFC 3410, 333 December 2002. 335 Author's Address 337 David B. Nelson 338 Enterasys Networks 339 50 Minuteman Road 340 Andover, MA 01810 341 USA 343 Email: dnelson@enterasys.com 345 Appendix A. Acknowledgments 347 The Authors of the original MIB [RFC2619] are Bernard Aboba and Glen 348 Zorn. 350 Many thanks to all reviewers, especially to David Harrington and 351 Bruno Pape. 353 Intellectual Property Statement 355 The IETF takes no position regarding the validity or scope of any 356 Intellectual Property Rights or other rights that might be claimed to 357 pertain to the implementation or use of the technology described in 358 this document or the extent to which any license under such rights 359 might or might not be available; nor does it represent that it has 360 made any independent effort to identify any such rights. Information 361 on the procedures with respect to rights in RFC documents can be 362 found in BCP 78 and BCP 79. 364 Copies of IPR disclosures made to the IETF Secretariat and any 365 assurances of licenses to be made available, or the result of an 366 attempt made to obtain a general license or permission for the use of 367 such proprietary rights by implementers or users of this 368 specification can be obtained from the IETF on-line IPR repository at 369 http://www.ietf.org/ipr. 371 The IETF invites any interested party to bring to its attention any 372 copyrights, patents or patent applications, or other proprietary 373 rights that may cover technology that may be required to implement 374 this standard. Please address the information to the IETF at 375 ietf-ipr@ietf.org. 377 Disclaimer of Validity 379 This document and the information contained herein are provided on an 380 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 381 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 382 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 383 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 384 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 385 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 387 Copyright Statement 389 Copyright (C) The Internet Society (2005). This document is subject 390 to the rights, licenses and restrictions contained in BCP 78, and 391 except as set forth therein, the authors retain all their rights. 393 Acknowledgment 395 Funding for the RFC Editor function is currently provided by the 396 Internet Society.