[Isms] A session-less fix to SNMP security issues?
Thierry Moreau <thierry.moreau@connotech.com> Wed, 23 March 2005 14:27 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18606; Wed, 23 Mar 2005 09:27:56 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6vR-0007Yh-Nb; Wed, 23 Mar 2005 09:33:38 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6mi-0004bW-Cl; Wed, 23 Mar 2005 09:24:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6mh-0004bR-Iq for isms@megatron.ietf.org; Wed, 23 Mar 2005 09:24:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18255 for <isms@ietf.org>; Wed, 23 Mar 2005 09:24:33 -0500 (EST)
Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251] helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6sA-0007TC-GF for isms@ietf.org; Wed, 23 Mar 2005 09:30:15 -0500
Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v3.32) ID MO0068D0; 23 Mar 05 09:33:18 -0500
Received: from spooler by Lamicro.com (Mercury/32 v3.32); 23 Mar 05 09:33:08 -0500
Received: from connotech.com (209.71.204.110) by SMTP.Lamicro.com (Mercury/32 v3.32) with ESMTP ID MG0068CE; 23 Mar 05 09:32:51 -0500
Message-ID: <4241825E.4050709@connotech.com>
Date: Wed, 23 Mar 2005 09:51:10 -0500
From: Thierry Moreau <thierry.moreau@connotech.com>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: isms@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d
Content-Transfer-Encoding: 7bit
Subject: [Isms] A session-less fix to SNMP security issues?
X-BeenThere: isms@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/isms>
List-Post: <mailto:isms@lists.ietf.org>
List-Help: <mailto:isms-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@lists.ietf.org?subject=subscribe>
Sender: isms-bounces@ietf.org
Errors-To: isms-bounces@ietf.org
X-Spam-Score: 1.3 (+)
X-Scan-Signature: 6a817af60e4281a101681ecb646dffff
Content-Transfer-Encoding: 7bit
Subject: A session-less fix to SNMP security issues? Dear isms wg members, The current isms activity is an architectural review. This message is intended as a contribution towards the isms advancement, however not based on either architectural proposals currently under review. I am taking the isms pursuit from a security perspective. I recently became aware and interested in the proposal comparison document ([COMPAR]) during a search of security scheme documents addressing the provisioning of pre-shared secrets. Table of contents 1. Situation analysis 2. Proposal 2.1. Desirable Properties 2.2. Proposal Strategy 3. Solution 3.1. Solution Context 3.2. A Sample Protocol Suite 3.2.1. SSH 3.2.2. RADIUS 3.2.3. SNMPv3 3.3. SAKEM Use Pattern 3.4. Elements of Operations Applicable to SNMPv3 Agents 3.4.1. Initial Out-of-box Procedure 3.4.2. SNMPv3 Installation-Related Operation 3.4.3. The SNMPv3 Agent User Management Operations 3.5. Server-Side Arrangements 4. Conclusion 5. Intellectual Property Notice 6. References 1. Situation analysis The following situation analysis uses some external sources of understanding: o the isms meeting audio recording ([AUDIO]) -- somehow usable despite low recording level and missing recording from some seats in the meeting room, o the reference [MSG445] o the author's organization promoted solution element, SAKEM (Secret Authentication Key Establishment Method) ([SAKEM_WP] and [SAKEM_IND]), o an inference from a mailing list message ([MSG319]) () that a workable SNMP agent configuration strategy can rest on a single "initial user" account, even with the initial-no-access-configuration option (defined in [RFC3415]). The main situation analysis elements are: o The major discomfort with the SNMPv3 security scheme is that "Key management with manual keying is extremely difficult in any system." From [COMPAR]. o There are very few proposals that directly address the above difficulty. From [SAKEM_WP]. o The SNMPv3 security scheme is application-level security, implementing datagram security (connectionless security protocol) with symmetric-key cryptography. o The SNMPv3 key management is a simple symmetric key derivation scheme, i.e. key derived from user passwords. Accordingly, the derived symmetric keys need to be (securely) configured in each SNMP agent, but the user passwords need not be stored on the SNMP manager side (it is a local implementation decision to store a user passwords on the SNMP manager side). o The current SNMPv3 security solution comprises no notion of a session to which a security association can be plugged. The three isms proposals appear to change this architectural trait in order to benefit from various security protocols which derive session master keys from long-term authentication secrets. From [COMPAR]. o According to [MSG319], the out-of-box security configuration for SNMPv3 would be a single pre-shared secret key derived from an "initial user" password. o Operational stability is best ensured if the "initial user" password is stored or backed up in a secure server for the administrative domain (hereafter "USM secure store"). o VACM is not broken. From [AUDIO], circa 58 minutes from start of recording. (Without further supporting data, not even having understood VACM, I assume that VACM need not be fixed.) 2. Proposal 2.1. Desirable Properties The desirable properties of a solution path, mainly motivated by the network operator's operational needs: o As little change as possible to the SNMPv3 implementations. From [AUDIO]. o The typical out-of-box procedure for a new network element comprises the installation of a number of security protocols, each with its manual cryptographic key configuration requirement (pre-shared secret passwords are analogue to cryptographic keys in this context): . SSH (host public key to be certified, see[SSH_ARCH]) . Radius NAS-to-server (symmetric secret key for mutual authentication, see [RFC2865]) . VPN enrolment (...) . SNMPv3 (pre-shared secret key derived from the "initial user" password) From [MSG445], [MSG319], and [AUDIO]. See also [OPSEC], section 2.3.2. o Perhaps a fallback mode of operation (or backwards compatibility) to the original SNMPv3 USM is an inescapable requirement. From [MSG445]. A secondary goal is ignored herein to keep focused on the main issues: o In SNMPv3, authentication and privacy keys are derived with a single mechanism. This looks like an original SNMPv3 design flaw (i.e. it would have been easy to specify differentiated derivations for authentication and privacy). In any case, a fix would be to use the recently standardized CCM mode of operation [CCM]. From [RFC3414] section 11.2. 2.2. Proposal Strategy The main strategy for this proposal is 1. stick to connectionless security as specified in SNMPv3, 2. specify additional symmetric key management operations, 3. allow protocol elements to remain unspecified at this stage (because symmetric-key cryptography is simpler, e.g. fewer rounds of session key derivation protocol, than public-key cryptography, at the expense of more limited set of threat prevention, e.g. lack of perfect forward secrecy), 4. address the manual pre-shared secret distribution problem in a systematic way (SAKEM), and 5. attempt to apply this systematic approach to other security protocols configured in a typical out-of-box installation (a network device authentication consolidation approach, not unlike the single-sign-on paradigm for user authentication). Stepping back in the isms activities, this proposal re- focuses on the SNMPv3 operational hindrance and shows (?) that the three isms proposals carry a major architectural change (moving away from the SNMPv3 connectionless protocol and simple symmetric-key security model) that is not clearly related to the major operational issue. 3. Solution 3.1. Solution Context Within an administrative domain, the solution assumes three execution environments: 1) field network devices, which may run SNMP agents, 2) secure servers premises, and 3) administrative systems, which may run SNMP manager applications. The secure server premises is the proper place for secure databases (e.g. Radius server databases) and security certificate issuing systems/applications in support of public key cryptography (e.g. to certify a network device public key for the SSH protocol). Note that public key cryptography is introduced in the present proposal because protocols alongside SNMPv3 use it, and the consolidation approach supports it (in some configurations at least). 3.2. A Sample Protocol Suite Since we are contemplating a consolidated solution to the device authentication needs of a number of security protocols, we may list some candidate protocols with some explanation about how the individual solutions can converge towards a common method for the very initial authentication of keys and secrets. 3.2.1. SSH In SSH, the network device needs to set up a private/public key pair for routine device authentication afterwards. Within the secure server premises, SSH deployment needs either a trusted database of public keys or a security certificate issuance function (see section 4.1 of [SSH_ARCH]). In either case, a proof-of-possession should be delivered to the secure server premises, providing confidence that the network device is able to sign some authenticated shared secret with the private counterpart of the alleged public key. Thus, the SAKEM procedure and technology may be used to authenticate a shared secret between a new SSH host protocol entity in a network device and a central organization's secure server premises. The SSH host implementation need to digitally sign this shared secret (specifically, a conventional string containing the shared secret or a string conventionally derived from the shared secret, as a necessary countermeasure against chosen ciphertext attacks, as is well understood among public key cryptography experts). The SSH host implementation already performs digital signature operations. The additional requirement shouldn't be overly difficult. 3.2.2. RADIUS If RADIUS is used to control access to a network device e.g. for command line system management interface, the network device acts as a NAS (Network Access Server) in the RADIUS terminology. The RADIUS protocol links the NAS to the RADIUS server (in the secure server premises). Upon device installation, the NAS and RADIUS server must be provisioned with a pre-shared secret. This is a straightforward application for the SAKEM procedure and technology. 3.2.3. SNMPv3 In the secure server premises, the SNMPv3 "USM secure store" (where SNMPv3 passwords are stored for an administrative domain) holds the "initial user" password from which the initial SNMPv3 pre-shared secret must be derived for any new network device. In this case, the SAKEM procedure and technology can pre-share an unpredictable binary secret key, which is neither a password nor a value derived from a password. Some key management provisions must be made to turn this network device pre-shared secret into a secret derived (localized) from a password for every SNPMv3 agent implementations on this device. First, there is a many-to-one relationship between SNMPv3 agents (identified by snmpEngineID) and network devices. This needs to be reflected in the procedural aspect of SAKEM, i.e. the identity that is verified in this context is the list of snmpEngineID-s installed (or to be installed) on this device. The key management provision addressing this many-to-one relationship is a secret key derivation (details to be specified) based on the snmpEngineID value. Then, the derived secret key for an SNMPv3 engine can be used to protect (e.g. for confidentiality and data authentication using the CCM mode of operation [CCM]) a message from the "USM secure store" to the SNMPv3 engine with the data triplet "initial user" name, privacy key, authentication key. We later refer to such message as the *protected message*. 3.3. SAKEM Use Pattern Although the three protocols SSH / RADIUS / SNMPv3 are introduced as a representative set of protocols for out-of-box installation, we also get representatives of three different SAKEM integration patterns: Protocol Authenticated pre-shared secret use pattern ======== =========================================== RADIUS Direct use of authenticated pre-shared secret SSH Authenticated pre-shared secret used in a proof- of-possession for public key certificate issuance SNMPv3 Authenticated pre-shared secret protecting a password (or value derived from password) configuration message 3.4. Elements of Operations Applicable to SNMPv3 Agents 3.4.1. Initial Out-of-box Procedure The SNMPv3 agent must securely store (same kind of secure storage applicable to shared secrets) an authenticated pre-shared secret received from the SAKEM client-side software. 3.4.2. SNMPv3 Installation-Related Operation The SNMPv3 agent must receive the *protected message* holding the "initial user" account data (user name, authentication key, privacy key). The triggering of this message transmission from the "USM secure store" to the local SNMPv3 agent is left unspecified at this point. Once so installed, the SNMPv3 agent is configured with a fallback "initial user" account. 3.4.3. The SNMPv3 Agent User Management Operations Synchronization between SNMP user management and authentication protocols (e.g. RADIUS) is a goal of the isms working group charter. The present proposal implements this with 1) a small change to SNMPv3 agent implementation, and 2) use of some RADIUS protocol implementation-specific attributes for the purpose of SNMPv3 user management integration (IANA considerations set aside). The main change in the SNMPv3 agent implementation is the support for the receipt of a *protected message* holding user account data for a given user (user name, authentication key, privacy key). Implementation-wise, this looks like the re-use of the "initial user" setup as described above. Security-wise, there a important difference: the SNMPv3 agent implementation must be protected from replay attacks (e.g. local mitigation by implementation integration of the SNMPv3 security code and the RADIUS NAS code). The RADIUS protocol support of SNMPv3 user management is an implementation-specific attribute in the Access-Request packet to indicate to the RADIUS server that some "Authenticate Only" service type request is a request to a) authenticate the end- user, b) validate that the end-user is allowed SNMPv3 agent registration, and c) convey the above *protected message* to the NAS in the network device, in an implementation-specific attribute to the RADIUS Access-Accept packet. The daily network management operations work as follows: o Upon hiring a new employee in the network management function, a user name and password is created in the "USM secure store." o The first time an employee wishes to perform an SNMP operation targeted at an SNMP agent, he/she must first authenticate with the RADIUS NAS server residing on the same network device, requesting the implementation- specific service arrangement described above. This is when the "USM secure store" application prepares the *protected message* for users other than the initial one. o When the employee leaves or when a password change is required, every SNMP agents which was within his/her reach must be notified (i.e. the employee user name must be removed or disabled). Most SNMP management systems should be flexible enough to have this task automated. 3.5. Server-Side Arrangements The server-side arrangement details are numerous but "straightforward" (for the present author to formulate, and maybe for some readers). A SAKEM implementation document uses the term "Functional Area" for the required secure application in the secure server premises ("FA systems"). The SAKEM FA system required for the current proposal integrates the support of SSH out-of-box deployment, RADIUS NAS out-of-box deployment, and the proposed RADIUS-SNMPv3 integration. 4. Conclusion The above proposal is a two-sided solution to the SNMPv3 operational difficulties: A) the "initial user" manual configuration is recognized as a familiar difficulty with other protocols in an out-of-box procedures for new network devices (we propose the IP- restricted SAKEM procedure and technology), and B) the SNMPv3 user management function is facilitated with a simple integration scheme that do not change the original SNMPv3 security model. Obviously, the present proposal reliance on RADIUS is mostly for convenience of feasability demonstration. This proposal author does not claim that a session-oriented security protocol is inappropriate for SNMPv3 (e.g. we do nothing about the 150 seconds anti-replay protection timeout). However, we suggest that SNMPv3 difficulties can also be addressed differently. 5. Intellectual Property Notice The SAKEM procedure and technology is covered by the United States patent number 6,061,791. Generally speaking, if proprietary elements of the SAKEM procedure and technology becomes part of a publicly available standard established by an open standardization body, CONNOTECH is willing to negotiate licenses for these intellectual property rights on reasonable and nondiscriminatory terms and conditions. Please contact CONNOTECH Experts-conseils inc. for further details. 6. References [COMPAR] R. Presuhn, Ed., U. Blumenthal, L. Dondeti, E. Rescorla, "Comparison of Proposals for Integrated Security Models for SNMP (Simple Network Management Protocol)", Internet-Draft, draft-ietf-isms-proposal-comparison-00.txt, February 13, 2005 [AUDIO] audio recording file ietf62-ch5-mon-eve.mp3 retrieved from the IETF web site [MSG445] a mailing list message from Wes Hardaker about "design decisions in SBSM", http://www1.ietf.org/mail-archive/web/isms/current/msg00445. html [SAKEM_WP] http://www.connotech.com/sakem_white_paper_06.htm [SAKEM_IND] http://www.connotech.com/sakem_index.htm [MSG319] http://www1.ietf.org/mail-archive/web/isms/current/msg00379. html [RFC3415] B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC3415, December 2002 [SSH_ARCH] draft-ietf-secsh-architecture-21.txt [RFC2865] C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote Authentication Dial In User Service (RADIUS).", RFC-2865, June 2000 [OPSEC] draft-ietf-opsec-current-practices-00.txt [CCM] Morris Dworkin, "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", NIST Special Publication 800-38C, May 2004 [RFC3414] U. Blumenthal, B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC-3414, December 2002 -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms
- [Isms] A session-less fix to SNMP security issues? Thierry Moreau
- Re: [Isms] A session-less fix to SNMP security is… Robert Story
- RE: [Isms] A session-less fix to SNMP security is… Blumenthal, Uri
- RE: [Isms] A session-less fix to SNMP security is… David B Harrington
- Re: [Isms] A session-less fix to SNMP security is… Wes Hardaker
- Re: [Isms] A session-less fix to SNMP security is… Thierry Moreau
- RE: [Isms] A session-less fix to SNMP security is… Nelson, David