ISMS U. Blumenthal Internet-Draft Intel Corporation Expires: August 17, 2005 L. Dondeti Nortel Networks R. Presuhn, Ed. R. Presuhn Consulting E. Rescorla RTFM, Inc. February 13, 2005 Comparison of Proposals for Integrated Security Models for SNMP (Simple Network Management Protocol) draft-ietf-isms-proposal-comparison-00 Status of this Memo 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 17, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Blumenthal, et al. Expires August 17, 2005 [Page 1] Internet-Draft ISMS Proposal Comparison February 2005 Although the Simple Network Management Protocol (SNMPv3) is secure, operators and administrators have found that deploying it can be problematic in large distributions, due to a lack of integration between its User-Based Security Model (USM) and other authentication and user management infrastructure. This memo contains an evaluation of three proposals for an integrated security model for SNMP, and, based on these proposals, suggests how the ISMS (Integrated Security Model for SNMP) working group might move forward. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Operational Scenarios . . . . . . . . . . . . . . . . . . 6 2.4 Proposals Considered . . . . . . . . . . . . . . . . . . . 7 2.4.1 User Security Model . . . . . . . . . . . . . . . . . 7 2.4.2 External User Security Model . . . . . . . . . . . . . 8 2.4.3 Session-Based Security Model . . . . . . . . . . . . . 10 2.4.4 Transport-Layer Security Model . . . . . . . . . . . . 11 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 3.1 Architectural View . . . . . . . . . . . . . . . . . . . . 13 3.2 Supported Security Infrastructures . . . . . . . . . . . . 13 3.3 Integration with VACM . . . . . . . . . . . . . . . . . . 13 3.4 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.1 Session Keys . . . . . . . . . . . . . . . . . . . . . 14 3.4.2 Number of Security Levels per Session . . . . . . . . 14 3.4.3 User Caching . . . . . . . . . . . . . . . . . . . . . 15 3.5 Need for Initial Shared Secrets . . . . . . . . . . . . . 15 3.6 Reuse of Existing Security Protocols . . . . . . . . . . . 15 3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Informative References . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 21 Blumenthal, et al. Expires August 17, 2005 [Page 2] Internet-Draft ISMS Proposal Comparison February 2005 1. Introduction SNMPv3 became a full Internet Standard in late 2002, adding security to the previous versions of the protocol. Although the enhanced protocol is secure, operators and administrators have found that deploying it can be problematic in large distributions, due to a lack of integration between USM and other authentication and user management infrastructure. This memo contains an evaluation of three proposals for an integrated security model for SNMP, and, based on these proposals, suggests how the ISMS working group might move forward. Readers should be reminded that, in accordance with [RFC2418] section 6.5, the working group is free to adopt, reject, ignore or modify these recommendations in whatever way it sees fit. 1.1 Terms and Abbreviations The following list defines the terms and abbreviations used here, and, where appropriate, provides references to further information on the relevant concepts. AAA: Authentication, Authorization and Accounting [RFC2903] CLI: Command Line Interface Diameter: (not an acronym) [RFC3588] DTLS: Datagram Transport Layer Security [I-D.rescorla-dtls] EUSM: External User Security Model [I-D.kaushik-snmp-external-usm] IKE: Internet Key Exchange [RFC2409] IPsec: IP Security [RFC2401] Kerberos: a third-party authentication protocol defined in [RFC1510] LDAP: Lightweight Directory Access Protocol [RFC2251] MAC: Message Authentication Code PDU: Protocol Data Unit RADIUS: Remote Authentication Dial In User Service [RFC2865] Session: Not quite a connection, nor an association, and not to be confused with a CLI session, we use the term session here to refer to a sequence of exchanges between two SNMP engines making on behalf of a single user and secured by the same key, as well as any PDU exchanges needed to establish or tear down the session. SBSM: Session Based Security Model [I-D.hardaker-snmp-session-sm] SNMP: Simple Network Management Protocol [RFC3410] SSH: Secure Shell protocol [I-D.ietf-secsh-architecture] Blumenthal, et al. Expires August 17, 2005 [Page 3] Internet-Draft ISMS Proposal Comparison February 2005 TACACS+: Terminal Access Controller Access Control System (plus) [RFC1492] TCP: Transmission Control Protocol [RFC0793] TLS: Transport Layer Security protocol [RFC2246] TLSM: Transport Layer Security Model [I-D.schoenw-snmp-tlsm] UDP: User Datagram Protocol [RFC0768] USM: User-Based Security Model [RFC3414] VACM: View-Based Access Control Model [RFC3415] 2. Overview Version 3 of the Simple Network Management Protocol (SNMPv3) was elevated to Internet Standard in late 2002 and added security to the previous versions of the protocol. Although the enhanced protocol is secure, operators and administrators have found that deploying it could be problematic in large distributions. There have been two major sources of difficulty. First, most networking devices already contain local accounts or the ability to negotiate with authentication servers, such as RADIUS servers. However, SNMPv3 does not make use of these authentication mechanisms, but instead adds its own SNMPv3-specific authentication system, which needs to be maintained across all networking devices. Secondly, the distribution and maintenance of View-based Access Control Model (VACM) rules is also difficult in large-scale environments. 2.1 Background In principle, SNMP has modular security, with communications security being provided via different "security models". In practice, SNMP security is done via the "User-based Security Model" [RFC3414], which is essentially per-message encryption and authentication inside of SNMP. USM keying is based on per-user shared keys, used between SNMP engines that need to communicate securely on behalf of management applications. (The traditional terms "manager" and "agent" are not particularly helpful, since both kinds of applications may make use of a given SNMP protocol engine at the same time.) Key localization techniques are used to minimize the impact of the compromise of a shared key. There are two major sources of discontent with USM: 1. Key management with manual keying is extremely difficult in any system. SNMP is no different. (major reason) 2. USM anti-replay protection is limited by design (minor reason). A message may be replayed within a 150 second window. Note that for set operations where ordering and non-duplication can be important, this can be largely mitigated by the use of TestAndIncr [RFC2579] objects. Blumenthal, et al. Expires August 17, 2005 [Page 4] Internet-Draft ISMS Proposal Comparison February 2005 A number of alternative designs have been proposed to improve SNMP security. We discuss three here: EUSM: External User Security Model [I-D.kaushik-snmp-external-usm] SBSM: Session Based Security Model [I-D.hardaker-snmp-session-sm] TLSM: Transport Layer Security Model [I-D.schoenw-snmp-tlsm] Evaluating these documents is difficult because they vary along two primary axes: 1. Architectural -- each of these designs is very different in terms of how it integrates with the SNMP architecture. 2. Features -- each design provides some support for automatic key management, but with a fair amount of variety in the kinds of credentials supported. To a first order, these concerns are orthogonal. The intent of this document is to evaluate the merits of various architectural approaches, without regard to the specific implementation details of the authentication mechanisms proposed in these drafts. In order to do this, we will confine the following discussion to idealized architectural sketches of the approach used by each protocol. We begin by describing the existing User-based Security Model, both for reference and to simplify comparison of the other schemes. 2.2 Goals The ISMS (Integrated Security Model for SNMP) working group was chartered to identify a solution for the first of the two above-mentioned problems: creating a security model for SNMPv3 that will meet the security and operational needs of network administrators. The goals were to maximize usability in operational environments to achieve high deployment success and at the same time minimize implementation and deployment costs to minimize the time until deployment would be possible. The ability to make use of existing and commonly deployed security infrastructure was a requirement, as was consideration of the following as potential existing authentication infrastructures to make use of within the new security model, with at least one being mandatory: * Local accounts * SSH identities * RADIUS * TACACS+ * X.509 Certificates * Kerberos * LDAP Blumenthal, et al. Expires August 17, 2005 [Page 5] Internet-Draft ISMS Proposal Comparison February 2005 * Diameter The working group's charter constrains the solution. It must not modify the other aspects of SNMPv3 protocol as defined in STD 62. It should also be compliant with the security model architectural block of SNMPv3, as outlined in [RFC3411]. Finally, it should also not change any other protocols. In addition to goals and requirements given in the working group charter, discussion on the mailing list and in working group meetings helped identify additional points to consider in evaluating proposals: * Must be at least as secure as USM [RFC3414]. * Must not preclude the use of USM [RFC3414], particularly if network instability could cause problems for the proposed solution * Must be able to work with VACM. * The protocol itself should support multiple security infrastructures, but an implementation may support some subset of these. * Must not break basic device discovery. (Retaining USM support would satisfy this goal.) In the documents and on the mailing list, some additional potential goals and requirements have been mentioned, but did not seem to enjoy widespread support. This does not mean that the evaluation team contests that they may be desirable; it simply means that these were given secondary importance in our evaluation. These include: * support for anonymous secured access (to ensure integrity of results) * implementation impact * deployment impact * time to market * stronger reorder / replay protection 2.3 Operational Scenarios How well proposals satisfy the goals described above can be evaluated by looking at specific operational scenarios or use cases. Ones mentioned on the mailing list include: * deploying a new device, such as a router * adding access for a new user * revoking access for a user * changing a user's secrets Blumenthal, et al. Expires August 17, 2005 [Page 6] Internet-Draft ISMS Proposal Comparison February 2005 In looking at each of these cases, one must consider what steps are needed with classic USM, which steps under the proposal under evaluation would be needed anyway (in order to support, for example, a CLI), how much of the classic USM work could be avoided under the proposal, and what additional configuration is needed to support the proposal. 2.4 Proposals Considered This section provides a brief review of USM, and then gives an overview of each of the proposals. 2.4.1 User Security Model The User-based Security Model [RFC3414] is a simple shared secret scheme. The operator configures secrets in the SNMP engines used by management applications. (Management applications include things traditionally considered "managers" and "agents".) These secrets may be "localized keys", computed from a passphrase known only to that user. These independent authentication and encryption keys are used to secure communication. Traffic may be authenticated, or authenticated and encrypted. The protocol also supports unauthenticated unencrypted exchanges, but they are not of interest here. +------------------------+ +------------------------+ | Manager | | Managed | | Computer | | Device | | +--------------------+ | | +--------------------+ | | | SNMP Engine | | | | SNMP Engine | | | | | | | | | | | | | | <------------> | | | | | | +-------+ | | | | +-------+ | | | | | USM | | | | | | USM | | | | | +-------+ | | | | +-------+ | | | +--------------------+ | | +--------------------+ | +------------------------+ +------------------------+ Figure 1 With USM security, the USM is part of the SNMP implementation. Messages to be protected are passed through the USM for transformation (encryption and/or authentication). When protected messages are received, they are passed through the USM for processing (decryption and/or authentication). The SNMP engine must keep track of whether a message had been encrypted and authenticated in order to make access control decisions. Blumenthal, et al. Expires August 17, 2005 [Page 7] Internet-Draft ISMS Proposal Comparison February 2005 As previously noted, this scheme has two disadvantages. First, even though all the localized keys for a given user in an administrative domain may be generated automatically from a single passphrase, device and user churn can still make it difficult to configure. Secondly, the particular message protection scheme, by design, does not provide replay protection inside a 150 second window. Being able to perform management operations while the underlying protocols were experiencing packet loss, duplication, or re-ordering was considered more important than protecting against replay attacks within a 150 second window, particularly since such attacks can be blocked by using a TestAndIncr [RFC2579] object to protect set requests which could do damage if replayed within the 150 second window. 2.4.2 External User Security Model The External User Security Model [I-D.kaushik-snmp-external-usm] replaces USM's key management but leaves the USM transport alone. EUSM assumes that an external key management process will be co-resident with SNMP engines, and will install the keys, as with IKE/IPsec. +------------------------+ +----------------------+ | Manager | | Managed | | Computer | | Device | | | | | | +---------+ | | +--------+ | | | Key | | Key establish | | Key | | | | Mgmt | |<----------------->| | Mgmt | | | +---------+ | | +--------+ | | ^ | | ^ | | +---------------|----+ | | +---|--------------+ | | | SNMP Engine | | | | | | SNMP Engine | | | | | | | Message traffic | | | | | | | v | | <---------------> | | v | | | | +-------+ | | | | +-------+ | | | | | USM | | | | | | USM | | | | | +-------+ | | | | +-------+ | | | +--------------------+ | | +------------------+ | +------------------------+ +----------------------+ Figure 2 In EUSM, the SNMP engines establish keys using the external key management system. Those keys are then passed to the USM, and create (or at least key) users (or pseudo-users). From that point on, ordinary USM message protection is used. One advertised advantage of EUSM is tight integration with Blumenthal, et al. Expires August 17, 2005 [Page 8] Internet-Draft ISMS Proposal Comparison February 2005 pre-existing network AAA systems such as RADIUS and DIAMETER. The general picture is shown below: the key management processes coordinate with the AAA server to perform the key agreement exchange. +---------+ | AAA | --------> | Server |<--------| | +---------+ | | | | | +------------------|-----+ +---|-----------------+ | Manager | | | | Managed | | Computer | | | | Device | | v | | v | | +---------+ | | +--------+ | | | Key | | Key establish | | Key | | | | Mgmt | |<----------------->| | Mgmt | | | +---------+ | | +--------+ | | ^ | | ^ | | +---------------|----+ | | +---|-------------+ | | | SNMP Engine | | | | | | SNMP Engine | | | | | | | Message traffic | | | | | | | v | | <---------------> | | v | | | | +-------+ | | | | +-------+ | | | | | USM | | | | | | USM | | | | | +-------+ | | | | +-------+ | | | +--------------------+ | | +-----------------+ | +------------------------+ +---------------------+ Figure 3 It's important to recognize that this is not an architectural advantage. Whether an AAA server is involved or not is completely orthogonal to the external key management design. One could use this general design with or without AAA integration. In order to reduce diagram complexity, we will not show AAA integration for the other approaches, although it is in general as easy to add *architecturally* to one approach as to the others. The primary advantage of this scheme is that it has very little impact on the SNMP implementation. Because the implementation already has the ability to accept externally specified (manual) keys, it is straightforward to modify the design to accept externally specified keys which are generated via an automatic key management process. This is part of the reason why a similar design was chosen for IKE/IPsec. EUSM also has the desirable feature of integrating very well with RADIUS, desirable due to its large market presence. An additional advantage, as well as a limitation of this approach, is Blumenthal, et al. Expires August 17, 2005 [Page 9] Internet-Draft ISMS Proposal Comparison February 2005 the extent to which it reuses USM, since at leaves USM's anti-replay mechanisms intact. This approach has several drawbacks. The first is that it inherits the communications security limitations of USM with respect to replay attack. The second is that it because the integration of the external key management module with the SNMP implementation is relatively loose, it can make policy setting confusing. In particular, it could be difficult to coordinate users between various processes. The coordination of permissions could likewise be a problem, but VACM coordination is out of scope of this effort, and none of the other proposals address this issue, which has been a substantial problem with IKE/IPsec. An additional consideration is that it's not clear how this could be used with Kerberos, at least as Kerberos is normally used. A secondary problem is that it can be difficult for the key management system to give the USM and the rest of the SNMP implementation information about users. Looking ahead to the integration of access control configuration, the ability to reuse the existing key management interfaces starts to be inadequate. However, none of proposals do anything to address this, since almost all the user-specific information other than keys belongs to VACM. This proposal's way of addressing policy integration by providing the user/group mapping for VACM seems to be a good tradeoff, giving dynamic authentication and integration with existing access control without excessive overhead. 2.4.3 Session-Based Security Model The Session-Based Security Model [I-D.hardaker-snmp-session-sm] addresses the first disadvantage by replacing the USM entirely. The new security model (SBSM) is an integrated session establishment and messaging protocol. When two network entities wish to communicate initially, SBSM performs a key agreement handshake to establish a session. From then on, messages are protected inside of SNMP. That is, the ciphertext and/or MAC data is encapsulated inside of an SNMP message, just as with USM and EUSM. Blumenthal, et al. Expires August 17, 2005 [Page 10] Internet-Draft ISMS Proposal Comparison February 2005 +----------------------+ +----------------------+ | Manager | | Managed | | Computer | | Device | | +------------------+ | | +------------------+ | | | SNMP Engine | | | | SNMP Engine | | | | | | | | | | | | | | <------> | | | | | | +-----+ +------+ | | | | +------+ +-----+ | | | | | USM | | SBSM | | | | | | SBSM | | USM | | | | | +-----+ +------+ | | | | +------+ +-----+ | | | +------------------+ | | +------------------+ | +----------------------+ +----------------------+ Figure 4 This design allows the tightest coupling between the security system and the rest of the SNMP implementation. Authentication information, such as user names and session lifetime constraints, can be easily passed between them. This approach has the advantage of providing an extensible architecture and making it possible to integrate almost any authentication or privacy mechanism. The major disadvantage of this design is that because it is so tightly coupled to the SNMP implementation, it may require a fair amount of reinvention. Indeed, the current SBSM design is a completely new security protocol. In principle, one could use an existing protocol such as IKE or TLS, but encapsulate all the message traffic in SNMP in the same way as the current SBSM, but it's not clear that that design would be superior to TLSM (below). In any case, going with SBSM would require a careful evaluation of the security protocol. An open issue here is how to tie whatever identity the this security model has for a user with the security name needed by VACM to do the user-to-group mapping. If these need to be pre-configured in VACM, the value is diminished. 2.4.4 Transport-Layer Security Model The Transport Layer Security Model [I-D.schoenw-snmp-tlsm] simply rehosts all SNMP communications over a new secure transport. The obvious choices here are TLS (for TCP) and DTLS (for UDP). However, from an architectural perspective, any self-contained generic channel security mechanism (such as IPsec or SSH) would also be fine. This produces a picture like the one below. Blumenthal, et al. Expires August 17, 2005 [Page 11] Internet-Draft ISMS Proposal Comparison February 2005 +------------------------+ +------------------------+ | Manager | | Managed | | Computer | | Device | | +--------------------+ | | +--------------------+ | | | SNMP Engine | | | | SNMP Engine | | | | | | | | | | | | | | <- - - - - -> | | | | | | +------+ +-------+ | | | | +-------+ +------+ | | | | | TLSM | | USM | | | | | | USM | | TLSM | | | | | +------+ +-------+ | | | | +-------+ +------+ | | | +----^---------------+ | | +-----^--------------+ | | | | | | | | +----v---------------+ | | +-----v--------------+ | | | Security layer | | <-----------> | | Security layer | | | +--------------------+ | | +--------------------+ | +------------------------+ +------------------------+ Figure 5 With the TLSM architecture, there is a new security model, the TLSM, but it's effectively a shim. All the heavy lifting is done by the generic security layer/protocol. The TLSM's only job is to provide the user name and security level to the security layer and to collect the per-message security properties. The downside to this is that the question of how the security layer's user names get mapped to security names for VACM is left open. This can be addressed either by preconfiguration, which defeats the purpose of the proposal, or by borrowing something like the EUSM proposal's mechanism for emulating the security name to group mapping for VACM. From the network perspective, SNMP traffic secured with TLSM looks like every other kind of traffic secured with the underlying security layer. The only indication that it is SNMP is (potentially) the choice of port number. TLSM allows reuse of standard communications security tools (e.g., TLS) while allowing a reasonable amount of coupling between the security layer and the SNMP implementation. However, it will likely be more work to integrate than EUSM and allow a less rich coupling than SBSM. 3. Recommendations The evaluation team was unable to identify a clear winner among the three proposals. Each of the documents contained some of the elements needed for a complete solution. In part, this was due to the preliminary nature of the internet drafts that were available, and the different teams had fleshed out different elements of their Blumenthal, et al. Expires August 17, 2005 [Page 12] Internet-Draft ISMS Proposal Comparison February 2005 proposals in differing degrees of detail. 3.1 Architectural View The evaluation team recommends the inclusion of an architectural perspective, like that provided by the TLSM proposal, though, of course, adapted to the technical specifics of the agreed solution. In particular, it's important to spell out where the various bits come from that are needed for the message processing model and security model abstract service interfaces, as well as what goes into message wrappers and any inter-layer redundancies. When authentication or encryption services are provided by other protocols outside SNMP proper, whether existing APIs provide these bits is an important consideration in gauging what the implementation effort would be. The SNMPv3 architecture goes to some length to avoid talking about managers and agents, and is instead described in terms of SNMP engines and applications. This was motivated by practical considerations and implementation experience, not just architectural purity. The evaluation team recommends that this working group maintain this perspective. 3.2 Supported Security Infrastructures The evaluation team recommends that the working group adopt an approach that can accommodate multiple security infrastructures concurrently. The EUSM proposal was clearest in this regard and went into the greatest detail, though clearly still greater detail will be needed for an interoperable specification. Note however that EUSM specifies integration with a specific authentication architecture, viz., AAA; we suggest the incorporation of a generic authentication architecture, with AAA as the case study. Either the EUSM specification or an independent specification can then describe how Kerberos (or any other authentication architecture) might be integrated. This is justified by the extreme diversity of security infrastructures currently in use, and the lack of compelling arguments justifying the selection of one to the exclusion of all others. The evaluation team also recommends, in the interest of interoperability, that the working group select a single mandatory-to-implement mechanism. The evaluation team recommends RADIUS [RFC2865] for this purpose, due to its widespread use. 3.3 Integration with VACM The SNMP architecture in general recognizes that how a user is Blumenthal, et al. Expires August 17, 2005 [Page 13] Internet-Draft ISMS Proposal Comparison February 2005 identified in a particular security model may need to be mapped to a protocol-independent identifier, allowing integration of different authentication schemes, for example. USM uses the usmUserSecurityName object to accomplish this. The evaluation team recommends that ways to support such mappings be investigated, since none of the proposals directly addresses this issue. Dynamic authentication of users is not operationally sufficient, given how VACM works. Requiring security administrators to pre-configure the vacmSecurityToGroupTable [RFC3415] for dynamically authenticated users would defeat the whole purpose of doing dynamic authentication. Consequently, the evaluation team recommends the inclusion of something similar to the EUSM proposal's mechanism for conveying user-to-group mappings from the AAA-server-equivalent. This should not be confused with full-scale configuration of VACM, which is out of scope for this working group. 3.4 Sessions All the proposals introduce something like a session. This allows the cost of authentication to be amortized over potentially many transactions. 3.4.1 Session Keys The SBSM proposal's mechanism for session key establishment is attractive in explicitly addressing the perfect forward secrecy goal, at least for encryption keys. The same functionality could, however, be obtained using the TLSM approach as well. Perfect forward secrecy guarantees that compromise of long term secret keys does not result in disclosure of past session keys. While this is a useful property, it comes at a fairly substantial computational cost, and in some cases additional message exchanges. There is no clear consensus in the evaluation team about this requirement. 3.4.2 Number of Security Levels per Session The discussion on the mailing list and in face-to-face meetings led the evaluation team to recommend that a session should have a single user and security level associated with it. If an exchange between communicating engines would require a different security level or would be on behalf of a different user, then another session would be needed. An immediate consequence of this is that implementations should be able to maintain some reasonable number of concurrent sessions. Blumenthal, et al. Expires August 17, 2005 [Page 14] Internet-Draft ISMS Proposal Comparison February 2005 3.4.3 User Caching The discussion of user cache lifetimes revealed that different types of interactions had different requirements. For example, ongoing polling was different from configuration requests. Consequently, the evaluation team recommends that cache lifetimes not be hard-wired. Lifetime could be communicated with the authentication results from the authentication server, with a configurable default in the managed device for those cases where the authentication server does not communicate a user cache entry lifetime. 3.5 Need for Initial Shared Secrets Since RADIUS requires a shared secret to be established between the RADIUS client and server, it has the same out-of-box problem as USM, where one needs to establish the keys for the security administrator, who can then create the other users and VACM configurations. None of the proposals address this problem. 3.6 Reuse of Existing Security Protocols The evaluation team considers designing and developing a new key management protocol for SNMPv3 an unnecessarily complex process and generally recommends reuse of existing security protocols where possible and appropriate. In other words, if an existing protocol is sufficient for the task at hand, the WG's energies are better spent elsewhere in the design of the overall solution for SNMPv3 security. 3.7 Conclusion We conclude that neither of the three proposals matches all recommendations. On the other hand, each of them has one or more desirable properties that others might draw on to improve their original designs. It is quite tempting to conclude that the protocols be "merged" to create a single ISMS protocol. However, that would be ambiguous and would delay the process further. The evaluation team concludes that the EUSM architecture would be the right direction for the ISMS WG. However, a number of aspects of the EUSM design need moderate to substantial revision. In the following, we first describe the components of the design that we consider most attractive, and then list the components that need to be revised and suggest components from other proposals as examples as appropriate: o EUSM keeps the current USM model intact. o EUSM integrates well with the AAA architecture. The evaluation team has the following recommendations to improve this interaction. Blumenthal, et al. Expires August 17, 2005 [Page 15] Internet-Draft ISMS Proposal Comparison February 2005 * First, as noted earlier, where possible the design should not distinguish between agent and manager, following the SNMPv3 architecture. * Next, consider the possibility of using the AAA architecture or any external authentication infrastructure to establish shared secrets a la 802.11i architecture. Specifically, one of the problems with USM is that between n SNMP engines, there might O(n^2) pre-shared keys. The use of a centralized architecture will help reduce these keys to O(n), with each engine only authenticating to a common entity external to the SNMP world. As necessary, any two engines engaging in secure communication can establish a common key between them, and generate session keys as required by running Bellare-Rogaway's "entity authentication and key distribution" protocol [EAKD]. This will help reduce the number of interactions between the SNMP engines and the AAA server. * The evaluation team recommends that the eventual EUSM architecture be generic enough to support Kerberos and other authentication architectures. o EUSM is also quite inline with the consensus in the evaluation team that, as much as possible the ISMS protocol should be reusing existing protocols. * We recommend the EUSM specification clearly identity the work in progress protocols that they use, so that the ISMS WG is aware of the dependencies on, say PANA, PEAP to name a few. * The other consideration is that the overall architecture once complete should be evaluated thoroughly from a security point of view. It is very easy to put together two independently secure protocols and open an avenue for a MiTM attack as shown by the compound binding attack. * We have several specific concerns (listed below) about some protocol choices in EUSM, which should be evaluated and justified with analysis and/or WG consensus as applicable. + There is a reference to CBC-DES in Section 3.5.1. Perhaps it is a typo. + EAP-GTC is suggested as the inner EAP method for client authentication. Q: Shouldn't the inner EAP method need to be a key generating method for compound binding? Furthermore WLAN EAP method recommendations draft specifically excludes GTC as the inner EAP method (see [I-D.walker-ieee802-req]). + There should be a discussion on PEAP vs. other tunneled EAP methods, e.g., EAP-TLS, TTLS etc. o As noted in Section 3.1, the evaluation team suggests that EUSM be revised to integrate well with RFC 3411 architecture as done by the TLSM specification (Please see Section 3.3 - 3.5 and Section 4 in the TLSM specification [I-D.schoenw-snmp-tlsm]). Blumenthal, et al. Expires August 17, 2005 [Page 16] Internet-Draft ISMS Proposal Comparison February 2005 4. Acknowledgments Working group co-chairs Ken Hornstein and Juergen Quittek facilitated the meetings of the evaluation team, goading the team to stay focused and on schedule. The working group charter provided text on requirements and goals. 5. Security Considerations This document compares three different proposals that fix the problems associated with USM for SNMPv3 security. They are all architecturally distinct from each other, and have different security properties and potential security issues. The reader is referred to the security considerations section within the drafts describing the three proposals. 6. IANA Considerations This document requires no actions by IANA. All of the proposals evaluated herein would require IANA action if adopted by the working group, but in no case was this seen to present a significant obstacle. For example, all the proposals would require the allocation of a new value for SnmpSecurityModel [RFC3411]. 7. Informative References [EAKD] Bellare, M. and P. Rogaway, "Entity Authentication and Key Distribution", Advances in Cryptology, Crypto '93, Lecture Notes in Computer Science 773, 1994. [I-D.hardaker-snmp-session-sm] Perkins, D. and W. Hardaker, "A Session-Based Security Model (SBSM) for version 3 of the Simple Network Management Protocol (SNMPv3)", Internet-Draft draft-hardaker-snmp-session-sm-03, October 2004. [I-D.ietf-secsh-architecture] Lonvick, C., "SSH Protocol Architecture", Internet-Draft draft-ietf-secsh-architecture-20, December 2004. [I-D.kaushik-snmp-external-usm] Narayan, K., "External User Security Model (EUSM) for version 3 of the Simple Network Management Protocol (SNMPv3)", Blumenthal, et al. Expires August 17, 2005 [Page 17] Internet-Draft ISMS Proposal Comparison February 2005 Internet-Draft draft-kaushik-snmp-external-usm-01, February 2005. [I-D.rescorla-dtls] Rescorla, E., "Datagram Transport Layer Security", Internet-Draft draft-rescorla-dtls-02, December 2004. [I-D.schoenw-snmp-tlsm] Harrington, D. and J. Schoenwaelder, "Transport Layer Security Model (TLSM) for the Simple Network Management Protocol version 3 (SNMPv3)", Internet-Draft draft-schoenw-snmp-tlsm-01, November 2004. [I-D.walker-ieee802-req] Stanley, D., Walker, J. and B. Aboba, "EAP Method Requirements for Wireless LANs", Internet-Draft draft-walker-ieee802-req-04, August 2004. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993. [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. Blumenthal, et al. Expires August 17, 2005 [Page 18] Internet-Draft ISMS Proposal Comparison February 2005 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J. and D. Spence, "Generic AAA Architecture", RFC 2903, August 2000. [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. [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Blumenthal, et al. Expires August 17, 2005 [Page 19] Internet-Draft ISMS Proposal Comparison February 2005 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Authors' Addresses Uri Blumenthal Intel Corporation USA Phone: +1 973-967-6446 Email: uri.blumenthal@intel.com Lakshminath Dondeti Nortel Networks 600 Technology Park Drive Billerica, Massachusetts 01821 USA Phone: +1 978-288-6406 Email: ldondeti@nortel.com Randy Presuhn (editor) R. Presuhn Consulting San Jose, California 95120 USA Phone: +1 408-268-2075 Email: randy_presuhn@mindspring.com Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, California 94303 USA Phone: Email: ekr@rtfm.com Blumenthal, et al. Expires August 17, 2005 [Page 20] Internet-Draft ISMS Proposal Comparison February 2005 Intellectual Property Statement 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-ipr@ietf.org. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Blumenthal, et al. Expires August 17, 2005 [Page 21]