Section 2.12.5. It MAY also be satisfied using local authentication. See Section 2.12.6. Warnings. None.
Section 2.4.5 or recovery of authorized access Section 2.12.15. Justification. The use of individual accounts, in conjunction with logging, promotes accountability. The use of group or default accounts undermines individual accountability. Examples. A user may need to log in to the device to access CLI functions for management. Individual user authentication could be provided by a centralized authentication server or a username/password database stored on the device. It would be a violation of this rule for the device to only support a single "account" (with or without a username) and a single password shared by all users to gain administrative access. Warnings. This simply requires that the mechanism to support individual users be present. Policy (e.g., forbidding shared group accounts) and enforcement are also needed but beyond the scope of this document.
Examples. None. Warnings. None.
Justification. Support for centralized authentication is particularly important in large environments where the network devices are widely distributed and where many people have access to them. This reduces the effort needed to effectively restrict and track access to the system by authorized personnel. Examples. This requirement can be satisfied through the use of DIAMETER [RFC3588], TACACS+ [RFC1492], RADIUS [RFC2865], or Kerberos [RFC1510]. The secure management requirements (Section 2.1.1) apply to AAA. See [RFC3579] for a discussion security issues related to RADIUS. Warnings. None. Section 2.3.1 (Support a 'Console' Interface) and Section 2.12.7 (Support Configuration of Order of Authentication Methods). Justification. Support for local authentication may be required in smaller environments where there may be only a few devices and a limited number of people with access. The overhead of maintaining centralized authentication servers may not be justified. Examples. The use of local, per-device usernames and passwords provides one way to implement this requirement.
Warnings. Authentication information must be protected wherever it resides. Having, for instance, local usernames and passwords stored on 100 network devices means that there are 100 potential points of failure where the information could be compromised vs. storing authentication data centralized server(s), which would reduce the potential points of failure to the number of servers and allow protection efforts (system hardening, audits, etc.) to be focused on, at most, a few servers.
Justification. Plaintext passwords can be easily observed using packet sniffers on shared networks. See [RFC1704] and [RFC3631] for a through discussion. Examples. Remote login requires the transmission of authentication information across networks. Telnet transmits plaintext passwords. SSH does not. Telnet fails this requirement. SSH passes. Warnings. None.
Justification. This requirement is intended to prevent unauthorized management access. Requiring the operator to explicitly configure passwords will tend to have the effect of ensuring a diversity of passwords. It also shifts the responsibility for password selection to the user. Examples. Assume that a device comes with console port for management and a default administrative account. This requirement together with No Default Passwords says that the administrative account should come with no password configured. One way of meeting this requirement would be to have the device require the operator to choose a password for the administrative account as part of a dialog the first time the device is configured. Warnings. While this device requires operators to set passwords, it does not prevent them from doing things such as using scripts to configure hundreds of devices with the same easily guessed passwords. Section 2.12.12. There MUST be at least three possible privilege levels. Justification. This requirement supports the implementation of the principal of "least privilege", which states that an individual should only have the privileges necessary to execute the operations he/she is required to perform. Examples. Examples of privilege levels might include "user" which only allows the initiation of a PPP or telnet session, "read only", which allows read-only access to device configuration and operational statistics, "root/superuser/administrator" which allows update access to all configurable parameters, and "operator" which allows updates to a limited, user defined set of
parameters. Note that privilege levels may be defined locally on the device or on centralized authentication servers. Warnings. None. Section 2.12.11. Justification. This requirement supports the implementation of the principal of "least privilege", which states that an individual should only have the privileges necessary to execute the operations he/she is required to perform. Examples. The implementation of this requirement will obviously be closely coupled with the authentication mechanism. If RADIUS is used, an attribute could be set in the user's RADIUS profile that can be used to map the ID to a certain privilege level. Warnings. None. Section 2.4.5 or recovery of authorized access per Section 2.12.15.
Justification. This requirement supports the implementation of the principal of "least privilege", which states that an individual should only have the privileges necessary to execute the operations he/she is required to perform. Examples. Examples of privilege levels might include "user" which only allows the initiation of a PPP or telnet session, "read-only", which allows read-only access to device configuration and operational statistics, "root/superuser/administrator" which allows update access to all configurable parameters, and "operator" which allows updates to a limited, user defined set of parameters. Note that privilege levels may be defined locally on the device or on centralized authentication servers. Warnings. It may be required to provide exceptions to support the requirements to support recovery of privileged access (Section 2.12.15) and to support OS installation and configuration (Section 2.4.5). For example, if the OS and/or configuration has somehow become corrupt an authorized individual with physical access may need to have "root" level access to perform an install.
Section 2.3.1 (Support a 'Console' Interface).
* Use of the security feature consumes excessive resources (CPU, memory, bandwidth). Warnings. Determination of compliance with this requirement involves a level of judgement. What is "severe"? Certainly crashing is severe, but what about a %5 loss in throughput when logging is enabled? It should also be noted that there may be unavoidable physical limitations such as the total capacity of a link.
Justification. Understanding risk requires understanding exposure. Each service that is enabled presents a certain level of exposure. Having a list of the services that is enabled by default makes it possible to perform meaningful risk analysis. Examples. The list may be no more than the output of a command that implements Section 2.5.1. Warnings. None.
Justification. Understanding of inputs and outputs is necessary to support scripting. See Section 2.4.2. Examples. Separate documentation should be provided for each command listing the syntax, parameters, options, etc. as well as expected output (status, tables, etc.). Warnings. None.
RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to MIB objects is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. [ANSI.X9-52.1998] American National Standards Institute, "Triple Data Encryption Algorithm Modes of Operation", ANSI X9.52, 1998. [FIPS.197] National Institute of Standards and Technology, "Advanced Encryption Standard", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.ps>. [PKCS.3.1993] RSA Laboratories, "Diffie-Hellman Key-Agreement Standard, Version 1.4", PKCS 3, November 1993. [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", RFC 1208, March 1991.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993. [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994. [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000. [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001. [RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002. [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, Eds., "Security Mechanisms for the Internet", RFC 3631, December 2003. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [bmwg-acc-bench] Poretsky, S., "Framework for Accelerated Stress Benchmarking", Work in Progress, October 2003. [Schneier] Schneier, B., "Applied Cryptography, 2nd Ed., Publisher John Wiley & Sons, Inc.", 1996.
o 'CLI' Supports Management Over 'Slow' Links o Document Command Line Interface o Support Software Installation o Support Remote Configuration Backup o Support Remote Configuration Restore o Support Text Configuration Files o Ability to Identify All Listening Services o Ability to Disable Any and All Services o Ability to Control Service Bindings for Listening Services o Ability to Control Service Source Addresses o Ability to Filter Traffic o Ability to Filter Traffic TO the Device o Support Route Filtering o Ability to Specify Filter Actions o Ability to Log Filter Actions o Ability to Filter Without Significant Performance Degradation o Ability to Specify Filter Log Granularity o Ability to Filter on Protocols o Ability to Filter on Addresses o Ability to Filter on Protocol Header Fields o Ability to Filter Inbound and Outbound o Packet Filtering Counter Requirements o Ability to Display Filter Counters o Ability to Display Filter Counters per Rule
o Ability to Display Filter Counters per Filter Application o Ability to Reset Filter Counters o Filter Counters Must Be Accurate o Logging Facility Uses Protocols Subject To Open Review o Logs Sent To Remote Servers o Ability to Log Locally o Ability to Maintain Accurate System Time o Display Timezone And UTC Offset o Default Timezone Should Be UTC o Logs Must Be Timestamped o Logs Contain Untranslated IP Addresses o Logs Contain Records Of Security Events o Authenticate All User Access o Support Authentication of Individual Users o Support Simultaneous Connections o Ability to Disable All Local Accounts o Support Centralized User Authentication Methods o Support Local User Authentication Method o Support Configuration of Order of Authentication Methods o Ability To Authenticate Without Plaintext Passwords o Passwords Must Be Explicitly Configured Prior To Use o No Default Passwords o Ability to Define Privilege Levels o Ability to Assign Privilege Levels to Users
o Default Privilege Level Must Be 'None' o Change in Privilege Levels Requires Re-Authentication o Support Recovery Of Privileged Access o Logs Do Not Contain Passwords o Security Features Must Not Cause Operational Problems o Security Features Should Have Minimal Performance Impact o Identify Services That May Be Listening o Document Service Defaults o Document Service Activation Process o Identify Origin of IP Stack o Identify Origin of Operating System o Identify Origin of IP Stack o Identify Origin of Operating System o Layer 2 Devices Must Meet Higher Layer Requirements
o Support Directional Application Of Rate Limiting Per Interface o Support Rate Limiting Based on State o Ability to Filter Traffic THROUGH the Device
o Apologies to those who commented on/contributed to the document and were not listed.
Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.