ISMS Working Group Miao Fuyou Internet Draft Huawei Technologies Expires: April 2006 October 17, 2005 SNMP Agent Discovery under SSH Transport draft-miao-isms-sshsm-discovery-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 17, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document discusses several possible mechanisms of SNMP engine discovery when SSH is deployed as transport mapping for SNMP. The document proposes a discovery mechanism using UDP transport and User Based Security Model(USM) with a feature of SSH host key distribution. Miao Expires April 17, 2006 [Page 1] Internet-Draft ISMS Discovery October 2005 The mechanism tries to reduce discovery cost and in the same time improve SSH host key distribution efficiency. The draft is in "discussion" nature. Maybe there is text that is implementation-related, but the author believes it was not specific to a certain implementation. Conventions used in this document 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 RFC-2119. Table of Contents 1. Introduction................................................2 2. The problems with running discovery over SSH.................3 2.1. Multiple processes......................................3 2.2. Cost of cryptographic processing........................4 2.3. snmpEngineID...........................................4 3. UDP/USM SNMP Discovery.......................................5 3.1. snmpEngineID...........................................5 3.2. Can we believe the discovery?...........................5 3.3. Discovering more information............................5 3.4. Re-association and re-discovery.........................6 4. MIB module definition........................................6 5. Security Considerations.....................................12 6. Acknowledgments............................................12 7. References.................................................12 7.1. Normative References...................................12 7.2. Informative References.................................13 Author's Addresses............................................14 Intellectual Property Statement................................14 Disclaimer of Validity........................................14 Copyright Statement...........................................15 Acknowledgment................................................15 1. Introduction SNMP agent discovery is a common feature for network management system. A manager application (command generator and notification receiver) uses this feature to discover agent at specific host. Miao Expires April 17, 2006 [Page 2] Internet-Draft ISMS Discovery October 2005 Discovery finds out whether a device is "manageable" through the specific transport address. In the same time it retrieves some general information of the device and agent. Usually the general information is defined in System Group of SNMP MIB [RFC3418] and snmpEngine Group of SNMP Framework MIB [RFC3411]. The current direction of ISMS working group indicates SSH transport mapping will be applied to secure SNMPv3 transaction. In this transport mapping model, there are some problems on agent discovery to be considered. The document addresses the problems and tries to suggest possible solutions for the problems. 2. The problems with running discovery over SSH In section 5.2 of [SSHSNMP] a mechanism is mentioned: "Auto-discovery of SNMP devices is an important feature of many NMS platforms. Should we simply use a noAuthNoPriv request, and recommend an associated access control configuration that only makes accessible relatively benign data such as sysOID, sysDescription, and snmpEngineID?" There are several problems with this mechanism. They will be addressed in the following subsections. 2.1. Multiple processes When a SNMP manager application runs a discovery over SSH, typically at least two processes should be started by operation system of discovered device to serve discovery. A SSH server keeps listening on specified port. When a transport connection request comes to port, it forks the first process to process the SSH connect. After the user is authenticated and channel setup is request by the client, the forked process must start another SNMP process as SSH subsystem to process SNMP request. The discovery is very expensive because of the nature of discovery. Usually an administrator configures a block of address for a manager application, then the manager application invokes discovery function to "discovery" the devices by trying each address in the block. There may be many devices to be discovered. So after the manager application discovers a device it simply disconnects the transport connection to the device, otherwise there will be too many transport connection to be kept active simultaneously. So, a piece of relative cheap information is retrieved in a relative expensive way. In the same time starting more processes means more time and discovery is Miao Expires April 17, 2006 [Page 3] Internet-Draft ISMS Discovery October 2005 time-sensitive in most situations because relatively high frequency of discovery to keep the database consistent with running network. 2.2. Cost of cryptographic processing If noAuthNoPriv is used in the mechanism as an alternative, it is assumed that the cost of cryptographic processing is zero. Maybe this is not true. The cost of SSH cryptographic processing is comprised of the following part: 1, User authentication - the cost is reduced to zero by noAuthNoPriv 2, Encryption - the cost is reduced to zero by noAuthNoPriv 3, Deffie-Hellman Exchange - maybe the expensive processing can be avoided. 4, Server authentication - it is not explicitly mentioned in [SSHARCH] whether server authentication is required. But, it is clear "none" algorithm is not allocated a number in section 4.11.3 of [SSHNUM]. Can the expensive asymmetric cryptographic processing can be avoided? In the same time, the availability of host keys of devices to be discovered is not something trivial. 2.3. snmpEngineID In section 5 [RFC3411] several ways to generate a static snmpEngineID is recommended. In the same time it says (page 42): "In cases where there are multiple engines on the same system, the use of this algorithm is NOT appropriate, as it would result in all of those engines ending up with the same ID value." SSH transport is different from TCP transport on process creation. TCP process is FORKED by TCP server to process incoming connection request, so snmpEngineID may be kept consistent for all forked processes. In SSH transport SNMP is started as subsystem of SSH, subsystem for different SNMP connection request is not as tightly coupled as TCP forked processes. Actually they are very independent to each other. For such case, snmpEngineID is very possible be allocated dynamically. When SSH is applied as a transporting model for SNMP, it is very difficult to predict whether there is only one engine or multiple engines on a device. When a SSH server accepts one SSH connection and Miao Expires April 17, 2006 [Page 4] Internet-Draft ISMS Discovery October 2005 creates one SNMP subsystem for it, perhaps there is a SNMP engine initialized and one snmpEngineID is allocated. When there are several connections, whether in a parallel or sequential manner, the snmpEngineID may be dynamically generated so that each value is unique. This means snmpEngineIDs are different for SNMP discovery connection and following management connection if the two connections are not same. 3. UDP/USM SNMP Discovery In section 5.2 of [SSHSNMP], another possible mechanism is discussed: "Alternatively, can we let USM perform discovery so we don't have to attempt to establish an SSH connection first? USM is the mandatory- to-implement security model, so this could make sense." Author's understanding is the mechanism implicitly suggests an UDP transport mapping for SNMP, in the same time USM with noAuthNoPriv is applied to discover SNMP agent. Because both UDP transport and USM are mandatory-to-implement, it is possible to use UDP/USM for agent discovery. One SNMP UDP server receives responses to discovery requests from all possible manager application. So it avoids the cost of multiple processes only for one discovery request. In the same time USM with noAuthNoPriv eliminates all costs of cryptographic processing. 3.1. snmpEngineID UDP snmpEngineID may be constant because there is only one UDP server listening on port 161[RFC3417]. But the following snmpEngineID in SSH transport mapping is probably different from this one because they are different server for UDP and SSH transport on agent, so does snmpEngineID. If it is true it is meaningless to discover snmpEngine group information, but this does not applies to System Group. 3.2. Can we believe the discovery? If an agent is discovered by UDP/USM, it does not mean one can connect SNMP with SSH transport to the agent. It only means there is a UDP SNMP server available on the device and nothing more! 3.3. Discovering more information To solve the problem in section 3.2 UDP/USM can discover more information than System Group alone. The information includes: Miao Expires April 17, 2006 [Page 5] Internet-Draft ISMS Discovery October 2005 1. Flag indicates whether SSH transport available 2. Transport address of the SNMP SSH transport 3. The host key of SSH server 4. Other parameters relevant to host key, such as algorithm identifier The information then is used to initialize a SNMP SSH transport. 3.4. Re-association and re-discovery After UDP/USM discovery a manager application may start a SNMP request in SSH transport. Then SNMP can re-discover the System Group information along with discovering snmpEngine Group information, which is trustable now. Manager application can also re-associate the System Group with snmpEngine Group. 4. MIB module definition SSHSM-DISCOVERY-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB; sshsmdiscoveryMIB MODULE-IDENTITY LAST-UPDATED "200510100000Z" ORGANIZATION "ISMS Working Group" CONTACT-INFO "WG-EMail: isms@lists.ietf.org Miao Expires April 17, 2006 [Page 6] Internet-Draft ISMS Discovery October 2005 Subscribe: isms-request@lists.ietf.org Chair: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany +49 6221 90511-15 quittek@netlab.nec.de Co-editors: Miao Fuyou Huawei Technologies No.3, Xinxi Rd Shangdi Information Industry Base Haidian District, Beijing P. R. China +86 10 8288 2502 miaofy@huawei.com " Miao Expires April 17, 2006 [Page 7] Internet-Draft ISMS Discovery October 2005 DESCRIPTION "The Agent Discovery MIB of Secure Shell Security Model Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices. REVISION "200509020000Z" -- 10 October, 2005 DESCRIPTION "The initial version, published in RFC XXXX." ::= { mib-2 xxxx } sshsmdiscoveryObjects OBJECT IDENTIFIER ::= { sshsmdiscoveryMIB 0 } SshsmSupportFlag ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The flag is defined to indicate whether SSH security model is available at the agent. The value is one of: UNAVAILABLE - SSH transport is available for successive communication Available - SSH transport is available for successive communication " SYNTAX INTERGER { UNAVAILABLE(0), AVAILABLE(1) } SshsmHostKeyAlgorithm ::= TEXTUAL-CONVENTION STATUS current Miao Expires April 17, 2006 [Page 8] Internet-Draft ISMS Discovery October 2005 DESCRIPTION "It defines the public key algorithm for host authentication by SSH client. Following strings is defined in [SSHNUM]: ssh-dss ssh-rsa spki-sign-rsa spki-sign-dss pgp-sign-rsa pgp-sign-dss " SYNTAX OCTECT STRING sshsmSupportFlag OBJECT-TYPE SYNTAX SshsmSupportFlag MAX-ACCESS read-only STATUS current DESCRIPTION "The flag indicates availability of SSH transport for successive SNMP communication." ::= { sshsmdiscoveryObjects 0 } sshsmTransportAddress OBJECT-TYPE SYNTAX INTEGER (1..4294967296) MAX-ACCESS read-only STATUS current Miao Expires April 17, 2006 [Page 9] Internet-Draft ISMS Discovery October 2005 DESCRIPTION "The value indicates to SSH client which transport address is available for SSH connection which transports SNMP when non-standard SSHSH port is not used" ::= { sshsmdiscoveryObject 1 } sshsmHostKeyTable OBJECT-TYPE SYNTAX SEQUENCE OF SshsmHostKeyEntry MAX-ACCESS not-accessible STATUS Current DESCRIPTION "This table supports agent discovery when SSH security model is applied to SNMP. The table provides information to management application through UDP/USM agent discovery functions. The information is organized in a table because there may be multiple host keys for a device" ::= { sshsmdiscoveryObject 2 } sshsmHostKeyEntry SYNTAX SshsmHostKeyEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in sshsmHostKeyTable, each entry represents a host key and information relevant to the host key." INDEX { sshsmHostKeyFingerPrint } ::= { sshsmHostKeyTable 1 } Miao Expires April 17, 2006 [Page 10] Internet-Draft ISMS Discovery October 2005 sshsmHostKeyEntry ::= SEQUENCE { sshsmHostKeyFingerPrint OCTECT STRING (SIZE (16)) sshsmHostKey OCTECT STRING, sshsmHostKeyAlgorithm SshsmHostKeyAlgorithm, } sshsmHostKeyFingerprint OBJECT-TYPE SYNTAX OCTECT STRING (SIZE (16)) MAX-ACCESS read-only STATUS current DESCRIPTION "16 bytes Output of hash function with host key as input. The hash function is specified as SHA-1" sshsmHostKey OBJECT-TYPE SYNTAX OCTECT STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The host key. The format of the key is defined in [SSHTRANS]" sshsmHostKeyAlgorithm OBJECT-TYPE Miao Expires April 17, 2006 [Page 11] Internet-Draft ISMS Discovery October 2005 SYNTAX SshsmHostKeyAlgorithm MAX-ACCESS read-only STATUS current DESCRIPTION "The public key algorithm relevant to the host key. When there are multiple host key available, the algorithm can be used as a distinguisher to choose proper host key for server authentication" END 5. Security Considerations With noAuthNoPriv enabled UDP/USM discovery model provides no security to data "discovered". The data are subject to falsification and eavesdropping by man in the middle. An attacker replaces host key on the wire with a public key which he knows the private key associating with. Then, a falsified host key and spoofed IP address is utilized to impersonate a device and gets itself authenticated by SSH client. Adding integrity check makes UDP/USM discovery sophisticated and cost, in the same time it eliminates the margin of the discovery model and the SSHSM. Maybe certificate and CA can be introduced into discovery to validate the public key. Another consideration is confidentiality of discovered data. Actually the data is publicly available because of noAuthNoPriv nature, so it is acceptable. 6. Acknowledgments The author would like to appreciate David B. Harrington and Spencer Dawkins. Their discussion and feedback to the proposal is valuable and important for improvement of the quality of the document. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Miao Expires April 17, 2006 [Page 12] Internet-Draft ISMS Discovery October 2005 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [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 SNMP", STD 62, RFC 3412, 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. [RFC3417] Presuhn (Editor), R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, [RFC3418] R. Presuhn, J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD62, RFC 3418 [SSHSNMP] D. Harrington, J. Schoenwaelder and J. Salowey, "Secure Shell Security Model for SNMP", Internet Draft, September 16, 2005, draft-harrington-isms-SecShell-01.txt(work in progress) [SSHARCH] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", draft-ietf-secsh-architecture-22 (work in progress), March 2005. [SSHNUM] S. Lehtinen, C. Lonvick, "SSH Protocol Assigned Numbers", Internet Draft, March 14, 2005, draft-ietf-secsh- assignednumbers-12.txt 7.2. Informative References [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport Mapping", RFC 3430, December 2002. [SSHTrans] Lonvick, C., "SSH Transport Layer Protocol", draft-ietf- secsh-transport-24 (work in progress), March 2005. Miao Expires April 17, 2006 [Page 13] Internet-Draft ISMS Discovery October 2005 [SSHAuth] Lonvick, C. and T. Ylonen, "SSH Authentication Protocol", draft-ietf-secsh-userauth-27 (work in progress), March 2005. [SSHConnect] Lonvick, C. and T. Ylonen, "SSH Connection Protocol", draft-ietf-secsh-connect-25 (work in progress), March 2005. Author's Addresses Miao Fuyou Huawei Technologies No. 3, Xinxi Road, Shangdi Information Industry Base, Haidian, Beijing, P. R. China Phone: 86 10 8288 2502 Email: miaofy@huawei.com 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 Miao Expires April 17, 2006 [Page 14] Internet-Draft ISMS Discovery October 2005 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. Miao Expires April 17, 2006 [Page 15]