Internet DRAFT - draft-miao-isms-sshsm-discovery
draft-miao-isms-sshsm-discovery
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]
