Network Working Group Kaushik Narayan Internet-Draft Keith McCloghrie Expiration Date: August 17, 2005 Joseph Salowey Cisco Systems Inc. Feb 2005 External User Security Model (EUSM) for version 3 of the Simple Network Management Protocol (SNMPv3) draft-kaushik-snmp-external-usm-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I 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 in August 2005. Copyright Notice Copyright (C) The Internet Society 2005. Narayan et al. Expires Aug 2005 [Page 1] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 Abstract This specification defines a framework for SNMPv3 authentication and key distribution with support for various authentication systems such as RADIUS, X.509 certificates, Local Accounts, Kerberos etc. Support for these authentication systems for SNMPv3 allows for a common identity to be used with/shared across all management protocols since the other network management interfaces such as the NetConf protocol and device Command Line Interface (CLI) are already using these authentication systems. This specification defines a new security model for SNMPv3, the External User Security Model (EUSM). This EUSM model differs from USM in only one respect: it uses out-of-band authentication protocols to establish keying material for the user for achieving the security goals defined in "RFC3414". Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language. . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Issues with USM. . . . . . . . . . . . . . . . . . . . 4 2.2. Design Considerations . . . . . . . . . . . . . . . . . 4 3. Elements of the Solution . . . . . . . . . . . . . . . . . . . . 6 3.1. Key Setup Protocol . . . . . . . . . . . . . . . . . . . 6 3.2. Key Request Protocol . . . . . . . . . . . . . . . . . . 8 3.3. EUSM Processing . . . . . . . . . . . . . . . . . . . . .10 3.4. Modifications to SNMPv3 View Based Access Control (VACM).11 3.5. Key Caching . . . . . . . . . . . . . . . . . . . . . . .11 3.5.1. Handling Cache Synchronization Issues. . . . . . 12 3.6 Security Context Identification . . . . . . . . . . . . .13 3.7 RADIUS Server Failover . . . . . . . . . . . . . . . . 14 4. Dependencies on Work in Progress. . . . . . . . . . . . . . . . 14 4.1. Extensible Authentication Protocol (EAP) . . . . . . . .14 4.2. RADIUS. . . . . . . . . . . . . . . . . . . . . . . . . .14 4.3. Protocol for carrying Authentication for Network Access .14 5. Security Considerations. . . . . . . . . . . . . . . . . . . . .15 6. IPv6 Considerations. . . . . . . . . . . . . . . . . . . . . . .15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 10. Intellectual Property Statement . . . . . . . . . . . . . . . . 18 Narayan et al. Expires Aug 2005 [Page 2] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 1. Introduction SNMPv3 provides a framework for user identity based authentication, privacy and granular access control. SNMPv3 aids secure manageability and overcomes one of major drawbacks in previous versions of the SNMP standard. There has been a significant lack of uptake for deployment of SNMPv3, and a number of organizations are still using SNMPv1/SNMPv2c. This is because SNMPv3 does not integrate with authentication systems currently used by existing management interfaces like the device command line interfaces. This specification defines a new security model for SNMPv3, the External User Security Model (EUSM). The EUSM primarily addresses the same threats as defined in the SNMPv3 USM Specification [RFC3414], this model intends to achieve the same goals as USM, this model intends to remove the constraint, i.e. "The security protocol nor its underlying security mechanisms should depend upon the ready availability of other network services". This EUSM model will use out-of-band authentication protocols to establish keying material for the user for achieving the security goals defined in [RFC3414]. EUSM is exactly similar to USM in all aspects, except for one key difference, that security information is established dynamically, as opposed to having it permanently stored in the Local Configuration Datastore. The use of out-of-band authentication protocols, namely the Extensible Authentication Protocol (EAP), allows EUSM to support a variety of authentication systems such as RADIUS servers, X.509 certificates, Local Accounts and Kerberos. EUSM defines a framework for SNMPv3 authentication and key distribution. The Extensible Authentication Protocol (EAP) has been commonly used in 802.1x environments for authentication and key establishment, this specification leverages work done in that area. This memo allows SNMPv3 authentication and privacy keys to be established out-of-band based on credentials managed locally on devices hosting the SNMP engines or credentials externally managed by a AAA server. Current schemes require SNMPv3 keys to be configured on a per engine basis. Support for a variety of local authentication systems in addition to support for external authentication via AAA protocols provides the advantage of allowing a common identity to be used with/shared across all management protocols since the other network management interfaces like device CLI and XML access are capable of authentication with the same authentication systems. Such sharing of common authentication systems removes the need for their separate maintenance, and thereby reduces administrative overhead. Narayan et al. Expires Aug 2005 [Page 3] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Overview EUSM describes the use of an out-of-band Key Setup Protocol for mutual authentication and setup of a security context to establish keys for SNMP engines. The security context refers to a pair of data structures that contain shared state information, which is required in order that per-message security services may be provided to SNMPv3 packets. Examples of state that are shared as part of a security context are cryptographic keys, and message sequence numbers. The security context specified here is different from the SNMP context described in [RFC3411]. The Key Setup protocol operates between SNMP engines or between the non-authoritative SNMP engine and a AAA server based on the desired authentication system to be used. In case a AAA server is involved, the non-authoritative SNMP engine will setup the security context with the AAA server prior to communicating with the authoritative SNMP engines. This specification recommends the use of the Extensible Authentication Protocol (EAP) as the Key Setup Protocol. As part of the establishment of a security context, the two SNMP engines or the non-authoritative SNMP engine and the AAA server are mutually authenticated, and on successful authentication, will generate a master session key. Keys derived from the master session key will be used to protect the communication between the two authenticated SNMP Engines or in case of the AAA server being involved, keys derived from the master session key will be used to protect the communication between the non-authoritative SNMP engine and all authoritative SNMP engines. This specification also describes a Key Request Protocol that is used by the authoritative SNMP engines to acquire session keys. The Key Request will not involve an over-the-wire protocol in case of authentication systems that do not involve an external AAA server. In case of authentication systems that do involve an external AAA server, the authoritative SNMP engines acquire these session keys from the AAA server via a Key Request Protocol. Narayan et al. Expires Aug 2005 [Page 4] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 The AAA Server MUST derive the session keys for the authoritative SNMP engines. These per-engine "session" keys are derived from the master session key by the process of SNMPv3 key localization. RADIUS is the mandatory to implement external authentication mechanism , but any other AAA Protocol with similar characteristics could also be used. The authoritative SNMP engines also cache the session keys for a short time interval; this time interval is either locally configured or supplied by the RADIUS Server as part of response to Key Request Protocol based on the authentication system used. 2.1. Issues with USM SNMPv3 USM [RFC3414] requires the users and user keys to be configured on every SNMP engine. Although the process can be automated via a SNMPv3 user management application, it does require a configuration management application that can configure ten of thousands of network elements in real time. Further, the USM model creates a parallel universe of SNMPv3 users which are completely different from the users that are used by the other management interfaces like CLI, TCL engine and XML based programmatic interfaces (XMLCONF). 2.2. Design Considerations The design for EUSM are based on the following considerations: 1) The requirement of a scheme for SNMPv3 to support multiple authentication systems such as RADIUS, X.509 certificates, Local accounts and Kerberos to unify the approach for administrative security model for SNMPv3 and CLI. 2) The requirement for SNMPv3 to use strong authentication and key exchange and eliminate the need to use long term secrets to protect SNMPv3 packets. 3) The requirement for minimum number of changes, preferably none to the SNMPv3 packet format given the current status of the SNMPv3 standard. 4) The scheme MUST extend the capability of the AAA server to provide key material for authentication, privacy and integrity protection for SNMPv3 engines. 5) The scheme MUST provide support for a variety of client authentication mechanisms including passwords, tokens and certificates. 6) The scheme MUST to optimize the key management scheme to scale to large numbers of SNMP engines. 7) The scheme MUST distribute keys based on valid security context. 8) The scheme MUST ensure that a separate AAA request is not generated for every SNMP request. 9) This scheme MUST be generic and should apply to existing and future AAA protocols. Narayan et al. Expires Aug 2005 [Page 5] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 3. Elements of the Solution 3.1. Key Setup Protocol The Extensible Authentication Protocol (EAP) will be used as the Key Setup Protocol. Not all EAP mechanisms may be suitable for this . The recommended mechanism depends upon the on desired authentication system as follows. a. EAP-TLS is RECOMMENDED to implement for authentication systems that do not require an external server and where the authentication conversation terminates on the SNMP engine. EAP-TLS supports several types of credentials with various ciphersuites. It supports X.509 PKI credentials using RSA and DSA based ciphersuites, it supports Kerberos with Kerberos based ciphersuites and it supports pre-shared keys using pre-shared key ciphersuites. The figure below illustrates the use of EAP-TLS method as part of Key Setup Protocol operating between two SNMP engines. This EAP method will be used for authentication systems that have credentials managed by the device hosting the SNMP engines. This EAP method will support authentication systems such as local accounts, X.509 certificates and Kerberos. ------------ PANA (EAP(EAP-TLS)), Key Setup Protocol ---------- | |<--------------------------------------->| | | SNMP | | SNMP | | Engine | | Engine | |(Non-Author)| SNMPv3 message | (Author) | | |<--------------------------------------->| | | | | | ------------ ---------- *Author => Authoritative Figure 1: EUSM with EAP-TLS for local authentication systems The EAP-TLS exchange depicted above will setup the master session key on both SNMP engines. The SNMP engines will acquire session keys for communication from the EAP sub-system. In above exchange the EAP messages need to be transported within an appropriate transport protocol that can transport EAP, RADIUS is not usable since it would require all SNMP engines maintain shared secrets. Instead an IP based protocol used to carry EAP messages similar to the one defined by [PANA] can be used. Narayan et al. Expires Aug 2005 [Page 6] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 b. For authentication systems that require the transmission of password based credentials such as one time passwords or plaintext passwords to an external server, such as a RADIUS server, a tunneled mechanism such as PEAP or TTLS MUST be used. PEAPv2 is RECOMMENDED to implement. PEAPv2 will be used as the Key Setup Protocol in EUSM to support RADIUS authentication. The EAP messages can be transported in two modes, the specification supports both modes of transport. The figure below depicts the first mode, the RADIUS protocol is used as transport. The RADIUS protocol is used to carry the EAP messages between the non-authoritative SNMP engine and the RADIUS server. This scheme requires all non-authoritative SNMP engines to have explicit knowledge of the RADIUS server. ------------ SNMPv3 message ---------- | |<---------------------------------------->| | | SNMP | | SNMP | | Engine | | Engine | |(Non-Author)| | (Author) | | | | | ------------ ---------- ^ ^ | | | | | | | RADIUS (EAP (PEAPv2)) RADIUS Protocol | | Key Setup Protocol Acquire Session Keys | | | | | | --------- | ----------------------> | | <----------------- | RADIUS | | Server | | | --------- *Author => Authoritative Figure 2: EUSM with PEAPv2 for RADIUS authentication using RADIUS to transport EAP messages The second mode depicted in the figure below uses an IP based transport such as PANA to carry the EAP messages. This is similar to exchanges used in 802.1x environments. The non-authoritative SNMP engine is similar to a 802.1x supplicant and requires no knowledge of the RADIUS server. The PEAPv2 conversation between the non-authoritative SNMP engine and the RADIUS server is relayed through any one of the authoritative SNMP Engines. Narayan et al. Expires Aug 2005 [Page 7] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 PANA (EAP (PEAPv2)) ------------ Key Setup Protocol ----------- | | <------------------------------> | | | SNMP | | SNMP | | Engine | SNMPv3 message | Engine | |(Non-Author)| <------------------------------> | (Author) | | | | | ------------ ----------- ^ ^ | | RADIUS (EAP (PEAPv2)) | | RADIUS Key Setup Protocol | | Acquire | | Session | | Keys --------- | | | | <------------ | | RADIUS | | | Server | | | | <----------------- --------- *Author => Authoritative Figure 3: EUSM with PEAPv2 for RADIUS authentication using PANA to transport EAP messages Both modes described above only differ in the transport mechanism used for the Key Setup Protocol. All other aspects of this memo apply identically. The rest of this memo uses the first mode for illustration of EUSM for RADIUS authentication, all the flows and processing will identically apply to second scheme as well. 3.2. Key Request Protocol The SNMP engines would use Key Request to acquire session keys. In case of authentication using the EAP-TLS method for local authentication systems, the Key Request will not require an over-the-wire protocol. In case of RADIUS authentication, the authoritative SNMP engine MUST obtain the session keys from the RADIUS server using the RADIUS Key Request Protocol. The authoritative SNMP engine MUST provide the IP address of the non-authoritative SNMP engine and username as part of the Key Request Protocol. The username and IP address of the non-authoritative SNMP engine are used to identify the security contexts, in the future the use of a security context identifier (SCID) is desirable. Narayan et al. Expires Aug 2005 [Page 8] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 The RADIUS server MUST make sure that it is distributing the keys to authoritative SNMP engines authorized to receive those keys by verifying the authoritative SNMP engines with their SNMPv3 engine IDs. This requires the RADIUS server to be administratively configured with the SNMPv3 Engine IDs for all the authoritative SNMP engines that would be requesting keys. The RADIUS key deliverance mechanism described in [KEYREQ] MUST be used to download keying material from Radius servers to authoritative SNMP engines. The RADIUS exchange between the RADIUS server and authoritative SNMP engine is illustrated in the Figure below. ------------ SNMPv3 Message ----------- | | <-------------------------> | | | SNMP | | SNMP | | Engine | | Engine | |(Non-Author)| | (Author) | | | | | ------------ ----------- ^ ^ | | |RADIUS Access_Request/ | |Access_Accept | |PEAP Exchange RADIUS Key_Request| RADIUS Key_Accept{ | { Key (App ID), | Key (Key, IV, Key ID | Calling-Station-ID,| Lifetime, App ID, | User-Name } | KEKID), | | SNMP-Protection-Type, | --------- | SNMP-Group-Name} | | | | -------------> | |<-------------- | RADIUS | | Server | | | --------- *Author => Authoritative Figure 4: EUSM with RADIUS key deliverance The RADIUS Key attribute defined in the [KEYREQ] is used without modification. The authoritative SNMP engine while processing the SNMPv3 packet MUST request the RADIUS server for keys relevant to that particular request, the username and non-authoritative SNMP engine IP address MUST be utilized as security context identifier to determine the SNMPv3 keys relevant to the particular request. Narayan et al. Expires Aug 2005 [Page 9] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 The authoritative SNMP engine MUST construct a Key_Request and MUST include the Key attribute with the App ID field set to the value indicating that SNMPv3 is the application requesting the keys. The authoritative SNMP engine MUST also include the username from the received SNMPv3 packet in the User-Name attribute and the IP Address of the non-authoritative SNMP engine MUST be included in the Calling-Station-ID attribute. The request must also contain a message authentication attribute as defined in [KEYWRAP]. The RADIUS server on processing the Key_Request MUST reference the App ID field in the Key attribute to determine that the request represents an SNMPv3 key request from an SNMPv3 engine. The RADIUS Server MUST proceed to process the User-Name and Calling-Station-ID attributes and MUST obtain the appropriate master session key based on the username and IP Address of the non-authoritative SNMP engine. The RADIUS server MUST then create localized keys using the SNMP engine ID for the authoritative SNMP engine requesting the keys. The Radius Server MUST then construct an Key_Accept and include the Key attribute, the Key attribute will carry the localized key, the Initialization Vector (IV), the Key Lifetime, Key ID, the KEK ID and App ID. The App ID included in the key attribute should be the same as the App ID received in the request. The Key Lifetime represents the duration of time beyond which the authoritative SNMP engine MUST NOT cache the keys retrieved from the RADIUS server. The RADIUS Server MUST also include the SNMP-Protection-Type and SNMP-Group-Name attributes, the SNMP-Protection-Type attribute specifies the SNMP encryption and authentication protocols to be used. The SNMP-Group-Name attribute specifies the VACM group for the user. The SNMPv3 authentication and privacy keys are placed in two separate Key attributes. 3.3. EUSM Processing The EUSM model will use EAP/RADIUS to establish keying material for the user for achieving the security goals defined in [RFC3414]. The EUSM will not modify the SNMPv3 message format defined in [RFC3414], there would only be a small change in the SNMP message processing. In case of packets received with the security model set to EUSM. authoritative SNMP engines will not use the USM Local Configuration Database (LCD); they would use the EUSM cache. The EUSM cache would be populated from the local EAP subsystem in case of authentication via locally defined credentials. The RADIUS request/response mechanism defined in section 3.2 will be used to support RADIUS authentication. Narayan et al. Expires Aug 2005 [Page 10] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 3.4 Modifications to SNMPv3 View Based Access Control (VACM) Processing for RADIUS authentication This specification would require a minor modification to the SNMPv3 VACM processing as defined in [RFC3415]. The current VACM specification has the vacmSecurityToGroupTable, this table maps a combination of securityModel and securityName into a groupName which is used to define an access control policy for a group of principals. The EUSM model will have not a Local Configuration Database and securityNames, hence there would be no entries in the vacmSecurityToGroupTable for the EUSM model. The Key Request mechanism server MUST retrieve the groupName for the user on successful authentication and the authoritative SNMP engine MUST not look up the vacmSecurityToGroupTable to retrieve the groupName for a given security Name. In case of RADIUS authentication, the groupName MUST be returned by the RADIUS server. It is possible for the Key Request mechanism to return a groupName that has not been defined on the authoritative SNMP engine; in such cases, the vacmAccessTable would not have an entry for this group. The authoritative SNMP engine MUST return with a noAccessEntry error for the request. All other aspects of the SNMPv3 VACM would be applicable to this specification. Although the vacmSecurityToGroupTable would be empty for EUSM users, it would not effect other VACM tables that depend on the groupName. The vacmAccessTable has the groupName as of the indexes but the groupName is not dependent on instances in vacmSecurityToGroupTable, quoting the statement in [RFC3415], "Entries in the vacmAccessTable can use an instance value for object vacmGroupName even if no entry in table vacmAccessSecurityToGroupTable has a corresponding value for object vacmGroupName." 3.5. Key Caching The key cache-time for the session keys cached on the authoritative SNMP engines should typically be in the range of 90-180 seconds, this duration represents the typical time window for a network management operation. In case a RADIUS authentication is used, this session key cache-time can be configured on the RADIUS server. The caching interval for the master session key, setup as part of the Key Setup Protocol would in the order of eight hours, this time interval can be configured on all non-authoritative SNMP engines, it can also be configured on the RADIUS server, in case RADIUS authentication is used. Narayan et al. Expires Aug 2005 [Page 11] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 3.5.1. Handling Cache Synchronization Issues This issue is only applicable to RADIUS authentication wherein a single master session key is used to derive session keys for multiple authoritative SNMP engines. The authoritative SNMP engines will cache the localized session keys for the duration of the session key cache time. In case the master session key changes during that time window, it would result in authentication failures for at least one request on all authoritative SNMP engines with valid session keys derived from that master session key. The authentication failure would be the only way to detect such synchronization issues which is not appropriate This memo defines a method to handle such cache synchronization issues, this is done by maintaining a residual timer on the master session key. Every time the RADIUS server responds to authoritative SNMP engine requests for session keys, it MUST save a residual timer on the master session key, the value of the timer will equal the session key cache time. There MUST be only one residual timer for a master session key and it MUST updated every time a localized key is distributed to authoritative SNMP engines. The RADIUS server during security context setup MUST check on any valid residual timer on the previous master session key, it SHOULD proceed with the key exchange but MUST return the residual timer value along with the new master session key. The non-authoritative SNMP engine MUST NOT use the new master session key until after expiry of the residual timer. This will prevent any synchronization issues between the per-engine session keys and master session keys. Implementation Note The residual timer will result in a small black out period for the non-authoritative SNMP engine during which time the non-authoritative SNMP engine MUST not send any SNMP messages to the authoritative SNMP engine. This really is not a significant problem since the only time the residual timer would be used is a case wherein the non-authoritative SNMP engine initiates a new Key Setup for a user within 90-180 secs of terminating an older security context for the same user. In such cases, network management operations performed by that user on the non-authoritative SNMP engine would be delayed for a few seconds. Most of the real time collection in network management applications are not tied to active user sessions and in such cases there will never be a residual timer set, a new security context for the network management system user would be created only on expiration of the older security context and the residual timer would never be set in such cases. Narayan et al. Expires Aug 2005 [Page 12] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 3.6. Security Context Identification for RADIUS authentication All references to "context" in this document refer to a security context which has no relationship to a SNMPv3 context; that is, a security context is independent of, and applies to all relevant SNMPv3 contexts. This memo uses the IP Address of the non-authoritative SNMP Engine and the username to identify the security context in case of RADIUS authentication. Alternate methods of security context identification like the use a Security Context ID are currently not possible, since that would involve changes to the SNMPv3 protocol. This method of security identification SHOULD be replaced with an appropriate Security Context ID in future revisions whenever possible. The use of IP Address of the non-authoritative SNMP engine doesn't result in any loss of functionality and this proposal is fully capable of supporting non-authoritative SNMP engines that use dynamic IP Address assignment. The design considerations for use of IP Address of the non-authoritative SNMP engine in this proposal are. 1) AAA protocol servers like RADIUS and TACACS+ servers use IP Address based association to authenticate requests from clients using the shared secret, the shared secrets are configured per client or one for several clients and the IP Address is used by the AAA server to determine the appropriate shared secret. This would mean that the RADIUS server would already have an IP Address based association with non-authoritative SNMP engines in case RADIUS transport is used. 2) This proposal does not use the IP Address for any long term association, the IP Address of the non-authoritative SNMP engine is used by the AAA server to index the appropriate master secret. The master secret is typically valid for the duration of 8 hours and the association with a particular non-authoritative SNMP engine's IP address will last only for that duration. Moreover in event of a reboot of the non-authoritative SNMP engine and reassignment of it's IP Address, the non-authoritative SNMP engine will create new master secrets for the new sessions initiated after the reboot. This makes this proposal capable of working with dynamic IP addresses. Narayan et al. Expires Aug 2005 [Page 13] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 3.7. RADIUS Server failover Network elements currently allow for definition of multiple RADIUS servers to handle failover. In case, all RADIUS servers are unreachable, the SNMPv3 EUSM allows failover to other authentication systems that use locally defined credentials such as local accounts. This allows SNMPv3 authentication to occur local to the device in case the network interface providing the transport to the AAA server goes down. This behavior is similar to other management interfaces like CLI that would be accessible via a local accounts in case the AAA server is unreachable. 4. Dependencies on work in progress This section specifies the dependency of EUSM on other work in progress within the IETF. 4.1. Extensible Authentication Protocol (EAP) This proposal makes use of the EAP framework which is defined in [EAP]. The optimization for operations on a large number of engines requires definition of the key hierarchy and key naming which is being worked on in [EAP-KEY]. For several types of credentials EAP-TLS [EAP-TLS] can be used, however for token card based credentials and password based credentials other mechanisms must be used. There are several mechanisms supported in deployed environments such as PEAP and EAP-TTLS. There is ongoing work in defining EAP-Methods for this purpose including [PEAP], [TTLS] and [EAP-POTP]. 4.2. RADIUS RADIUS already has specifications for carrying EAP in [RADIUS-EAP]. Existing mechanisms for the transport of key material are supported in RADIUS deployments of 802.11, however it is recommended that stronger protection mechanisms be used such as [KEYWRAP]. The optimization for support of operations on a large number of SNMP engines requires new RADIUS functionality and messages described in [KEYREQ]. 4.3. Protocol for carrying Authentication for Network Access (PANA) There are several layer 3 protocol which have been adapted to carry EAP. There currently are discussions within the PANA working group on extending the PANA solution to work in a multi-hop environment [MULTI-EAP]. This could make a good transport for the Key Setup Protocol for supporting authentication systems other than RADIUS. Narayan et al. Expires Aug 2005 [Page 14] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 5. Security Considerations PEAPv1 is susceptible to a man in the middle attack as described in [CompoundBinding]. The attack uses lack of mutual authentication during security context establishment, since the PEAP client is authenticated via the inner EAP method after the security context has been established. PEAPv2 [PEAP] mitigates the problem by creating a cryptographic binding between the inner and the outer protocols. This memo recommends the use of PEAPv2 to enable the use of the security enhancements. The master session key used to derive localized keys for SNMP engine SHOULD be completely random SHOULD have no co-relation to the user's password, the user's password is never used to seed any key derivation. The process of localization defined in [RFC3414] derives per authoritative SNMP engine session keys from the master session key using a one way hash (MD5), this effectively ensures that the compromise of the per authoritative SNMP engine session key does not compromise the master session key. The session keys are distributed to the authoritative SNMP engines from the AAA server by using RADIUS exchanges as defined in this memo. The security for this exchange would be based on the security provided by the underlying AAA protocol. The RADIUS Key Attribute is protected using the scheme defined in [KEYWRAP]. The AAA servers MUST make sure that the authoritative SNMP engines are authorized to receive the keys they are requesting. The usage of IPSec to protect these RADIUS and TACACS+ exchanges is recommended for better security. 6. IPv6 Considerations Every mention of "IP Address" in this document is intended to provide equivalent support for IPv6 and IPv4. For example, in MIB syntax, the usage would be of InetAddress, not IpAddress. 7. Acknowledgements Thanks (in no particular order) to Don Livinghouse, Eliot Lear, Glen Zorn, Greg Weber, Fabio Maino, Azita Kia, Barry Bruins, Mark Basinski, Jeremy Stieglitz, Arthur Zavalkovsky, Darren Potter for useful feedback. Narayan et al. Expires Aug 2005 [Page 15] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 8. References 8.1 Normative References [RFC3412] Case, J., "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 3412, STD 62, December 2002 [RFC3415] Wijen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 3415, STD 62, December 2002. [RFC3414] Wijen, B. and U. Blumenthal, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, STD 62, December 2002. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [KEYREQ] Zorn, G., Zhou H., Salowey J., "Session Key Transport in RADIUS", http://www.ietf.org /internet-drafts/draft-zorn- radius-keyreq-03.txt [KEYWRAP] Zorn, G., Zhang T., Walker J., Salowey J., "RADIUS Attributes for Key Delivery", http://www.ietf.org /internet-drafts/draft-zorn-radius-keywrap-03.txt [PEAP] Palekar, A., et al., "Protected EAP Protocol (PEAP)", draft -josefsson-pppext-eap-tls-eap-10.txt, Internet draft (work in progress), May 2004. [CompoundBinding] Puthenkulam, J., Lortz, V., Palekar, A. and D. Simon, "The Compound Authentication Binding Problem", draft-puthenkulam -eap-binding-04.txt, Internet Draft (work in progress), October 2003. Narayan et al. Expires Aug 2005 [Page 16] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 [PANA] D. Fosberg et al., "Protocol for Carrying Authentication for Network Access", draft-ietf-pana-pana-04.txt [EAP-KEY] Aboba et. Al. "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-04.txt, Internet Draft (work in progress). [TTLS] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol Version 1 (EAP-TTLSv1)", draft-funk-eap-ttls-v1-00.txt, Internet Draft (work in progress). [MULTI-EAP] Giraetta, et. Al. "Usage Scenarios and Requirements for Multi-hop EAP Lower Layer", draft-ohba-multihop-eap-00, Internet Draft (work in progress). 9. Authors' Addresses Kaushik Narayan Cisco Systems, Inc. 125 Rio Robbles San Jose, CA. 95134 USA Phone: +1-408-526-8168 EMail: kaushik@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 East Tasman Drive San Jose, CA. 95134-1706 USA Phone: +1-408-526-5260 EMail: kzm@cisco.com Joseph Salowey Cisco Systems 2901 Third Avenue SEA1/6/ Seattle, WA 98121 USA Phone: +1-206-256-3380 EMail: jsalowey@cisco.com Narayan et al. Expires Aug 2005 [Page 17] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 10. Intellectual Property Considerations 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. Full Copyright Notice 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayan et al. Expires Aug 2005 [Page 18] INTERNET-DRAFT External USM for SNMPv3 Feb 2005