From isms-bounces@ietf.org Thu May 1 17:18:18 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6EB43A6AEB; Thu, 1 May 2008 17:18:18 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAD228C164 for ; Thu, 1 May 2008 17:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eX0YKM25K2YF for ; Thu, 1 May 2008 17:18:13 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 2C2293A6D34 for ; Thu, 1 May 2008 17:18:13 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 6B26A39A26C for ; Thu, 1 May 2008 17:16:34 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:subject:organization:date:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=K/sr2aMuG1Ukc7AJaJVbV0tGBGg=; b=WWSGllnDHx2gZ2ooMv1XKLvq2IxLvbRHTftloRbBdzFJMswXQ/xSgeMQ1OT53W6/xLIqA/IwHXVBvzBPykPRC6Fz7ieRU12a1mI1eGDi6+3uJHh2BrOopP27sym5PQY+iPSlWaqR6RgBwrn9ngZBePlTlw6FNSsomprTOx3aq2k= Received: by wes.hardakers.net (Postfix, from userid 274) id DE1D039A26D; Thu, 1 May 2008 17:16:33 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Thu, 01 May 2008 17:16:32 -0700 Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org The following is based on the message I sent out in January in 2007 and then later modified in July of 2007. I've now modified it for a third time to fix some errors I found in it and have lengthened some of the sections to talk more about the issues recently discussed here. I didn't know which email was the best to reply to in the current thread, so I gave up and started a new Subject: :-) (previous posting for anyone that wants to compare changes: http://www.ietf.org/mail-archive/web/isms/current/msg02097.html ) This is *long* but hopefully clear. Please read the entire document before responding to bits in the top; it's not a complete set of thouhts without reading the whole thing (sorry). Hopefully it'll be helpful, however. The VACM discussion in section 3 is entirely new. This is all about sending notifications over SNMP/SSH and the usable authentication mechanisms. It's been edited heavily for improved readability and usability. I can probably be coerced into further formalizing the writing for suitable inclusion into the resulting draft assuming the description below is sufficient for forward progress. Note: I have not trolled through all the docs to make sure everything below is 100% accurate and secure. Think of it as a white-board diagram not an end-specification. 1.0 Background 1.1 Terminology Politically correct SNMP terms: CG = command generator CR = command responder NG = notification generator NR = notification responder SSH terms: LoF = Leap of Faith 1.2 Basic Notification Configuration The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB already allow for configuration of notification receivers destinations to which notifications should be sent. The following examples depict possible configuration of this setup using a USM configuration. snmpTargetParamsTable row: snmpTargetParamsName toNR (administrative string) snmpTargetParamsMPModel 3 (SNMPv3) * snmpTargetParamsSecurityModel 3 (USM) * snmpTargetParamsSecurityName usmUser (The USM user name) snmpTargetParamsSecurityLevel 3 (auth|encr) snmpTargetParamsStorageType 3 (nonVolatile) snmpTargetParamsRowStatus 4 (createAndGo) snmpTargetAddrTable row: snmpTargetAddrName toNRAddr (arbitrary string) snmpTargetAddrTDomain snmpUDPDomain snmpTargetAddrTAddress 0x0A00000100A2 (NR address, port) snmpTargetAddrTimeout 1500 (in .01 sec) snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toNRTag snmpTargetAddrParams toNR (must match prev table) snmpTargetAddrStorageType 3 (nonVolatile) snmpTargetAddrColumnStatus 4 (createAndGo) snmpNotifyTable row: snmpNotifyName NRNotif (arbitrary string) snmpNotifyTag toNRTag (matches tag list above) snmpNotifyType 2 (inform) snmpNotifyStorageType 3 (nonVolatile) snmpNotifyColumnStatus 4 (createAndGo) The above will configure an agent to act as a NG and send informs to the NR at 10.0.0.1 port 162 using the SNMPv3/USM user "usmUser". The configuration for the "usmUser" settings in the SNMP-USER-BASED-SM-MIB and SNMP-VIEW-BASED-ACM-MIB objects are not shown here for brevity. The columns marked with a "*" are the items that are USM specific. We'll refer back in later sections about how this changes when using SNMP/SSH. An important point: the agent already needs configuration to be able to send notifications regardless if ssh is the transport or it's not. 1.3 Basic VACM Configuration The workings of the VACM is fortunately more widely understood, so I won't break it out in detail here. The important thing to do know from a notification point of view is that the only thing the VACM needs to check is "am I allowed to send this notification". It does that through the use of a securityName (and model and level) given to it by the NG. It doesn't care where that securityName came from nor how it was technically authenticated. It completely trusts the caller to not have lied to it and it's the callers responsibility to have checked the authenticity of the values. Here's the important key point: the VACM does not verify that the other end is actually who they say they are. It's not the VACMs job. We'll need this later. 2.0 Notification Generation by a Notification Responder Notification Generators (NGs) need to send notifications to management stations acting as a Notification Responders (NRs). There are three possibilities for how this might be done depending on the current SNMP/SSH sessions available for use and the directionality associated with them. Section 2.1 describes 2 authentication mechanism procedures for how a Notification Generator would open and authenticate a SNMP/SSH connection to a Notification Receiver. Section 2.2 describes how a Notification Receiver can open a connection (or more than one) to the Notification Generator and configure it to send notifications over an existing connection. 2.1 A Notification Generator Opening a SNMP/SSH Connection to the Notification Responder There are a number of interesting issues with how to do the case where a Notification Generator needs to open a connection to the Notification Receiver. The hardest issue with this has been authentication mechanism to authenticate the NG at the NR side. Additionally, the NR must be authenticated at the NG side and the NG must properly check VACM settings to ensure each notification sent to the NR is authorized. 2.1.1 Authentication Using a User Credential Devices could be configured with user credentials (EG, a user name and the user's public-key or password) to use when connecting to a NR. This would make use of the normal user-to-host mode of operation of SSH. Steps to send the notification (this is a very terse description of what happens when you combine SSH and SNMP for notifications; it's obviously a bit more complex as there are more steps involved; this is just a high level summary): 1) The NG would open a SNMP/SSH connection as an SSH Client to the NR acting as a SSH server. 2) The NR would send it's public (host) key and proof of ownership 3) The NG would verify that it was talking to the expected NR (by verifying the public key against the proof and by verifying that the public key presented matched the expected public key for that destination; see below). 4) The NG would transmit it's user name and it's own SSH authentication credentials (either the a public key, and proof or a password). 5) The NR would verify the authenticity of the received credentials. 6) The NG would send the notification through the established connection. The configuration pieces missing that are not currently available in any modern MIBs at this time: 1) The ability to indicate that ISMS/SSH should be used as the transport. EG: "Send a copy of the notification to host H using SSH to port P" 2) The Ability to specify the SSH user credential type to use (eg, public key or password) EG: "I'm 'Adam'" 3) The ability to configure that public-key or password EG: "I can prove I'm joe because I have the super secret password or can prove I have the needed private key" 4) end-destination expected public SSH host-key - the public key of the NR acting as an SSH Server that the NG acting as a SSH Client should be connecting to. EG: "Now prove to me that you're Bob so I know that you're not Eve" Note one security risk that needs to be mentioned about the above: 1) Username/password combinations are horrible things to use. SSH allows for it but in order to use it securely in order to prevent agent configuration theft compromising an entire network (see USM Key Localization) you'd have to use a different username/password configured into each agent. That doesn't scale wonderfully from a configuration point of view. Thus public/private keys should be used instead (of course). I'm not going to get into the debate here about whether we should support/allow username/password configuration for sending something). 2.1.1.1 Changes to the TARGET-MIB configuration This would result in notification destination parameter configuration that looked like (the settings explained next): snmpTargetParamsTable row: snmpTargetParamsName toNR (administrative string) snmpTargetParamsMPModel 3 (SNMPv3) * snmpTargetParamsSecurityModel 4 (SNMP/SSH mapping) * snmpTargetParamsSecurityName sshParams (The SSH parameter name) snmpTargetParamsSecurityLevel 3 (auth|encr) snmpTargetParamsStorageType 3 (nonVolatile) snmpTargetParamsRowStatus 4 (createAndGo) snmpTargetAddrTable row: snmpTargetAddrName toNRAddr (arbitrary string) + snmpTargetAddrTDomain snmpTCPDomain ++ snmpTargetAddrTAddress 0x0A00000100A2 (NR address, port) snmpTargetAddrTimeout 1500 (in .01 sec) snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toNRTag snmpTargetAddrParams toNR (must match prev) snmpTargetAddrStorageType 3 (nonVolatile) snmpTargetAddrColumnStatus 4 (createAndGo) * = changed since previous example. + = may change to snmpSSHDomain? subject to debate (the security model already indicates SSH but if we want a v1 or v2c security model then we'll need to use a snmpSSHDomain instead; I think this is likely at this point) ++ = shown as same but will likely change (likely a new port number from IANA) Because we need 4 configuration settings (1-4 above) and there is no room in the existing tables for some of that information (config setting #1 (use SSH) was done in the snmpTargetParamsSecurityModel and/or snmpTargetAddrTDomain), we'll need to create another table to contain the other 3 needed settings. I'll call this the snmpSSHParametersTable and it will contain the following information: snmpSSHParametersTable: index: snmpSSHParameterName sshParams (matches 2nd * above) columns: snmpSSHUserName Adam (the NG says "I'm Adam") snmpSSHUserCredentialType 1 (1 = userPublicKey, 2 = userPassword, 3 = hostPublicKey ... enum list) snmpSSHNGUserKey +++ (the expected NG Key if 1) snmpSSHNGUserPass ++++ (the passphrase to use if 2) snmpSSHNRHostKey +++ (the public key expected from the expected NR) +++ = potential issue with config via SNMP/UDP since these are potentially larger than SNMP/UDP would like. ++++ = a GET should return "" at all times? With all of this in place it is possible for a NG to open a connection to a NR and authenticate itself and verify the other end is the expected end. Note that we still haven't discussed user names; be patient! It is implementation dependent how the NR decides whether to accept notifications given the authentication provided by the NG. This is already true for SNMPv3/USM NR engines today (there is no NR authorization model in the SNMPv3 STDs). Notification delivery would fail if the snmpSSHNRHostKey didn't match the returned SSH public certificate given by the NR or if it failed to authenticate. The SSH connection also wouldn't succeed if the NR refused The question many should be asking at this point is, "but... we're trying *not* to configure so much stuff and we want to reuse existing authentication systems". - There is no way to avoid the configuration of the NR host key to be expected. Not doing so would be insecure. IE, snmpSSHNRHostKey is required. This *could* be bootstrapped using the normal SSH known_hosts cache if it already had a setting. A blank value, eg, could indicate use "use the existing known_hosts cache". Because this is expected to be a device that probably hasn't done SSH Client logins before, it's unlikely this host cache would exist. But it could be distributed via rdist, etc, if operators preferred that. It could be that this entire column could be left to SSH Client side implementation, but that doesn't seem complete to me and I'd rather see it in place rather than require an external distribution mechanism. - There is no way to avoid the configuration required by the client (snmpSSHUserName and related authentication data). *However*, if the snmpSSHUserCredentialType was 3 (hostPublicKey) and snmpSSHNRUserKey was "" (blank) then that could indicate to simply use the system configured ssh host key instead of using a separate one. This would alleviate this configuration setting and entirely rely on the pre-configured ssh service's host key. This does assume there is only one to choose from, however. If a system had more than one it is undefined what should happen. This is dual-using a SSH host key for both host usage and user usage, and it's unclear whether this should be frowned upon or not. Cryptography-wise it's generally not recommend that keys not be allowed to be shared between multiple identities (i.e. both a host and a user named 'Adam'). SSH actually already has an authentication mode designed to authenticate as a host directly though. See the next section for details. 2.1.2 Authentication Using a SSH Host-Key Devices with deployed SSH Host public-key credentials ("Host-Keys") already have a public key that is likely already known to a network management station. This is the same host identity that must be authenticated to when connecting to an agent operating as a CR when a management station takes on the role of a CG over SSH. It is possible to reuse the CR's SSH public host key when operating as a NG SSH-Client to open a connection back to a NR SSH-Server. To accomplish this, the NG would open a SSH connection to the NR and both sides would authenticate each other. The NR would use a host-key certificate per-normal SSH usage. The NG would present it's own host-key certificate to authenticate itself rather than present the more typical user-based credential as discussed in section 2.1.1. How to accomplish this via the SSH protocol is discussed in Section 9 of [RFC4252]. Note that for SSH this form of authentication support is OPTIONAL in this document. The ISMS/SSH document would have to require. Steps to send the notification: 1) The NG would open a SNMP/SSH connection to the NR. 2) The NR would send it's public key and proof of ownership 3) The NG would verify that it was talking to the expected NR (by verifying the public key against the proof and by verifying that the public key presented matched the expected public key for that destination). 4) The NG would transmit it's special host-based user name (see below) and it's host credential. 5) The NR would verify the authenticity of the received credentials. 6) The NG would send the notification through the established connection. Note: Section 9 of [RFC4252] actually specifies that for authorization purposes the NR can ignore the user name field for this authentication type. The NG must fill it in, however. For the new snmpSSHParametersTable settings, they would look like: snmpSSHParametersTable: snmpSSHParameterName sshParams (matches 2nd * above) snmpSSHUserName sshUser (the NG says "I'm sshUser") * snmpSSHUserCredentialType 3 (1 = userPublicKey, 2 = userPassword, 3 = hostPublicKey ... enum list should be pulled from ssh auth types?) * snmpSSHNGUserKey "" (the expected NG Key) (blank = default host key) snmpSSHNGUserPass "" (none) snmpSSHNRHostKey +++ (the expected NR Key) * = changed from last time +++ = issue with config via SNMP since these are potentially larger than SNMP/UDP would like. With the above in place, it should be possible to open a host-key based authentication from the NG to an NR. It is implementation dependent how the NR decides whether to accept notifications given the authentication provided by the NG. This is already true for SNMPv3/USM NR engines today. The primary advantage of this over the user-based credentials used in Section 2.1.1 is that the host-key has likely already been created and no credential configuration is needed and this is the SSH supported mechanism for using a host-based authentication mechanism. The NR, however, still needs to be configured to accept notifications from an NG using it's host-key credentials (and tied to the snmpSSHUserName passed in the "user name" field of the SSH_MSG_USERAUTH_REQUEST message described in Section 9 of [RFC4252]. 2.2 Reusing an existing SNMP/SSH Connection That Was Previously Established between the NG and NR. There has been desire to have an architecture where a Notification Receiver connects to a Notification Generator and notifications are then sent via this connection. This section describes how this can be done via SNMP/SSH using additional MIB configuration settings. Some of this desire has dropped a bit since this section was originally written. [I haven't re-proof-read this section as much.] Steps to send the notification: 1) The NR would open a SNMP/SSH connection to the NG. There are two choices here: a) Open only a single connection to the standard CR service endpoint which also happens to be capable of sending notifications back over the same stream (acting as a NG on the same session). b) One connection to the standard CR service, and a second to a NG service port. Note that notifications would not be sent until the rest of the following steps had taken place. 2) The CR and/or NG service(s) would send it's public key and proof of ownership. 3) The CG and/or NR would verify that it was talking to the expected CR/NG (by verifying the public key against the proof and by verifying that the public key presented matched the expected public key for that destination). 4) The CG/NR would transmit it's user name and credentials (either a public key, password or other SSH authentication mechanism). 5) The CR/NG would verify the authenticity of the received credentials. 6) The CG would configure the CR to send notifications over the already existing SNMP/SSH channels (configuration of the snmpNotifyTable not shown as it matches that in section 1.2): snmpTargetParamsTable row: snmpTargetParamsName toCR (administrative string) snmpTargetParamsMPModel 3 (SNMPv3) * snmpTargetParamsSecurityModel 4 (SSH) * snmpTargetParamsSecurityName XXX (see below) snmpTargetParamsSecurityLevel 3 (auth|encr) snmpTargetParamsStorageType 3 (nonVolatile) snmpTargetParamsRowStatus 4 (createAndGo) snmpTargetAddrTable row: snmpTargetAddrName toCRAddr (arbitrary string) * snmpTargetAddrTDomain snmpSSHSession * snmpTargetAddrTAddress YYY (see below) snmpTargetAddrTimeout 1500 (in .01 sec) snmpTargetAddrRetryCount 3 snmpTargetAddrTagList toCRTag snmpTargetAddrParams toCR (must match prev) snmpTargetAddrStorageType 3 (nonVolatile) snmpTargetAddrColumnStatus 4 (createAndGo) * = changed since previous example. In order to enable the NG to start sending notifications over either the current ssh session (the connection to the CR service) or another SSH session (a connection to the NG service), the XXX value of the snmpTargetParamsSecurityName and the YYY parameter of the snmpTargetAddrTAddress field need to be filled into to point to the proper session. This could be done in 2 different ways that I can think of (possibly more): option 1) snmpTargetAddrTDomain = snmpSSHSession snmpTargetParamsSecurityName = XXX = "NRUser" snmpTargetAddrTAddress = YYY = "" This would effectively state that the NG could send notifications to all connected SNMP/SSH sessions that the incoming (***only***) SNMP/SSH connection had authenticated as the SNMP/SSH user "NRUser". Outgoing sessions from the NG MUST NOT be checked for when looking for sessions that match this criteria. The VACM would be consulted based on the SNMP/SSH security model and the security Name of "NRUser" in this example. option 2) snmpTargetAddrTDomain = snmpSSHSession snmpTargetParamsSecurityName = XXX = "" snmpTargetAddrTAddress = YYY = 0x00000001 (session id) This would effectively state that the NG could send notifications to the SNMP/SSH session with a session id of 1. This could potentially be the exact same session that the CG/CR were speaking over, or it could be an "external" session such as one connected to via the CR. The VACM would be consulted based on the SNMP/SSH security model and the security name of the ***remote*** user name associated with the remote session #1 for incoming sessions. Outgoing sessions MUST NOT be referred to by the NG (see ????) (???? aside: actually I'm not sure this is required from a security stand point, but I don't like the security name associations that would have to happen between the configuration and the sessions... I'd rather just only do this for incoming sessions as it doesn't make my hairs stand up as potentially problematic). 3. VACM Authorization Here's where the important note discussed above comes into play: the VACM doesn't care how the securityName passed to it was derived and authenticated. It's not the job of the VACM to do that. It trusts the CR and NG engines to have done the right thing security wise. A lot of discussion has surrounded this point. What does the VACM use when doing authorization lookups? The NR/SSH server doesn't have a "user name" in the traditional sense of the word. It has proven that it has an adequate host key, however. Choices: 1) The local configuration has already dictated a user name to use via the snmpSSHUserName setting discussed above (assuming the text in this document is followed). This is the value that should be given to the VACM (along with an appropriate model and level settings based on the connection). It doesn't matter that the remote host didn't specify this value in the connection; the local configuration says this is the value that should be used and the remote side *has* proven that it can authenticate the NR host key that was expected. But, this doesn't allow for dual-user name support, which brings us to option 2: 2) If there is desire to have the NG/SSH-Client use one user name to authenticate itself to the remote NR/SSH-Server and another to consider the remote NR/SSH-Server to be for purposes of VACM authorization then another column in the snmpSSHParametersTable would be needed that might have something like: snmpSSHRemoteUser "Jack" Again, it does not matter that the remote side didn't technically specify itself as "Jack". It's already proven that it has the configure remote host key. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 2 02:05:51 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3E03A6E1A; Fri, 2 May 2008 02:05:51 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1FC3A6CA6 for ; Fri, 2 May 2008 02:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bcUtoELAa08 for ; Fri, 2 May 2008 02:05:46 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7F64128C452 for ; Fri, 2 May 2008 02:05:09 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4294uon013101; Fri, 2 May 2008 12:05:03 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 May 2008 12:04:48 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 May 2008 12:04:48 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 May 2008 12:04:47 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS/SSH and notifications Thread-index: Acir6gqqKzbn8lY6QbmF2iiGPJaVsAARti1g References: From: To: , X-OriginalArrivalTime: 02 May 2008 09:04:48.0663 (UTC) FILETIME=[92D26270:01C8AC33] X-Nokia-AV: Clean Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker wrote: > The following is based on the message I sent out in January in 2007 > and then later modified in July of 2007. I've now modified it for a > third time to fix some errors I found in it and have lengthened some > of the sections to talk more about the issues recently discussed > here. I think this looks pretty good! (Although there are really two quite different solutions, depending on which of the parties opens the SSH connection.) Couple of minor comments/questions: > 2.1.1.1 Changes to the TARGET-MIB configuration > snmpSSHParametersTable: > > index: > snmpSSHParameterName sshParams (matches > 2nd * above) > > columns: > snmpSSHUserName Adam (the NG says "I'm Adam") > snmpSSHUserCredentialType 1 (1 = userPublicKey, > 2 = userPassword, > 3 = hostPublicKey > ... enum list) > snmpSSHNGUserKey +++ (the expected NG Key if 1) Should this be "++++ (the NG public/private key pair if 1)"? > snmpSSHNGUserPass ++++ (the passphrase to use if 2) > snmpSSHNRHostKey +++ (the public key > expected from the > expected NR) > > +++ = potential issue with config via SNMP/UDP since these are > potentially larger than SNMP/UDP would like. > ++++ = a GET should return "" at all times? > > With all of this in place it is possible for a NG to open a > connection to a NR and authenticate itself and verify the other end > is the expected end. Note that we still haven't discussed user > names; be patient! > > It is implementation dependent how the NR decides whether to > accept notifications given the authentication provided by the NG. > This is already true for SNMPv3/USM NR engines today (there is no > NR authorization model in the SNMPv3 STDs). I guess one detail that still needs to be described is what's the securityName value passed to the notification receiver application. > 3. VACM Authorization > > Here's where the important note discussed above comes into play: the > VACM doesn't care how the securityName passed to it was derived and > authenticated. It's not the job of the VACM to do that. It trusts > the CR and NG engines to have done the right thing security wise. > > A lot of discussion has surrounded this point. What does the VACM > use when doing authorization lookups? The NR/SSH server doesn't > have a "user name" in the traditional sense of the word. It has > proven that it has an adequate host key, however. > > Choices: > > 1) The local configuration has already dictated a user name to use > via the snmpSSHUserName setting discussed above (assuming the > text in this document is followed). This is the value that > should be given to the VACM (along with an appropriate > model and level settings based on the connection). It doesn't > matter that the remote host didn't specify this value in the > connection; the local configuration says this is the value that > should be used and the remote side *has* proven that it can > authenticate the NR host key that was expected. > > But, this doesn't allow for dual-user name support, which brings > us to option 2: > > 2) If there is desire to have the NG/SSH-Client use one user name to > authenticate itself to the remote NR/SSH-Server and another to > consider the remote NR/SSH-Server to be for purposes of VACM > authorization then another column in the snmpSSHParametersTable > would be needed that might have something like: > > snmpSSHRemoteUser "Jack" > > Again, it does not matter that the remote side didn't technically > specify itself as "Jack". It's already proven that it has the > configure remote host key. Can't we use snmpTargetParamsSecurityName for this? Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 2 09:32:06 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1A63A6BAF; Fri, 2 May 2008 09:32:06 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA40E28C24F for ; Fri, 2 May 2008 09:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chi1bXvGzNnc for ; Fri, 2 May 2008 09:32:04 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 4F8C63A6BAF for ; Fri, 2 May 2008 09:32:04 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id AA96A399B9A; Fri, 2 May 2008 09:30:22 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=X+Ktns9WV6NwLikqMDdSGvm9I4Q=; b=C72RQLVX6RQJq7M01wn1HLfIgFhDfPeqaiveLseAJUbYAJwB9v/Kr5q9NK5iQ6zoK2Ltm9B4WLb4rR1JEhIq54XIcAde1S4z9W0zv4yLGGLqf8xGYFLLRckdtY/23wGZ0dkDZan18eyzzHqZYnKL57JsDueSDZG++7YfuD+hmbU= Received: by wes.hardakers.net (Postfix, from userid 274) id 5FBF839A254; Fri, 2 May 2008 09:30:21 -0700 (PDT) From: Wes Hardaker To: Organization: Sparta References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> Date: Fri, 02 May 2008 09:30:20 -0700 In-Reply-To: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> (Pasi Eronen's message of "Fri, 2 May 2008 12:04:47 +0300") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org PE> I think this looks pretty good! (Although there are really two PE> quite different solutions, depending on which of the parties PE> opens the SSH connection.) Yep. It's still up for debate if we want to allow the manager to open the connection. A few years ago it was looking like we should do it. I think desire has fallen a bit since then. I'm not really sure it's necessary and worth the complexity increase, but I'm not opposed to it either. > snmpSSHUserName Adam (the NG says "I'm Adam") > snmpSSHUserCredentialType 1 (1 = userPublicKey, > 2 = userPassword, > 3 = hostPublicKey > ... enum list) > snmpSSHNGUserKey +++ (the expected NG Key if 1) PE> Should this be "++++ (the NG public/private key pair if 1)"? Yep. Good point. (though a GET could return the public half) And it would probably be better to have 2 columns, one for the public key and one for the private. Or a button to generate a new key pair and that column would just return the public half of the generated pair and thus the private never has to traverse the network (but then we get into key generation parameters etc). Though we could also just opt-out of the whole configuration pile and say "use this public key; you'd better have the private somewhere in your ssh stash" (and a SET of an unknown public key would then fail with an error). > It is implementation dependent how the NR decides whether to > accept notifications given the authentication provided by the NG. > This is already true for SNMPv3/USM NR engines today (there is no > NR authorization model in the SNMPv3 STDs). PE> I guess one detail that still needs to be described is what's the PE> securityName value passed to the notification receiver application. For a user-server connection the security name could be pulled from the normal SSH connection. That's already taken care of. For a host based authentication you're right... maybe we should require the NR to accept the host based authentication name for the NR to use as a securityName. I haven't checked what the legal lengths of a host-based SSH authentication name can always fit within a securityName field (which is only 32 octets long). > 3. VACM Authorization > > Here's where the important note discussed above comes into play: the > VACM doesn't care how the securityName passed to it was derived and > authenticated. It's not the job of the VACM to do that. It trusts > the CR and NG engines to have done the right thing security wise. > > A lot of discussion has surrounded this point. What does the VACM > use when doing authorization lookups? The NR/SSH server doesn't > have a "user name" in the traditional sense of the word. It has > proven that it has an adequate host key, however. > > Choices: > > 1) The local configuration has already dictated a user name to use > via the snmpSSHUserName setting discussed above (assuming the > text in this document is followed). This is the value that > should be given to the VACM (along with an appropriate > model and level settings based on the connection). It doesn't > matter that the remote host didn't specify this value in the > connection; the local configuration says this is the value that > should be used and the remote side *has* proven that it can > authenticate the NR host key that was expected. > > But, this doesn't allow for dual-user name support, which brings > us to option 2: > > 2) If there is desire to have the NG/SSH-Client use one user name to > authenticate itself to the remote NR/SSH-Server and another to > consider the remote NR/SSH-Server to be for purposes of VACM > authorization then another column in the snmpSSHParametersTable > would be needed that might have something like: > > snmpSSHRemoteUser "Jack" > > Again, it does not matter that the remote side didn't technically > specify itself as "Jack". It's already proven that it has the > configure remote host key. PE> Can't we use snmpTargetParamsSecurityName for this? Yes. Somehow I forgot about that column. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 2 14:25:09 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A403A6E42; Fri, 2 May 2008 14:25:09 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03FE83A6BCF for ; Fri, 2 May 2008 14:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiXZWa9PP-6M for ; Fri, 2 May 2008 14:25:00 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id A34BF3A683E for ; Fri, 2 May 2008 14:23:54 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m42LNsie001346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 17:23:54 -0400 (EDT) Date: Fri, 02 May 2008 17:23:54 -0400 From: Jeffrey Hutzelman To: Pasi.Eronen@nokia.com, j.schoenwaelder@jacobs-university.de Message-ID: <56A3A84520CE94D1DDBD11E8@sirius.fac.cs.cmu.edu> In-Reply-To: <1696498986EFEC4D9153717DA325CB727BC9D2@vaebe104.NOE.Nokia.com> References: <20080423213343.GA14614@elstar.local> <1696498986EFEC4D9153717DA325CB7271D4AF@vaebe104.NOE.Nokia.com> <20080424183123.GF17532@elstar.local> <1696498986EFEC4D9153717DA325CB727BC9D2@vaebe104.NOE.Nokia.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, April 30, 2008 10:01:37 AM +0300 Pasi.Eronen@nokia.com wrote: > Juergen Schoenwaelder wrote: > >> > And if a given transportAddress has just one principal behind it, >> > we don't really have problems with SSH either, right? >> >> Almost. And SSH hostkey, as I understand it, identifies a host, not >> just a transport endpoint. But there might be ways to weak SSH to use >> different hostkeys for different transport endpoints on the same host. > > Although the SSH RFCs talks about "hosts", if a host would have more > than one SSH server running, they could have different "host" keys > (just like if you have multiple applications using TLS on the same > host, they might need different certificates). That is correct. So, if you're sending SNMP notifications, the right way to think about this is not that you're going to connect to an sshd and have it demultiplex, but that you'll have been given a transport endpoint which reaches an sshd with the intended recipient's credentials. > (I think we can handle the latter: the securityName given by the > notification originator application would identify the intended > recipient, and would be used for access control on the notification > originator side -- but the SSH user name sent when connecting > to the notification receiver would identify the originator.) Yes, exactly so. Interestingly, there is nothing in SSH that says that "host keys" must belong to an Internet host, or to an IP address, or to a hostname. In fact, SSH says very little at all about how clients should track host keys. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon May 5 06:19:58 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EBEA3A6B7A; Mon, 5 May 2008 06:19:58 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBB6F3A6DC0 for ; Mon, 5 May 2008 06:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z5HbkSdRt4W for ; Mon, 5 May 2008 06:19:30 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 59B7028C1DD for ; Mon, 5 May 2008 06:19:09 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m45DIWvb025308; Mon, 5 May 2008 16:18:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 May 2008 16:17:56 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 May 2008 16:17:55 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 May 2008 16:17:56 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS/SSH and notifications Thread-index: AcischKgGXej5lMRRl2a3SbOl6eYxACPg94w References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 05 May 2008 13:17:55.0746 (UTC) FILETIME=[6E449820:01C8AEB2] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker wrote: > > snmpSSHUserName Adam (the NG says > > "I'm Adam") > > snmpSSHUserCredentialType 1 (1 = userPublicKey, > > 2 = userPassword, > > 3 = hostPublicKey > > ... enum list) > > snmpSSHNGUserKey +++ (the expected > > NG Key if 1) > > PE> Should this be "++++ (the NG public/private key pair if 1)"? > > Yep. Good point. > > (though a GET could return the public half) > > And it would probably be better to have 2 columns, one for the > public key and one for the private. Or a button to generate a new > key pair and that column would just return the public half of the > generated pair and thus the private never has to traverse the > network (but then we get into key generation parameters etc). Is there any precedent for this, e.g. other MIBs that manage public keys in some way? Or generate new keys? > Though we could also just opt-out of the whole configuration pile > and say "use this public key; you'd better have the private > somewhere in your ssh stash" (and a SET of an unknown public key > would then fail with an error). Or to make it more admin-friendly, maybe just pass a name/token of some kind; the SSH stash would be responsible for handling both public and private parts of the key? (I guess on the SSH server side, we anyway won't have detailed MIBs for configuring things.) > > It is implementation dependent how the NR decides whether to > > accept notifications given the authentication provided by the NG. > > This is already true for SNMPv3/USM NR engines today (there is no > > NR authorization model in the SNMPv3 STDs). > > PE> I guess one detail that still needs to be described is what's > PE> the securityName value passed to the notification receiver > PE> application. > > For a user-server connection the security name could be pulled from > the normal SSH connection. That's already taken care of. Well... the SSH user name seen by the notification receiver (SSH server) really identifies the notification generator, so it's not the same as the securityName given by the notification generator application. If we want to preserve this property, we need something else... Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon May 5 11:46:13 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA7A3A6935; Mon, 5 May 2008 11:46:13 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9695E3A6935 for ; Mon, 5 May 2008 11:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbD5DHjZDy4P for ; Mon, 5 May 2008 11:46:11 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id D190D3A6866 for ; Mon, 5 May 2008 11:46:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Dj24t1puGocTDYJC1rdq4ND+gLh4q2Z8icvkdxt/iiHpN/+PJ15Hry6SM/1IlL7F; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.42] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jt5hS-0005zl-CH for isms@ietf.org; Mon, 05 May 2008 14:46:10 -0400 Message-ID: <00a201c8aed7$f0a97c20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> Date: Mon, 5 May 2008 11:46:25 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3eb9c6f660f4d22d43d0edd3248cd8da8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.42 Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: > To: > Cc: > Sent: Monday, May 05, 2008 7:17 AM > Subject: Re: [Isms] ISMS/SSH and notifications ... > > And it would probably be better to have 2 columns, one for the > > public key and one for the private. Or a button to generate a new > > key pair and that column would just return the public half of the > > generated pair and thus the private never has to traverse the > > network (but then we get into key generation parameters etc). > > Is there any precedent for this, e.g. other MIBs that manage > public keys in some way? Or generate new keys? ... Yes, going back at least as far as RFC 1352. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon May 5 13:31:45 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3E93A6C38; Mon, 5 May 2008 13:31:45 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E4A3A6A86 for ; Mon, 5 May 2008 13:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0any6bVLkxL for ; Mon, 5 May 2008 13:31:43 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 6ACB53A6C91 for ; Mon, 5 May 2008 13:31:43 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 376B12C3EEA; Mon, 5 May 2008 13:29:39 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=b7Kpz2JAwwjHHXweOwQs22GyR3Q=; b=OuhNdfvHsqYm+nNiYtOYnNx64hePCZhGuOl5GVAJdEunEuj0ueOabkqC7F6nertZRsQhumAcvOVGyVGq2c5qfGxcW6ILODfEMEedHEY+Sao1b0HYecNddTDpd0bT6qjSOBGoRFSudueI+NdXYFfOJiXqDatQrq4H2ja4a0ZYIlY= Received: by wes.hardakers.net (Postfix, from userid 274) id 1564B2C3228; Mon, 5 May 2008 13:29:39 -0700 (PDT) From: Wes Hardaker To: Organization: Sparta References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> Date: Mon, 05 May 2008 13:29:38 -0700 In-Reply-To: <1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> (Pasi Eronen's message of "Mon, 5 May 2008 16:17:56 +0300") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Mon, 5 May 2008 16:17:56 +0300, said: PE> Is there any precedent for this, e.g. other MIBs that manage PE> public keys in some way? Or generate new keys? As Randy mentioned, yes. The USM-DH MIB also has some prior history. >> Though we could also just opt-out of the whole configuration pile >> and say "use this public key; you'd better have the private >> somewhere in your ssh stash" (and a SET of an unknown public key >> would then fail with an error). PE> Or to make it more admin-friendly, maybe just pass a name/token of PE> some kind; the SSH stash would be responsible for handling both PE> public and private parts of the key? The problem with that is that the current SSH implementations don't support named keys at this point. Not that it can't be done, but it'd require new features of the SSH service or an independent name mapping on the SNMP side. >> For a user-server connection the security name could be pulled from >> the normal SSH connection. That's already taken care of. PE> Well... the SSH user name seen by the notification receiver (SSH PE> server) really identifies the notification generator, so it's not PE> the same as the securityName given by the notification generator PE> application. If we want to preserve this property, we need something PE> else... I'm not sure which property you're talking about preserving. (USM actually operates in one of two modes depending on whether TRAPs or INFORMs are being sent). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 9 04:31:31 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E80228C1DE; Fri, 9 May 2008 04:31:31 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232DA3A684B for ; Fri, 9 May 2008 04:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-999 required=5 tests=[AWL=-1.798, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOXhpR4zp4wL for ; Fri, 9 May 2008 04:26:37 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id F1B453A681E for ; Fri, 9 May 2008 04:26:36 -0700 (PDT) Received: from mgw-mx03.nokia.com (mgw-mx03.nokia.com [192.100.122.230]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m49BMpq0014487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 May 2008 14:22:52 +0300 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m49BJAxW023577; Fri, 9 May 2008 14:19:37 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 May 2008 14:19:26 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 May 2008 14:19:25 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 14:19:27 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS/SSH and notifications Thread-index: Aciu7w9wSJsODvfIQICEn7L1DaphYwC1wXKg References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> From: "Pasi.Eronen@nokia.com" To: X-OriginalArrivalTime: 09 May 2008 11:19:25.0852 (UTC) FILETIME=[8A17DDC0:01C8B1C6] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker wrote: > PE> Well... the SSH user name seen by the notification receiver (SSH > PE> server) really identifies the notification generator, so it's not > PE> the same as the securityName given by the notification generator > PE> application. If we want to preserve this property, we > PE> need something else... > > I'm not sure which property you're talking about preserving. (USM > actually operates in one of two modes depending on whether TRAPs or > INFORMs are being sent). The property that securityName given in notification originator's sendPdu() call is the same as the notification receiver gets in the processPdu() call (in RFC 3413 terms). (However, it's possible that preserving this property exactly is not absolutely required, since the current RFCs don't seem to specify how, if at all, the notification receiver would use this information.) Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 9 05:31:38 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C907F3A6980; Fri, 9 May 2008 05:31:38 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CCD63A67FA for ; Fri, 9 May 2008 05:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.247 X-Spam-Level: X-Spam-Status: No, score=-4.247 tagged_above=-999 required=5 tests=[AWL=-1.648, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiD-8+aAE35d for ; Fri, 9 May 2008 05:18:10 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id EFC573A67B6 for ; Fri, 9 May 2008 05:18:09 -0700 (PDT) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m49CEvFW025649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 May 2008 15:14:59 +0300 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m49CAbqn013696; Fri, 9 May 2008 07:11:41 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 May 2008 15:11:13 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 May 2008 15:11:12 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 15:11:16 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72925044@vaebe104.NOE.Nokia.com> In-Reply-To: <6AC65FD74E2B984A95EED496FBFC59FC9C36C8@IMCSRV3.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS/SSH and notifications Thread-index: Aciu7w9wSJsODvfIQICEn7L1DaphYwC1wXKgAACHV3AAAVz0UA== References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> <6AC65FD74E2B984A95EED496FBFC59FC9C36C8@IMCSRV3.MITRE.ORG> From: "Pasi.Eronen@nokia.com" To: , X-OriginalArrivalTime: 09 May 2008 12:11:12.0875 (UTC) FILETIME=[C605F3B0:01C8B1CD] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Ray Purvis wrote: > [Ray Purvis] Isn't the securityName, in the current RFCs, and thus > for the use of USM, used with the snmpEngineID to locate the > authentication and privacy key to authenticate/decrypt the > notification? Yes; with SSHTM, at the point when the securityName actually could be visible, the packet has already been authenticated and decrypted. Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 9 05:31:38 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64633A698B; Fri, 9 May 2008 05:31:38 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849803A67FA for ; Fri, 9 May 2008 05:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Km7UhUwJAPoS for ; Fri, 9 May 2008 05:21:37 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 82F0A3A67B6 for ; Fri, 9 May 2008 05:21:37 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m49CH5lw021157 for ; Fri, 9 May 2008 08:17:06 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m49CH5KQ021136; Fri, 9 May 2008 08:17:05 -0400 Received: from IMCSRV3.MITRE.ORG ([129.83.20.198]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 08:17:06 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 May 2008 08:17:05 -0400 Message-ID: <6AC65FD74E2B984A95EED496FBFC59FC9C36CA@IMCSRV3.MITRE.ORG> In-Reply-To: <1696498986EFEC4D9153717DA325CB72925044@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS/SSH and notifications Thread-Index: Aciu7w9wSJsODvfIQICEn7L1DaphYwC1wXKgAACHV3AAAVz0UAAAMeKQ References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> <6AC65FD74E2B984A95EED496FBFC59FC9C36C8@IMCSRV3.MITRE.ORG> <1696498986EFEC4D9153717DA325CB72925044@vaebe104.NOE.Nokia.com> From: "Purvis, Ray" To: , X-OriginalArrivalTime: 09 May 2008 12:17:06.0024 (UTC) FILETIME=[98843680:01C8B1CE] Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0024553839==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is a multipart message in MIME format. --===============0024553839== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0020_01C8B1A4.AF18F360"; protocol="application/x-pkcs7-signature" This is a multipart message in MIME format. ------=_NextPart_000_0020_01C8B1A4.AF18F360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, of course, I had USM on the brain. For TSM, the notification receiver doesn't really have a whole lot to do with the securityName, does it? Thanks much. Ray -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Friday, May 09, 2008 7:11 AM To: Purvis, Ray; wjhns1@hardakers.net Cc: isms@ietf.org Subject: RE: [Isms] ISMS/SSH and notifications Ray Purvis wrote: > [Ray Purvis] Isn't the securityName, in the current RFCs, and thus > for the use of USM, used with the snmpEngineID to locate the > authentication and privacy key to authenticate/decrypt the > notification? Yes; with SSHTM, at the point when the securityName actually could be visible, the packet has already been authenticated and decrypted. Best regards, Pasi ------=_NextPart_000_0020_01C8B1A4.AF18F360 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKuzCCA2Qw ggJMoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWjESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQL ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMTG01JVFJFIENvcnBvcmF0aW9uIFJvb3Qg Q0EtMTAeFw0wNjA2MDEwNDAwMDBaFw0xODA2MDEwNDAwMDBaMFoxEjAQBgNVBAoTCW1pdHJlLm9y ZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3Jh dGlvbiBSb290IENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCva1qWPZiEJv5v MtCbjt0cTu0Nbn15Q1cKqQBXKi8VSH9zZPmPxfWizJJ7JSqFJ5/sLUz3NsnUVjpLYBdFcxNXnOLj XtmDPFOewm5T98NZc9wRRCiDzt4f8qsHFI19ShPiK3cN5UqtJf+i66QVLA1S6CNL6o2eGAsAl5Wn xwOh2BfcWU5fNlHDVc9KKAlDDWpHjC2LLHAUbLP4ZzMIJKcLgLKFMtgM2AEfaSHzmi7WUdUHRCtC blrF7qzPsy/jBLFrr8VcX+mb7saq95pEOilgcix0/naW7kJfM5ph7UBB+S1O/OhH+ZjQ4MjWnwE8 A/YDrQx1OVLAOi29Bsho/l8lAgMBAAGjNTAzMBIGA1UdEwEB/wQIMAYBAf8CAQMwHQYDVR0OBBYE FMdwUQDYTf7kAdRolsU9n5qX/nQvMA0GCSqGSIb3DQEBBQUAA4IBAQAa+fVfCljimBlcfWwkfJXu XNKWun9xloFKjnq6SPGgAIKi5LUDil60a0NaNGoGSO3I1xzYt7ncayh21qXulcVTDFqubSJdv51a HTuJYcYUX72LN/gSq03UVLBCJzYm7ZLUlkb2YLo7xUeZ3coLFcT5AHR36kjG4cYHqXgH0liBl8jx pN0gwgaci4sgPLUj1w4t8zoKH+zxGFwXwTP/P+etQqiJZ5T00fLLm5kz9mmnxxmmIvUGNdsCAhGh dnF24pcrR43LNgyOBJ9DPUHBNq3kUQRO48WBKxBxflOtKzsICx/HEtIABcZn7deADHcY9spULZfB nQYdEpyz5tgh7Y2qMIIDZzCCAk+gAwIBAgICFqswDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJF IENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODAyMTMxNTM1MjJaFw0wOTA4MDYxNTM1MjJa MFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZImiZPyLGQBARMH cnB1cnZpczEaMBgGA1UEAxMRUHVydmlzIFJheW1vbmQgSy4wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAMLsR5jBXwsj9oNA5OPbuTND/QTAJlridlWBGFeE33+FbKLTwm36BWwlRA+Vtzu4z1wh mXat+JWyT5gGl6/K5mH3XZdlvowgkNpAOIhuzdeym6J1djv4r6VhwqBC0hoDumuKdLCalYbhCqtL kVE4pZehT8jpV/7+tn9xacyAGPFFAgMBAAGjgbcwgbQwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQW BBSFbMT3jYifJ8L8HaW7UztasSWlezAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21p dHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERcnB1cnZpc0BtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQAD ggEBACNPzWemHNWSeK5noshsdg8PH+1PjDRbUyNskeTIuN6LFdEd08Fw8rPqjbbWjVmVLqZ3j4Tq UIn27ojMbjvfoWUWSo2cxv+kIaDGshtb+NEcd9t9xk948qu9OvV+vruTtEvRbdREiDV5cbW7WCJA 3rUmELvKvEtR0/SUkeQjXsoj84HyiUVPsVCxRTajLO3hQvXz0Z2GSXs8Ek2Q3N4gA8Ov88dAaUfp wjBj5+KZlbd8oWf+7mdS7+gI6p/BghoXXMDrsDv558ak+H9a0WDoILvixJG1jKESbyHgm5olj5fK lCVWlPbtuLX/oG5LPhtr7OsbgBPFVSp1EmE8aPV6VW8wggPkMIICzKADAgECAgEFMA0GCSqGSIb3 DQEBBQUAMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y aXR5MSQwIgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIy WhcNMTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFP MXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2 ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhIC fgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzzt C+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBq mQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQW BBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBI BgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNh MV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClq ix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatG moibqP/8WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo8 2ZiyU680ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M 6WHcxWXtp3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxM nGdh7NqgMYICvTCCArkCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRp ZmljYXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x AgIWqzAJBgUrDgMCGgUAoIIBsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wODA1MDkxMjE3MDVaMCMGCSqGSIb3DQEJBDEWBBRcWe6nSX/pz7Zy2g3UYrRt2Aa8qTBn BgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3 EAQxZTBjMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9y aXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAharMHQGCyqGSIb3 DQEJEAILMWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIWqzANBgkq hkiG9w0BAQEFAASBgHdr/BxMRa3fescHwldGAJlueg63VLw9+wmEcfqt/2KmjNdwDIVy5XhDFHwN 97KgajZYIk1KbgVu87XV6i7xApupznigkMVKSQ8AYml5qefIGmrhvVGQpkqCTYKW4Oncz7jRfw82 38Rq+SFIDK4rAjngsWI+RZXtML18HtJ9j0aKAAAAAAAA ------=_NextPart_000_0020_01C8B1A4.AF18F360-- --===============0024553839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --===============0024553839==-- From isms-bounces@ietf.org Fri May 9 07:47:49 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253263A6941; Fri, 9 May 2008 07:47:49 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0450C3A67FA for ; Fri, 9 May 2008 07:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnZ3eGHDR3Bu for ; Fri, 9 May 2008 07:36:27 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id E78EC3A67CE for ; Fri, 9 May 2008 07:36:26 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id E42E92C3EEA; Fri, 9 May 2008 07:28:13 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=pDXY27xnq3BgJtJCBRezwulXM3A=; b=CDGjxI4LxqmqMDAlu7GKQ6snyUBmCSw9LB9gk6NYcOgW9ZFD9ycYu28saen3B5CwnS7rkQH2k5ALog1KFaKs0/Vi2kjmJsPWlKJ6+owr1C/hJZec7XOzujRoGYciNJo1IRIEQNVcvR0LiOpQmjw2VJ/USB1waLLnvfZ4j2m/GU0= Received: by wes.hardakers.net (Postfix, from userid 274) id C33DB2C3228; Fri, 9 May 2008 07:28:12 -0700 (PDT) From: Wes Hardaker To: "Purvis\, Ray" Organization: Sparta References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> <6AC65FD74E2B984A95EED496FBFC59FC9C36C8@IMCSRV3.MITRE.ORG> <1696498986EFEC4D9153717DA325CB72925044@vaebe104.NOE.Nokia.com> <6AC65FD74E2B984A95EED496FBFC59FC9C36CA@IMCSRV3.MITRE.ORG> Date: Fri, 09 May 2008 07:28:10 -0700 In-Reply-To: <6AC65FD74E2B984A95EED496FBFC59FC9C36CA@IMCSRV3.MITRE.ORG> (Ray Purvis's message of "Fri, 9 May 2008 08:17:05 -0400") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Fri, 9 May 2008 08:17:05 -0400, "Purvis, Ray" said: RP> Yes, of course, I had USM on the brain. For TSM, the notification receiver RP> doesn't really have a whole lot to do with the securityName, does it? It is important to identify who sent the message. Notification receivers are fairly boring in their current ability to log stuff, however. Frequently they just display logs associated with an IP address and possibly a port. Right now the SNMP standards don't dictate that the securityName be used much on the notification receiver side. Note that even the NOTIFICATION-LOG-MIB doesn't have an entry fro the securityName used to send the message (just the context engineID and transport information). There is no securityName for SNMPv1/SNMPv2c so to some extent this does make sense. Net-SNMP (a single point of data as a reference) actually does use the securityName to authorize what a received notification is allowed to do (log, forward and execute being the current 3 possible outputs to the authorization process). I think Net-SNMP is fairly unique here as most notification receivers don't do any authorization checks other than to assure the packet has been properly authenticated. But... My point was that there is no current standard that requires they be the same on both sides. Both sides may need to make a decision or use the resulting securityName. But there isn't a requirement that the be administratively identical on both sides. The SSH transport will accept a user name on the client side to "use" in the transport, and the server side will be able to extract that same name. There is no reason why administratively it can't be the name configured on both sides to be *the* securityName. But there is no *current* great reason why on the sending side it couldn't be different as well. I think I'm digressing a bit though. The original point of my message had nothing to do with the security name the notification receiver was using (it essentially would be the ssh user name accepted through the ssh transport). The issue on the table originally "if USM INFORMs considers the remote notification receiver to be authoritative, and thus the securityName is technically defined by the remote side and if SSH doesn't give us a "name" to use to identify the INFORM receiver with, then what do we use to do a VACM authorization check?". My point was: we have information on the client side that we can use already. If we want to use the user name we sent as a client, that's fine. If we want to use something different, that's fine too (IMHO here). The important thing, and this is critical, is that whatever we decide to call the notification receiver securityName-wise we MUST make sure the public key returned by the SSH server and authenticated by the SSH client side is the same as the public key we were expecting. Otherwise, all bets are off. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 9 09:04:03 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57273A69B3; Fri, 9 May 2008 09:04:03 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7EC83A67FA for ; Fri, 9 May 2008 08:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip7yAr1TD8O9 for ; Fri, 9 May 2008 08:59:19 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id F26B03A67CE for ; Fri, 9 May 2008 08:59:18 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m49BXrgq023348 for ; Fri, 9 May 2008 07:33:54 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m49BXrFE023331; Fri, 9 May 2008 07:33:53 -0400 Received: from IMCSRV3.MITRE.ORG ([129.83.20.198]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 07:33:53 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 x-mimeole: Produced By Microsoft Exchange V6.5 Date: Fri, 9 May 2008 07:33:53 -0400 Message-ID: <6AC65FD74E2B984A95EED496FBFC59FC9C36C8@IMCSRV3.MITRE.ORG> In-Reply-To: <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS/SSH and notifications Thread-Index: Aciu7w9wSJsODvfIQICEn7L1DaphYwC1wXKgAACHV3A= References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> From: "Purvis, Ray" To: , X-OriginalArrivalTime: 09 May 2008 11:33:53.0389 (UTC) FILETIME=[8F2F81D0:01C8B1C8] Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org -----Original Message----- From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Friday, May 09, 2008 6:19 AM To: wjhns1@hardakers.net Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications Wes Hardaker wrote: > PE> Well... the SSH user name seen by the notification receiver (SSH > PE> server) really identifies the notification generator, so it's not > PE> the same as the securityName given by the notification generator > PE> application. If we want to preserve this property, we > PE> need something else... > > I'm not sure which property you're talking about preserving. (USM > actually operates in one of two modes depending on whether TRAPs or > INFORMs are being sent). The property that securityName given in notification originator's sendPdu() call is the same as the notification receiver gets in the processPdu() call (in RFC 3413 terms). (However, it's possible that preserving this property exactly is not absolutely required, since the current RFCs don't seem to specify how, if at all, the notification receiver would use this information.) [Ray Purvis] Isn't the securityName, in the current RFCs, and thus for the use of USM, used with the snmpEngineID to locate the authentication and privacy key to authenticate/decrypt the notification? v/r Ray Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 13 10:55:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790CD3A6C21; Tue, 13 May 2008 10:55:39 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293FF3A6BFE for ; Tue, 13 May 2008 10:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBievgLfp3FR for ; Tue, 13 May 2008 10:55:33 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 01B7B3A6BF3 for ; Tue, 13 May 2008 10:55:32 -0700 (PDT) X-Trace: 79858987/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.50.88 X-SBRS: None X-RemoteIP: 213.116.50.88 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAJhyKUjVdDJY/2dsb2JhbABBixCiKgQ X-IP-Direction: IN Received: from 1cust88.tnt101.lnd4.gbr.da.uu.net (HELO allison) ([213.116.50.88]) by smtp.pipex.tiscali.co.uk with SMTP; 13 May 2008 18:54:49 +0100 Message-ID: <029c01c8b519$721a5f80$0601a8c0@allison> From: "tom.petch" To: , References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> Date: Tue, 13 May 2008 16:32:18 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: To: Cc: Sent: Friday, May 09, 2008 1:19 PM Subject: Re: [Isms] ISMS/SSH and notifications > Wes Hardaker wrote: > > > PE> Well... the SSH user name seen by the notification receiver (SSH > > PE> server) really identifies the notification generator, so it's not > > PE> the same as the securityName given by the notification generator > > PE> application. If we want to preserve this property, we > > PE> need something else... > > > > I'm not sure which property you're talking about preserving. (USM > > actually operates in one of two modes depending on whether TRAPs or > > INFORMs are being sent). > > The property that securityName given in notification originator's > sendPdu() call is the same as the notification receiver gets in > the processPdu() call (in RFC 3413 terms). > > (However, it's possible that preserving this property exactly is not > absolutely required, since the current RFCs don't seem to specify how, > if at all, the notification receiver would use this information.) > I am not clear what problem this is solving. The problem I see, which has been mulled over for some three years and Juergen articulated last month, is that access control in the NO checks that the NR is permitted to see the data in the notification based on the securityName. For that check to be of any value, then the name needs authenticating, which means that the NR should supply credentials for it. So Wes is right to say that VACM is not responsible for checking it but I think wrong to say that it is ok to take whatever the application gives it. The security model should stand between the two and check that the secure transport ends at something with that name and with verified security credentials (as USM does). And as has been pointed out several times, when the NO originates the session, and the NO is the ssh client, then that credential is a public key. So that is what the NO should be checking and what VACM should have in its tables:-) I do not see these proposals as solving that problem. Tom Petch > Best regards, > Pasi > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 13 14:19:43 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E553A68D4; Tue, 13 May 2008 14:19:43 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411143A67AE for ; Tue, 13 May 2008 14:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSzGJyEDqXrA for ; Tue, 13 May 2008 14:19:34 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 404083A68D4 for ; Tue, 13 May 2008 14:19:33 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 08D042C41B3; Tue, 13 May 2008 14:11:51 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=NOEPNenTzT4vWaM2Fjm5/ixyv4Y=; b=A3iUSPkWhuM3RJTD3rAI+Mlpe4Cxi/OMCkE2Na+UnI53MWw6Zshc6YLLY/7p42d5wzaKSrCjrqV6L/9jP43QVQLhGo/Btxbfbmt3dYOzKYq90cU8puIJPTjMGxp+ifDcZGSepNS+euUTdE8qPr1dolO5LjuPbWuDxzqv8jTyKhM= Received: by wes.hardakers.net (Postfix, from userid 274) id DD8C92C41B2; Tue, 13 May 2008 14:11:50 -0700 (PDT) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> <029c01c8b519$721a5f80$0601a8c0@allison> Date: Tue, 13 May 2008 14:11:50 -0700 In-Reply-To: <029c01c8b519$721a5f80$0601a8c0@allison> (tom petch's message of "Tue, 13 May 2008 16:32:18 +0200") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Tue, 13 May 2008 16:32:18 +0200, "tom.petch" said: tp> The problem I see, which has been mulled over for some three years tp> and Juergen articulated last month, is that access control in the NO tp> checks that the NR is permitted to see the data in the notification tp> based on the securityName. Correct. The VACM uses a securityName to make an access control decision. The security model is responsible for determining that the other side isn't "faking it". The security model (SM) is responsible for mapping "something security-model specific" (paraphrasing the architecture here) to a securityName that could be used "beyond that point" (again, paraphrasing), like the application (NG, NO, CR, CG) for example. The "beyond that point" apps trust the SM to have given it an appropriate securityName. The question is, where does that name come from? There are three potential places: 1) configuration 2) somewhere in the packet 3) somewhere in the security credentials Where it comes from only is tied together cryptographically if it's in the keying material (#3) is chosen (keep reading to get comments on #2) tp> For that check to be of any value, then the name needs tp> authenticating, which means that the NR should supply credentials tp> for it. Not necessarily true. In a security model that didn't have a 1:1 mapping from something in the packet to the securityName then the security model has to *derive* the securityName to use. It does this through a security model specific transformation (the SNMPv3 architecture very wisely allowed for this possibly and discusses it in various places). What, does a protocol which has no in-packet direct "note" saying "I'm Bob" do? The choices (marker: ***) are: 1) throw up your hands and say "this protocol is useless". I don't buy this option but apparently some are willing to just ditch SSH because there is no magical 1:1 mapping transformation. 2) Use some other in-protocol field to "transform" into a security name. This could be, for example, the SSH server name offered up by the SSH server side of the protocol. This is one potential solution out of this space. The securityName would be set to "wjh.hardakers.net", for example, if a client was trying to connect to my laptop. The issue will come, however, that the legal length of a host name is longer than that of the legal securityName value that is used to look up a VACM entry. 3) A configured mapping table. Something in the packet or in the configuration that created the session could be used to look up, in a configured lookup table, what the securityName should be based on cryptographically proven (assuming at least authNoPriv) portions of the packet. Like the server's SSH public key. Only public key *certificates* (note the added word) actually containing identifying information in the certificate itself that says "I'm Bob, and not only that if I alter this certificate saying I'm now Eve it won't work". SSH doesn't operate this way; the application says "I'm Bob and I'm using this key" but the key doesn't prove it. The keys only prove that the application has the private key. It could still say "Eve" and you can still only verify that eve has a private key you recognize and potentially trust. The USM doesn't provide any assurance that the keying material it uses is attached to a particular name as well. Every user in the USM table could all be configured with the same localized key so that Bob, Mary, Eve and Joe all could swap account names and the far other side would do VACM checks on whatever name was given to it in the packet regardless of the fact that they could have picked from a few. That wouldn't be allowed with an X.509 cert, for example, but would be with both SSH and USM. tp> So Wes is right to say that VACM is not responsible for checking it tp> but I think wrong to say that it is ok to take whatever the tp> application gives it. The security model should stand between the tp> two and check that the secure transport ends at something with that tp> name and with verified security credentials (as USM does). No, actually the USM doesn't do this. A couple of problems exist in this logic: 1) The security model hands the securityName back to the application and says "I got this message from this dude named 'Bob'". The application already takes the value 'Bob' and can change it to whatever it wants before handing it to the VACM. There is no security check in the architecture today that the application isn't discarding what it got from the SM and winging it. The security model doesn't "stand between the two" like you suggest. (a historic aside: there was actually an alternate SNMPv3 architecture ID that attempted to allow the SM and the ACM blocks to communicate so that the ACM could verify wit the SM that the application wasn't lying to it, but it never got published. I was even part of a team that did a reference implementation of it that really showed you have to have the SM and the ACM blocks be memory protected from the application for it to actually be an effective security mitigation and no SNMP stack these days really supports that separation). 2) The initiating application (NG or CG) is the one that actually tells the remote side who it is when USM is used. More importantly, it really says "we're both Bob; I can prove I'm Bob and please prove you are too when you send a response". The CR and NR merely use this fact to look up the proper keying material to use to ensure that they can be Bob. tp> And as has been pointed out several times, when the NO originates tp> the session, and the NO is the ssh client, then that credential is a tp> public key. The *client* credential is a public key. As is the servers. tp> So that is what the NO should be checking and what VACM should have tp> in its tables:-) Right, that's actually what I said. You could use the server's key to do a lookup in a table to ensure you're talking to Bob. If they say I have key 0xABCD and you have "Bob" next to 0xABCD in your keying table, then you can be completely sure it's "Bob" at the other end. The only two forward paths that exist are #2 and #3 from *** above. I'm honestly happy with either, though #2 (using the SSH server host name as the securityName) would limit the hostnames I can use but, and this is my important point, it doesn't provide me with any extra security over #3 (using a mapping table so the key would be used to lookup the value of the securityName to use). A lookup would be done in the process of sending a trap. The configuration would specify the remote securityName and the public key of the remote server to verify it's the right securityName on the other side. Cryptographically speaking, you still don't have any assurance that the application hasn't messed with the data before the VACM uses it nor do you have any assurance that the public key in use wasn't intended to be used by a completely different name. You still can be completely assured that whoever is listening on the other side, be it Bob or Eve, could convenience you that they're both Bob and Eve or whatever name you want them to be. They have the private key to prove it and that's all you can care about. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 13 20:16:15 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E1C3A68CD; Tue, 13 May 2008 20:16:15 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC203A69B1 for ; Tue, 13 May 2008 20:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQojZL-rePz4 for ; Tue, 13 May 2008 20:16:12 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 53A1F3A68CD for ; Tue, 13 May 2008 20:16:12 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id RDWg1Z01v0b6N64A506r00; Wed, 14 May 2008 03:15:56 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id RFGB1Z0014HwxpC8P00000; Wed, 14 May 2008 03:16:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=-F-DWY4-qxep6i7d4ZQA:9 a=XbuK12RsQKaAh-tVFlYA:7 a=u83H3ARgH2etK_j1oa0eO0BKRl0A:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Wes Hardaker'" , "'tom.petch'" References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com><029c01c8b519$721a5f80$0601a8c0@allison> Date: Tue, 13 May 2008 23:16:10 -0400 Message-ID: <06b101c8b570$dccce800$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aci1PxuP1ffxKJ9LQhWKGJug2tz/UAAIbvuw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > > tp> So Wes is right to say that VACM is not responsible for > checking it > tp> but I think wrong to say that it is ok to take whatever the > tp> application gives it. The security model should stand between the > tp> two and check that the secure transport ends at something > with that > tp> name and with verified security credentials (as USM does). > > No, actually the USM doesn't do this. A couple of problems exist in > this logic: > > 1) The security model hands the securityName back to the > application and > says "I got this message from this dude named 'Bob'". The > application already takes the value 'Bob' and can change it to > whatever it wants before handing it to the VACM. There is no > security check in the architecture today that the application isn't > discarding what it got from the SM and winging it. The security > model doesn't "stand between the two" like you suggest. > I agree. An "SNMP application" makes the call to IsAccessAllowed, and the application gets the answer from the ACM. No other subsytem or model ever talks directly to an access control model. Access control in the RFC3411 architecture is deliberately **advisory** - it is up to the application to ask whether access is allowed, and the application can decide what to do with the answer. This was very deliberate. There is no binding between the IsAccessAllowed answer and the actual access to the underlying instrumentation. Even if IsAccessAllowed says "no", an application MAY still decide to access the underlying instrumentation. For a minimal device such as a printer that has only notifications such as "out of paper" and "out of ink", a specific SNMP application could be written that performs no access control, because the only notifications are not sensitive. A specific application in the same printer might accept an operation to clear the "out of XXX" status value, without performing access control. The working group discussed these specific cases, amongst others, when doing the architecture design. There is no architectural binding between an applications' use of ACM and the security model. Having the security check that this is the same securityName used for ACM would violate the modularity of the subsystems (and would disallow the minimal printer applications). On the other hand, specific standard applications MAY imply or require in their elements of procedure that the securityName is the same between the ACM and the SM. I think this is the case for the NO described in RFC3413 section 3.3, in paragraph (2). > 2) The initiating application (NG or CG) is the one that > actually tells > the remote side who it is when USM is used. More importantly, it > really says "we're both Bob; I can prove I'm Bob and > please prove you > are too when you send a response". The CR and NR merely use this > fact to look up the proper keying material to use to > ensure that they > can be Bob. > > tp> And as has been pointed out several times, when the NO originates > tp> the session, and the NO is the ssh client, then that > credential is a > tp> public key. > > The *client* credential is a public key. As is the servers. > > tp> So that is what the NO should be checking and what VACM > should have > tp> in its tables:-) I haven't hunted this one down, but I believe it is incorrect to state that an **ACM** should have authentication credentials in its tables. Authentication is the domain of a security model, so authentication credentials belong in the tables of a security model, as is done in RFC3414. The configuration of the tables of an application, such as an NO, might contain administratively-set pointers (such as the securityModel, securityName, securityLevel indices) to lookup the appropriate security credentials in the tables of the security model, to use for the notification target, as is done in RFC3413. I think it is inaccurate to refer to an NO as an ssh client. An NO does not do authentication or establish a transport connection; it specifies which securityModel and securityName and securityLevel should be used when authentication is performed, and which transport address is used when transport is established. The application should know nothing about the nature of the authentication credentials. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 13 20:43:07 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5E73A69C9; Tue, 13 May 2008 20:43:07 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C663A6950 for ; Tue, 13 May 2008 20:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pBQ7h-p1foq for ; Tue, 13 May 2008 20:43:03 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 78BCE3A69C9 for ; Tue, 13 May 2008 20:43:03 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id CF1DF2C41B3; Tue, 13 May 2008 20:42:21 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=g10oNbGhS7TK4YT03V4mvIn4iKo=; b=c04tibK/TwE1SR5EP+Jhqg4tDTF+9XNvhIDQ6xVCsPE/CQOpMRr7o8LAvqFFOz/H9v+GX5mN9rD2kM6HGfttW4iUIE7UW2FC23mQcVC6MqojIqrPajsOQSYxodIEp2z3n9NnbBBGv9BJY0wVYEYP7xZVrcdkfNksBR5tiLHXXvY= Received: by wes.hardakers.net (Postfix, from userid 274) id 6803B2C41B2; Tue, 13 May 2008 20:42:21 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> <029c01c8b519$721a5f80$0601a8c0@allison> <06b101c8b570$dccce800$0600a8c0@china.huawei.com> Date: Tue, 13 May 2008 20:42:20 -0700 In-Reply-To: <06b101c8b570$dccce800$0600a8c0@china.huawei.com> (David Harrington's message of "Tue, 13 May 2008 23:16:10 -0400") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Tue, 13 May 2008 23:16:10 -0400, "David Harrington" said: DH> There is no binding between the IsAccessAllowed answer and the actual DH> access to the underlying instrumentation. Even if IsAccessAllowed says DH> "no", an application MAY still decide to access the underlying DH> instrumentation. Good point that I forgot, thanks for catching it. DH> For a minimal device such as a printer that has only notifications DH> such as "out of paper" and "out of ink", a specific SNMP application DH> could be written that performs no access control, because the only DH> notifications are not sensitive. One might argue it's still performing it "architecturally"; it's just always returning "ok". DH> There is no architectural binding between an applications' use of ACM DH> and the security model. Having the security check that this is the DH> same securityName used for ACM would violate the modularity of the DH> subsystems (and would disallow the minimal printer applications). Actually there would be some security gain there that wouldn't break the applications you're talking about; but I won't dive into that here as it's out of scope. DH> On the other hand, specific standard applications MAY imply or require DH> in their elements of procedure that the securityName is the same DH> between the ACM and the SM. I think this is the case for the NO DH> described in RFC3413 section 3.3, in paragraph (2). I'd like to reword that before I agree with it: ... require in their elements of procedure that the securityName is the same between the ACM and the SM ^ output of Remember, I never said that the SM wasn't responsible for passing on the securityName. I only said that it could do it in a number of ways; one of which could be a lookup table for which the keys might be some other aspect of the packet/protocols involved (such as the keying material and possibly parameters passed to it via the application just as the USM user name to use is currently passed to it via the application). I did *not* ever state (or mean to imply) that the securityName chosen wouldn't be agreed to by the SM. Only how that mapping was done. >> 2) The initiating application (NG or CG) is the one that >> actually tells the remote side who it is when USM is used. More >> importantly, it really says "we're both Bob; I can prove I'm Bob and >> please prove you are too when you send a response". The CR and NR >> merely use this fact to look up the proper keying material to use to >> ensure that they can be Bob. DH> I haven't hunted this one down, but I believe it is incorrect to DH> state that an **ACM** should have authentication credentials in its DH> tables. I never meant to say that if I did, but I could see how you interpreted it that way. Specifically, the application does say "I'm Bob" and also specifies other parameters like "and my engineID for this message is XXX" but you're right, it's up to the SM to find the right key. I was, unfortunately, combining the SM and the application into "application" in the above statements and I do apologize for that. My bad. (I was thinking of the application has a whole, stack included, as I wrote the above not the "CG, CR, ..." type application above the stack). The SM does hold the "keys". DH> I think it is inaccurate to refer to an NO as an ssh client. Also true; the NO itself is not. For the NO to be useful it has to send the message out to the point where the SM and the transport deal with it and you're right, from an architectural standpoint it's the transport that is the client. However, I don't think my terminology blunders invalidate my points at least :-) -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 13 22:02:04 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5490E3A6830; Tue, 13 May 2008 22:02:04 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 245EA3A6955 for ; Tue, 13 May 2008 22:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J2OziyKVh-f for ; Tue, 13 May 2008 22:01:58 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 5F9013A6830 for ; Tue, 13 May 2008 22:01:58 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id RGxy1Z06j0FhH24A900500; Wed, 14 May 2008 05:01:30 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id RH1q1Z0034HwxpC8U00000; Wed, 14 May 2008 05:01:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=vbmy4N8V3Jlb8gKQr3oA:9 a=1sSLcak4bfhYzGg0N9QA:7 a=SbwNEDSQ54T8DC-Z_7262-rrmBMA:4 a=86L1PGDMzkIA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Wes Hardaker'" References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com><029c01c8b519$721a5f80$0601a8c0@allison><06b101c8b570$dccce800$0600a8c0@china.huawei.com> Date: Wed, 14 May 2008 01:01:50 -0400 Message-ID: <06c801c8b57f$9ff02a50$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aci1dKNDVNvZ9uKlR9ic4OTiFy67ZQAAIHCA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] [...] > > DH> On the other hand, specific standard applications MAY > imply or require > DH> in their elements of procedure that the securityName is the same > DH> between the ACM and the SM. I think this is the case for the NO > DH> described in RFC3413 section 3.3, in paragraph (2). > > I'd like to reword that before I agree with it: > > ... require in their elements of procedure that the > securityName is the same > between the ACM and the SM > ^ > output of Your rewording is incorrect because it presupposes this is an incoming message. RFC3413 section 3.3 is actually about Notification Originator Applications. In either direction, it is the design of the application that makes any binding between the securityName used for ACM and SM. For incoming, an application design MAY use the output of the SM when invoking the ACM. For outgoing, the application chooses the securityName, and the design MAY use the same one for both ACM and SM purposes. In the SNMPv3 WG, we worked to eliminate the explicit binding between a security model and an ACM. There were too many issues caused by (often-invalid) assumptions made by access control designs, about the "strength" of authentication, integrity, and confidentiality provided by different algorithms. These "strengths" could easily change over time, and the strength of algorithms depends too much on the environment to which they are being applied. The SNMPv3 approach differed from the earlier monolithic SNMPv2p, snmpv2u, and snmpv2* designs which had explicit sharing of information between the message security and access controls, including knowledge of the specific algorithms and credentials used. The SNMPv3 approach uses layered security. In SNMPv3, we broke the architecture into separate subsystems (layers, more or less). The security model provides message security at a lower layer than the using application; the interface to upper layers (the applications) only provides the model used, a human-readable handle for the principal authenticated, and an indication of security services provided. All information about the specifics of the algorithms or credentials used at lower layers is deliberately hidden from the upper layers. This approach permits algorithm agility, and eliminates assumptions about the strengths of different algorithms when configuring access controls. (The ACM does consider the expected strength of the security model.) > > Remember, I never said that the SM wasn't responsible for > passing on the > securityName. I only said that it could do it in a number of > ways; one > of which could be a lookup table for which the keys might be > some other > aspect of the packet/protocols involved (such as the keying > material and > possibly parameters passed to it via the application just as the USM > user name to use is currently passed to it via the application). I disagree with this. The application does not pass the USM user name to use; it passes the securityName to use, and the security model to use to determine how to translate the securityName to a security-model-specific credential. USM happens to use the securityname to lookup the corresponding USM user name in a table to determine the credentials. The application layer does not know how the lower-layer security model translates from securityName to an SM-specific credential (for outgoing) or how the lower-layer security model translates from an SM-specific credential to securityName (for incoming). > > I did *not* ever state (or mean to imply) that the securityName chosen > wouldn't be agreed to by the SM. Only how that mapping was done. > > >> 2) The initiating application (NG or CG) is the one that > >> actually tells the remote side who it is when USM is used. More > >> importantly, it really says "we're both Bob; I can prove > I'm Bob and > >> please prove you are too when you send a response". The CR and NR > >> merely use this fact to look up the proper keying material > to use to > >> ensure that they can be Bob. > > DH> I haven't hunted this one down, but I believe it is incorrect to > DH> state that an **ACM** should have authentication > credentials in its > DH> tables. > > I never meant to say that if I did, You didn't. Tom said the public key should be stored in VACM tables. You didn't seem to notice that. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 14 02:31:38 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C703A67D8; Wed, 14 May 2008 02:31:38 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B56B3A6854 for ; Wed, 14 May 2008 02:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCecTghM9ip0 for ; Wed, 14 May 2008 02:31:35 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 0D24E3A67A2 for ; Wed, 14 May 2008 02:31:30 -0700 (PDT) X-Trace: 115586166/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.139.84 X-SBRS: None X-RemoteIP: 62.188.139.84 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAEBNKkg+vItU/2dsb2JhbACLU6IrBA X-IronPort-AV: E=Sophos;i="4.27,485,1204502400"; d="scan'208";a="115586166" X-IP-Direction: IN Received: from 1cust84.tnt10.lnd4.gbr.da.uu.net (HELO allison) ([62.188.139.84]) by smtp.pipex.tiscali.co.uk with SMTP; 14 May 2008 10:30:27 +0100 Message-ID: <02a901c8b59c$2724ade0$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com><029c01c8b519$721a5f80$0601a8c0@allison> Date: Wed, 14 May 2008 10:14:51 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: "tom.petch" Cc: ; ; Sent: Tuesday, May 13, 2008 11:11 PM Subject: Re: [Isms] ISMS/SSH and notifications > >>>>> On Tue, 13 May 2008 16:32:18 +0200, "tom.petch" said: > > tp> The problem I see, which has been mulled over for some three years > tp> and Juergen articulated last month, is that access control in the NO > tp> checks that the NR is permitted to see the data in the notification > tp> based on the securityName. > > Correct. The VACM uses a securityName to make an access control > decision. The security model is responsible for determining that the > other side isn't "faking it". The security model (SM) is responsible > for mapping "something security-model specific" (paraphrasing the > architecture here) to a securityName that could be used "beyond that > point" (again, paraphrasing), like the application (NG, NO, CR, CG) for > example. The "beyond that point" apps trust the SM to have given it an > appropriate securityName. > > The question is, where does that name come from? There are three > potential places: > > 1) configuration > 2) somewhere in the packet > 3) somewhere in the security credentials > > Where it comes from only is tied together cryptographically if it's in > the keying material (#3) is chosen (keep reading to get comments on #2) > > tp> For that check to be of any value, then the name needs > tp> authenticating, which means that the NR should supply credentials > tp> for it. > > Not necessarily true. In a security model that didn't have a 1:1 > mapping from something in the packet to the securityName then the > security model has to *derive* the securityName to use. It does this > through a security model specific transformation (the SNMPv3 > architecture very wisely allowed for this possibly and discusses it in > various places). > > What, does a protocol which has no in-packet direct "note" saying "I'm > Bob" do? > > The choices (marker: ***) are: > > 1) throw up your hands and say "this protocol is useless". I don't buy > this option but apparently some are willing to just ditch SSH because > there is no magical 1:1 mapping transformation. > > 2) Use some other in-protocol field to "transform" into a security > name. This could be, for example, the SSH server name offered up > by the SSH server side of the protocol. This is one potential > solution out of this space. The securityName would be set to > "wjh.hardakers.net", for example, if a client was trying to connect > to my laptop. The issue will come, however, that the legal length > of a host name is longer than that of the legal securityName value > that is used to look up a VACM entry. > > 3) A configured mapping table. Something in the packet or in the > configuration that created the session could be used to look up, in > a configured lookup table, what the securityName should be based on > cryptographically proven (assuming at least authNoPriv) portions of > the packet. Like the server's SSH public key. > > Only public key *certificates* (note the added word) actually containing > identifying information in the certificate itself that says "I'm Bob, > and not only that if I alter this certificate saying I'm now Eve it > won't work". SSH doesn't operate this way; the application says "I'm > Bob and I'm using this key" but the key doesn't prove it. The keys only > prove that the application has the private key. It could still say > "Eve" and you can still only verify that eve has a private key you > recognize and potentially trust. The USM doesn't provide any assurance > that the keying material it uses is attached to a particular name as > well. Every user in the USM table could all be configured with the same > localized key so that Bob, Mary, Eve and Joe all could swap account > names and the far other side would do VACM checks on whatever name was > given to it in the packet regardless of the fact that they could have > picked from a few. That wouldn't be allowed with an X.509 cert, for > example, but would be with both SSH and USM. > > tp> So Wes is right to say that VACM is not responsible for checking it > tp> but I think wrong to say that it is ok to take whatever the > tp> application gives it. The security model should stand between the > tp> two and check that the secure transport ends at something with that > tp> name and with verified security credentials (as USM does). > > No, actually the USM doesn't do this. A couple of problems exist in > this logic: > > 1) The security model hands the securityName back to the application and > says "I got this message from this dude named 'Bob'". The > application already takes the value 'Bob' and can change it to > whatever it wants before handing it to the VACM. There is no > security check in the architecture today that the application isn't > discarding what it got from the SM and winging it. The security > model doesn't "stand between the two" like you suggest. > > (a historic aside: there was actually an alternate SNMPv3 architecture > ID that attempted to allow the SM and the ACM blocks to communicate > so that the ACM could verify wit the SM that the application wasn't > lying to it, but it never got published. I was even part of a team > that did a reference implementation of it that really showed you have > to have the SM and the ACM blocks be memory protected from the > application for it to actually be an effective security mitigation > and no SNMP stack these days really supports that separation). > > 2) The initiating application (NG or CG) is the one that actually tells > the remote side who it is when USM is used. More importantly, it > really says "we're both Bob; I can prove I'm Bob and please prove you > are too when you send a response". The CR and NR merely use this > fact to look up the proper keying material to use to ensure that they > can be Bob. > > tp> And as has been pointed out several times, when the NO originates > tp> the session, and the NO is the ssh client, then that credential is a > tp> public key. > > The *client* credential is a public key. As is the servers. > > tp> So that is what the NO should be checking and what VACM should have > tp> in its tables:-) > > Right, that's actually what I said. You could use the server's key to > do a lookup in a table to ensure you're talking to Bob. If they say I > have key 0xABCD and you have "Bob" next to 0xABCD in your keying table, > then you can be completely sure it's "Bob" at the other end. > > The only two forward paths that exist are #2 and #3 from *** above. I'm > honestly happy with either, though #2 (using the SSH server host name as > the securityName) would limit the hostnames I can use but, and this is > my important point, it doesn't provide me with any extra security over > #3 (using a mapping table so the key would be used to lookup the value > of the securityName to use). A lookup would be done in the process of > sending a trap. The configuration would specify the remote securityName > and the public key of the remote server to verify it's the right > securityName on the other side. > > Cryptographically speaking, you still don't have any assurance that the > application hasn't messed with the data before the VACM uses it nor do > you have any assurance that the public key in use wasn't intended to be > used by a completely different name. Yes, I agree. I am left wondering, more with the second point than the first, if this is good enough security and thinking that perhaps it is not. I see this as the crux of the issue. In passing, SSH (unlike TLS) does have a ready made session identifier that is cryptographically bound to the session so if we do take data from the session setup for use in the ways you describe, then that is what I think we should use (see draft-williams-sshv2-channel-bindings-00.txt) Tom Petch > You still can be completely > assured that whoever is listening on the other side, be it Bob or Eve, > could convenience you that they're both Bob and Eve or whatever name you > want them to be. They have the private key to prove it and that's all > you can care about. > > -- > Wes Hardaker > Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 14 02:31:38 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1DD3A68BC; Wed, 14 May 2008 02:31:38 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC993A67A2 for ; Wed, 14 May 2008 02:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S56KKXI5yOU for ; Wed, 14 May 2008 02:31:35 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id EFB863A67D8 for ; Wed, 14 May 2008 02:31:31 -0700 (PDT) X-Trace: 115586225/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.139.84 X-SBRS: None X-RemoteIP: 62.188.139.84 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAEBNKkg+vItU/2dsb2JhbACLU6IrBA X-IronPort-AV: E=Sophos;i="4.27,485,1204502400"; d="scan'208";a="115586225" X-IP-Direction: IN Received: from 1cust84.tnt10.lnd4.gbr.da.uu.net (HELO allison) ([62.188.139.84]) by smtp.pipex.tiscali.co.uk with SMTP; 14 May 2008 10:30:30 +0100 Message-ID: <02aa01c8b59c$28c6c520$0601a8c0@allison> From: "tom.petch" To: "Wes Hardaker" , "David Harrington" References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com><029c01c8b519$721a5f80$0601a8c0@allison><06b101c8b570$dccce800$0600a8c0@china.huawei.com> Date: Wed, 14 May 2008 10:23:08 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Incidentally I am using Notification Originator rather than Notification Generator but I think we understand each other. Tom Petch ----- Original Message ----- From: "Wes Hardaker" To: "David Harrington" Cc: "'Wes Hardaker'" ; "'tom.petch'" ; Sent: Wednesday, May 14, 2008 5:42 AM Subject: Re: [Isms] ISMS/SSH and notifications > >>>>> On Tue, 13 May 2008 23:16:10 -0400, "David Harrington" said: > > DH> There is no binding between the IsAccessAllowed answer and the actual > DH> access to the underlying instrumentation. Even if IsAccessAllowed says > DH> "no", an application MAY still decide to access the underlying > DH> instrumentation. > > Good point that I forgot, thanks for catching it. Yes, I agree that there is no binding but ... > > DH> For a minimal device such as a printer that has only notifications > DH> such as "out of paper" and "out of ink", a specific SNMP application > DH> could be written that performs no access control, because the only > DH> notifications are not sensitive. > > One might argue it's still performing it "architecturally"; it's just > always returning "ok". > > DH> There is no architectural binding between an applications' use of ACM > DH> and the security model. Having the security check that this is the > DH> same securityName used for ACM would violate the modularity of the > DH> subsystems (and would disallow the minimal printer applications). > > Actually there would be some security gain there that wouldn't break the > applications you're talking about; but I won't dive into that here as > it's out of scope. > > DH> On the other hand, specific standard applications MAY imply or require > DH> in their elements of procedure that the securityName is the same > DH> between the ACM and the SM. I think this is the case for the NO > DH> described in RFC3413 section 3.3, in paragraph (2). > yes, that is my thinking too so while there is no binding, there is some linkage, I - we? - do expect there to be one common securityName for the'transaction'. > I'd like to reword that before I agree with it: > > ... require in their elements of procedure that the securityName is the same > between the ACM and the SM > ^ > output of > > Remember, I never said that the SM wasn't responsible for passing on the > securityName. I only said that it could do it in a number of ways; one > of which could be a lookup table for which the keys might be some other > aspect of the packet/protocols involved (such as the keying material and > possibly parameters passed to it via the application just as the USM > user name to use is currently passed to it via the application). > > I did *not* ever state (or mean to imply) that the securityName chosen > wouldn't be agreed to by the SM. Only how that mapping was done. > > >> 2) The initiating application (NG or CG) is the one that > >> actually tells the remote side who it is when USM is used. More > >> importantly, it really says "we're both Bob; I can prove I'm Bob and > >> please prove you are too when you send a response". The CR and NR > >> merely use this fact to look up the proper keying material to use to > >> ensure that they can be Bob. > > DH> I haven't hunted this one down, but I believe it is incorrect to > DH> state that an **ACM** should have authentication credentials in its > DH> tables. > > I never meant to say that if I did, but I could see how you interpreted > it that way. Specifically, the application does say "I'm Bob" and also > specifies other parameters like "and my engineID for this message is > XXX" but you're right, it's up to the SM to find the right key. I was suggesting, somewhat tongue in cheek:-), that the public key would be in the tables because that is the identity, as well as the security credentials As you imply, with certificates (as in TLS), then there is a clear separation of the identity (host name, MAC address, IP address etc) and the credentials that authenticate the assertion thereof. With just a public key, then that is in a sense doing double duty, as identity and authentication thereof. You could say that the private key is the credential or that a message encrypted with the private key is or .... Whatever, what is comes down to we do not have a satisfactory identity for the ssh host, one that we can authenticate. > > I was, unfortunately, combining the SM and the application into > "application" in the above statements and I do apologize for that. My > bad. (I was thinking of the application has a whole, stack included, as > I wrote the above not the "CG, CR, ..." type application above the stack). > The SM does hold the "keys". > > DH> I think it is inaccurate to refer to an NO as an ssh client. Yes, I should have said something like ' the engine on which the NO runs as ssh client'. My point was really that if the engine on which the NO runs becomes the ssh server, then, as emerged in the interim meeting some time ago, life is simpler; this is my preferred option. Tom Petch > > Also true; the NO itself is not. For the NO to be useful it has to send > the message out to the point where the SM and the transport deal with it > and you're right, from an architectural standpoint it's the transport > that is the client. > > However, I don't think my terminology blunders invalidate my points at > least :-) > > -- > Wes Hardaker > Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 14 10:02:59 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17E53A67DD; Wed, 14 May 2008 10:02:58 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98CCB3A67DD for ; Wed, 14 May 2008 10:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJT9gz6cQDc2 for ; Wed, 14 May 2008 10:02:25 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id DAF493A67A8 for ; Wed, 14 May 2008 10:02:24 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id EA7CB2C41B3; Wed, 14 May 2008 09:59:42 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=w31Tr6HamxNxoNFKwyjIh/XkwjY=; b=dj1fsJLe73T8G0y69R7SuJlu15OjtIedUGXVkIHB+sqA7ml7Ud0rz9h3YWtLwObS6ajk1xxercjn+IiRNuzEYWucU0Q3QyzTjDYdskO3E3h3+Hw55hhgtqQR6vDF8tubjRkzPmdevGgIYEEVQJ6fr1xmMEm95B6lhXEZhpwebE4= Received: by wes.hardakers.net (Postfix, from userid 274) id CAB572C41B2; Wed, 14 May 2008 09:59:42 -0700 (PDT) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> <029c01c8b519$721a5f80$0601a8c0@allison> Date: Wed, 14 May 2008 09:59:42 -0700 In-Reply-To: (Jeffrey Hutzelman's message of "Wed, 14 May 2008 12:02:35 -0400") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 14 May 2008 12:02:35 -0400, Jeffrey Hutzelman said: JH> Please drop right now any notion that SNMP should track, identify, or JH> authorize any engine based on SSH public keys. I never said that directly (well, I probably implied it). What I said was that the client has to know the credentials of the other side in order to protect against mitm attacks. The client will have to specify somehow which remote authentication mechanisms and credentials are trusted. To not do this would be to blindly allow ssh to always perform a leap of faith which is very insecure and prone to mitm issues. JH> To do so would be a serious abstraction violation and would defeat JH> or seriously impair the purpose of ISMS, which is to allow operators JH> to authenticate SNMP using their existing infrastructure. This may well be done through existing known hosts and key material. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 14 10:05:30 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A343A686E; Wed, 14 May 2008 10:05:17 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DB23A68A8 for ; Wed, 14 May 2008 10:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8eH2tTXhQLN for ; Wed, 14 May 2008 10:04:16 -0700 (PDT) Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by core3.amsl.com (Postfix) with ESMTP id 248963A67A8 for ; Wed, 14 May 2008 10:04:16 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m4EG2Z3v009645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2008 12:02:35 -0400 (EDT) Date: Wed, 14 May 2008 12:02:35 -0400 From: Jeffrey Hutzelman To: Wes Hardaker , "tom.petch" Message-ID: In-Reply-To: References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> <029c01c8b519$721a5f80$0601a8c0@allison> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Tuesday, May 13, 2008 02:11:50 PM -0700 Wes Hardaker wrote: >>>>>> On Tue, 13 May 2008 16:32:18 +0200, "tom.petch" >>>>>> said: > tp> And as has been pointed out several times, when the NO originates > tp> the session, and the NO is the ssh client, then that credential is a > tp> public key. > > The *client* credential is a public key. As is the servers. Not necessarily. SSH supports key exchange methods in which the server is authenticated by a mechanism other than a public key, as well as methods in which public key crypto is used, but the server is not identified by a specific public key. It also supports a wide range of user authentication methods which are not based on public keys. Please drop right now any notion that SNMP should track, identify, or authorize any engine based on SSH public keys. To do so would be a serious abstraction violation and would defeat or seriously impair the purpose of ISMS, which is to allow operators to authenticate SNMP using their existing infrastructure. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 14 10:45:31 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1A528C100; Wed, 14 May 2008 10:45:31 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34E528C100 for ; Wed, 14 May 2008 10:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mnWy9aTwY3C for ; Wed, 14 May 2008 10:45:28 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id B86DA28C0FB for ; Wed, 14 May 2008 10:45:25 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 045B92C41B3; Wed, 14 May 2008 10:34:42 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=wsW2BC6HhdAKGWPyFW4tARwl7YE=; b=Y6YA+qaeLQN2M7D4d+xmkQgc58Ekhe6eTkq4Y59B9XUDJtGEXOFKCLMdkvZfe6w3S6uZuUXcu8nTKqz/mM/hUuQpyS/vi1z+k1HB7jWDuG6Q5L2qudLtyI3/g+PhOzW6fkw5k7iIF7XyAbcFrJ8R79+R0fnj8bquoKaJYe+pO8s= Received: by wes.hardakers.net (Postfix, from userid 274) id D95BA2C41B2; Wed, 14 May 2008 10:34:41 -0700 (PDT) From: Wes Hardaker To: "tom.petch" Organization: Sparta References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> <029c01c8b519$721a5f80$0601a8c0@allison> <06b101c8b570$dccce800$0600a8c0@china.huawei.com> <02aa01c8b59c$28c6c520$0601a8c0@allison> Date: Wed, 14 May 2008 10:34:41 -0700 In-Reply-To: <02aa01c8b59c$28c6c520$0601a8c0@allison> (tom petch's message of "Wed, 14 May 2008 10:23:08 +0200") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 14 May 2008 10:23:08 +0200, "tom.petch" said: tp> yes, that is my thinking too so while there is no binding, there is some tp> linkage, I - we? - do expect there to be one common securityName for tp> the'transaction'. I would argue that for a symmetric cryptography using SM like USM we'd expect them to be the same. I don't necessarily think that's true for an asymmetric system like any public/private key system. What we use to identify ourselves as the "client" will be differently named than what we use to identify the remote side. Naming wise, no, I don't think they need to be the same (since it doesn't buy you anything). As a client I may be configured to be "wes" but I'm not expecting to talk to "wes" at the other end. I'm expecting to talk to "bob". Most importantly, I'm expecting to talk to another transport end that meets my security requirements for proof of identity requirements. SSH proves that sufficiently for me to trust it. Thus I can choose to call the remote side "bob" (or "wes" too if you really wanted to) as long as the more important aspect is still true: they've cryptographically shown me I've connected to the right place given the message I want to send. I honestly don't care about the name; I care about the cryptography. tp> Whatever, what is comes down to we do not have a satisfactory tp> identity for the ssh host, one that we can authenticate. I'm saying you do. You can all it whatever you want. Specifically, you can use the name you assigned it when you are pointing to your local configuration that says "use this SSH transport to talk to the remote side". The important security bits that MUST be agreed upon have been taken care of by the SSH layer. I don't see any benefit to throwing up your hands and declaring the whole thing off just because SSH doesn't offer an adequate securityName for the server side of the connection. Either pull it from the configuration that specified the session in the first place or pull it from the SSH system's configuration, such as the offered host name. This exact problem is likely to bite us with many public/private type transport layers. Somehow I think we'd rather figure out a workable solution than throw up our hands and declare that USM is better. Clearly that's been shown that it isn't in the terms of the people using the systems. tp> My point was really that if the engine on which the NO runs becomes tp> the ssh server, then, as emerged in the interim meeting some time tp> ago, life is simpler; this is my preferred option. That may be an adequate solution too, but the transport doesn't work that way if the NO needs to open the session. And I don't think any solution that requires a management connection first as the only way to deliver a notification is a suitable one for all environments. (I have no objection to allowing a reverse mapping so the manager needs to connect; in fact I've even discussed MIB objects that would be required to support that) -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu May 15 11:16:28 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8033328C10B; Thu, 15 May 2008 11:16:28 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A20528C10B for ; Thu, 15 May 2008 11:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfOvavNnXOzF for ; Thu, 15 May 2008 11:16:25 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7D13A67B6 for ; Thu, 15 May 2008 11:16:25 -0700 (PDT) X-Trace: 27993157/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.139.26 X-SBRS: None X-RemoteIP: 62.188.139.26 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEABAaLEg+vIsa/2dsb2JhbACLWKNXAw X-IronPort-AV: E=Sophos;i="4.27,492,1204502400"; d="scan'208";a="27993157" X-IP-Direction: IN Received: from 1cust26.tnt10.lnd4.gbr.da.uu.net (HELO allison) ([62.188.139.26]) by smtp.pipex.tiscali.co.uk with SMTP; 15 May 2008 19:15:47 +0100 Message-ID: <005301c8b6ae$b44effa0$0601a8c0@allison> From: "tom.petch" To: "Jeffrey Hutzelman" , "Wes Hardaker" References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com> <029c01c8b519$721a5f80$0601a8c0@allison> Date: Thu, 15 May 2008 18:52:57 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "Jeffrey Hutzelman" To: "Wes Hardaker" ; "tom.petch" Cc: ; Sent: Wednesday, May 14, 2008 6:02 PM Subject: Re: [Isms] ISMS/SSH and notifications > --On Tuesday, May 13, 2008 02:11:50 PM -0700 Wes Hardaker > wrote: > > >>>>>> On Tue, 13 May 2008 16:32:18 +0200, "tom.petch" > >>>>>> said: > > tp> And as has been pointed out several times, when the NO originates > > tp> the session, and the NO is the ssh client, then that credential is a > > tp> public key. > > > > The *client* credential is a public key. As is the servers. > > Not necessarily. SSH supports key exchange methods in which the server is > authenticated by a mechanism other than a public key, as well as methods in > which public key crypto is used, but the server is not identified by a > specific public key. It also supports a wide range of user authentication > methods which are not based on public keys. > > Please drop right now any notion that SNMP should track, identify, or > authorize any engine based on SSH public keys. To do so would be a serious > abstraction violation and would defeat or seriously impair the purpose of > ISMS, which is to allow operators to authenticate SNMP using their existing > infrastructure. I disagree; if the only way we have of identifying the ssh server, somewhere on which a Notification Receiver is running, is a public key, and if the use of public keys is sufficiently widespread to make this viable, then it is an option we should seriously consider. I do not agree with Wes's first option (give up:-), do not see any attractive option but do believe we should find an option and move on. Tom Petch > > -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu May 15 13:15:29 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37CF3A67B6; Thu, 15 May 2008 13:15:29 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE763A6895 for ; Thu, 15 May 2008 13:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gevELQpWfqwr for ; Thu, 15 May 2008 13:15:24 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 80D673A67A3 for ; Thu, 15 May 2008 13:15:24 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id RwBX1Z00f1HpZEsA200Z00; Thu, 15 May 2008 20:15:19 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id RwDk1Z0064HwxpC8a00000; Thu, 15 May 2008 20:13:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=FebX0nPN77Dr2AL9Rw8A:9 a=5baiIJemJYtGUxVM15YA:7 a=Y5KSLNIu9-jeATctBe4XIaduxW4A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: , , References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> Date: Thu, 15 May 2008 16:13:44 -0400 Message-ID: <07c501c8b6c8$2eb1ae50$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com> Thread-Index: Acir6gqqKzbn8lY6QbmF2iiGPJaVsAARti1gAqQzt3A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I think this discussion has gotten off-track because there are some invalid assumptions floating around, due to using the terms loosely and not keeping the interfaces in mind. I will correct a couple here. I will correct others in other emails. > > 3. VACM Authorization > > > > Here's where the important note discussed above comes into play: the > > VACM doesn't care how the securityName passed to it was derived and > > authenticated. It's not the job of the VACM to do that. It trusts > > the CR and NG engines to have done the right thing security wise. Actually, that is not quite true. It is true that VACM does not care which algorithm within a security model was used to perform authentication, but it does care which securitymodel was invoked to do the job. There is a big difference between the community security model, the USM security model, and the TSM security model, so there may be a big difference between community/dbh, USM/dbh, and TSM/sbh. The IsAccessAllowed() ASI passes certain values, and it is expected that those values will somehow be used to index the access control tables. As with almost everything in SNMPv3, it is expected that securityModel, securityName, and securitylevel are likely to be used as indices to security information, and contexts and OIDs will be used to reference data subsets. statusInformation = -- success or errorIndication isAccessAllowed( IN securityModel -- Security Model in use IN securityName -- principal who wants to access IN securityLevel -- Level of Security IN viewType -- read, write, or notify view IN contextName -- context containing variableName IN variableName -- OID for the managed object ) -- I have concerns that Wes's email was misleading about how the target table and parameters table are used. Please look at Appendix A in the TSM document to see how the values from these tables are used by TSM. Wes's email does not follow the Appendix, and fills in some fields incorrectly, like roughly specifying a transport model (SNMP/SSH) where an explicit securityModel enumeration is definitely called for. To repeat myself: as with almost everything in SNMPv3, it is expected that securityModel, securityName, and securitylevel are likely to be used as indices to security information. The securityModel/Name/Level tuple will be needed to index into other tables as the processs goes through the elements of procedure. -- I think we will get into trouble if we keep talking about the NG and NR doing security and transport things. The NG (actually it should be NO) and the NR are applications. Transport model processing should not be aware of what the operation is, because it only gets the wholeMsg already formed, and possibly with the PDU encrypted by the security model; the modularity of SNMPv3 means the transport model does know what operation the message contains, and it should never look into the PDU. It is an RFC3411-architectural-layer violation to have the transport model know the operation type. I know Wes's implementation may not follow the architectural layering of the standard, but RFC3411 is the standard, and should abide by it in our designs, or explicitly (not by sloppiness) re-architect SNMP. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu May 15 14:34:22 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135653A69C1; Thu, 15 May 2008 14:34:22 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E126F3A681B for ; Thu, 15 May 2008 14:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLnxO6s51jK0 for ; Thu, 15 May 2008 14:34:17 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 220223A67C1 for ; Thu, 15 May 2008 14:34:17 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id RwDE1Z0070b6N64AA08a00; Thu, 15 May 2008 21:34:11 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id Rxa81Z0094HwxpC8P00000; Thu, 15 May 2008 21:34:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=FTDfflV0hByC_2p6fbgA:9 a=RHPJTAeYye3sJcvjkUoA:7 a=5xh7kyNtbo5uvMR10rRv2hd1B84A:4 a=Qd4WOhwIQFcA:10 a=noOez8b8FOgA:10 a=6rJ49o1g-3kA:10 a=8nNKBKeDaW0A:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Wes Hardaker'" , References: Date: Thu, 15 May 2008 17:34:08 -0400 Message-ID: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acir6hmVy3ZUdaUvRT6mENS3EiZoJQKBBnLA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I think the starting point of this discussion has some incorrect assumptions and that could be causing some problems, so I would like to correct some of the starting point for configuration. I am paying close attention to the layering called for by the architecture, because it is important to correctly understanding how things get done. The TSM describes how to work with the ParamsTable and the TargetTable in Appendix A of the TSM document. Wes's examples showed other values. snmpTargetParamsSecurityModel would not be configured with (SNMP/SSH Mapping). It should be configured with the securitymodel to be used, not the transport model to be used. The securityModel to work with our SSH design should be the TransportSecurityModel (TSM). This is a really important thing to know because it is the securitymodel specified in snmpTargetParamsSecurityModel that knows how to take the securityModel and securityLevel specified in snmpTargetParamsSecurityName and snmpTargetParamsSecurityLevel and map them to the appropriate security credentials. The Transport Security Model will determine from the transportDomain (which should have a value of snmpSSHDomain) that the SSH transport model should be used. For an outgoing message, it will check for an existing securityStateReference. If the application is requesting that a notification be sent, there will not be an existing securityStateReference (which are used to ensure responses have the same security as the request). The TSM will create a tmStateReference (the structure used to pass info between the SM and the TM), and put in the securityName and securityLevel. Then it will create the wholeMmessage from the parts provided by the MPM and a zeroed-out securityParameter field, and give that back to the MPM. The MPM will pass the request to send the wholeMsg to the specified transport address (and pass along the tmStateReference). Note that up to this point, nobody has looked to see if there is an existing connection. That's important because it is not their job to do so. The six step process described in Wes's example is wrong for that reason. The TM (in this case the SSH-TM) will take the address provided by the MPM, plus the securityName and Level, and determine how to convert that into SSH parameters. Then it will check whether a connection exists that matches those parameters. It does this in an implementation-dependent manner, but it probably uses the address and the securityname and the securityLevel to see if the local configuration datastore has a record of such an existing connection. It is implementation-dependent whether it checks an SNMP datastore (a MIB) or an SSH datastore (such as a ./ssh_config and an ssh_keys directory). Maybe it doesn't check at all, but simply says "hey SSH, send this for me, will you? and SSH finds an existing connection, or establishes a new connection, and sends the message, or the SSH layer returns an error. A lot is going to depend on the APIs provided by the SSH implementation one is using. The really important part here is that the application knows nothing of the transport processing except the address and domain, or the security processing except the Model/Name/Level. The security model knows nothing of the transport-specific processing, and the MPM knows nothing of the transport-specific processing. Only the transport model really knows about the processing for that transport. And if the transport layer (SSH) is providing the authentication, then only the transport layer really know what processing occurs to do that authentication. Only SSH knows whether authentication was done using public keys or passwords or certificates or whatever. Now, if we want to store client credentials locally so we have the necessary credentials to initiate an SSH session for notifications when no connection is available, we can define a standardized datastore to put that into (define an SSHTM-specific MIB as part of the transport model). But before we decide the WG should do this we should see if the SSH configuration datastore already has a mechanism for storing such credentials, such as an ssh_keys directory. We should also be careful to separate the SSH-MIB from the SSHTM-MIB, since having an SSH-MIB would allow SSH used for other purposes to be managed as well. So can we reach consensus that the issue we need to deal with is not the TARGET-TABLE or PARAMS-TABLE, and not the application or the security model? We should be talking about how the SSH-TM talks to an underlying SSH implementation (whichever one that happens to be) in a standardized manner, including implementation-dependent magic. We also need to figure out how to bridge the gap from what we have for info (securityName and Level and transport domain and address) to what SSH needs to initate an outgoing connection. And we need to consider, for incoming messages, how we get from what SSH has (user names, host keys, or whatever) to what we need to pass up the stack (securityName and Level and transport domain and address). Personally, I think we need to identify the securityModel that the TM expects will process the provided securityName and Level, rather than leave it to the MPM to decide which SM to use, but we can discuss that again later. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Thursday, May 01, 2008 8:17 PM > To: isms@ietf.org > Subject: [Isms] ISMS/SSH and notifications > > > The following is based on the message I sent out in January > in 2007 and > then later modified in July of 2007. I've now modified it for a third > time to fix some errors I found in it and have lengthened some of the > sections to talk more about the issues recently discussed here. > > I didn't know which email was the best to reply to in the current > thread, so I gave up and started a new Subject: :-) > > (previous posting for anyone that wants to compare changes: > http://www.ietf.org/mail-archive/web/isms/current/msg02097.html > ) > > This is *long* but hopefully clear. Please read the entire document > before responding to bits in the top; it's not a complete set > of thouhts > without reading the whole thing (sorry). Hopefully it'll be helpful, > however. The VACM discussion in section 3 is entirely new. > > This is all about sending notifications over SNMP/SSH and the usable > authentication mechanisms. It's been edited heavily for improved > readability and usability. I can probably be coerced into further > formalizing the writing for suitable inclusion into the > resulting draft > assuming the description below is sufficient for forward progress. > > Note: I have not trolled through all the docs to make sure everything > below is 100% accurate and secure. Think of it as a white-board > diagram not an end-specification. > > 1.0 Background > > 1.1 Terminology > > Politically correct SNMP terms: > > CG = command generator > CR = command responder > NG = notification generator > NR = notification responder > > SSH terms: > > LoF = Leap of Faith > > 1.2 Basic Notification Configuration > > The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB already allow for > configuration of notification receivers destinations to which > notifications should be sent. The following examples depict > possible configuration of this setup using a USM configuration. > > snmpTargetParamsTable row: > snmpTargetParamsName toNR > (administrative string) > snmpTargetParamsMPModel 3 (SNMPv3) > * snmpTargetParamsSecurityModel 3 (USM) > * snmpTargetParamsSecurityName usmUser (The USM user name) > snmpTargetParamsSecurityLevel 3 (auth|encr) > snmpTargetParamsStorageType 3 (nonVolatile) > snmpTargetParamsRowStatus 4 (createAndGo) > > snmpTargetAddrTable row: > snmpTargetAddrName toNRAddr > (arbitrary string) > snmpTargetAddrTDomain snmpUDPDomain > snmpTargetAddrTAddress 0x0A00000100A2 (NR > address, port) > snmpTargetAddrTimeout 1500 (in .01 sec) > snmpTargetAddrRetryCount 3 > snmpTargetAddrTagList toNRTag > snmpTargetAddrParams toNR (must > match prev table) > snmpTargetAddrStorageType 3 (nonVolatile) > snmpTargetAddrColumnStatus 4 (createAndGo) > > > snmpNotifyTable row: > snmpNotifyName NRNotif > (arbitrary string) > snmpNotifyTag toNRTag > (matches tag list above) > snmpNotifyType 2 (inform) > snmpNotifyStorageType 3 (nonVolatile) > snmpNotifyColumnStatus 4 (createAndGo) > > > The above will configure an agent to act as a NG and send informs to > the NR at 10.0.0.1 port 162 using the SNMPv3/USM user "usmUser". > The configuration for the "usmUser" settings in the > SNMP-USER-BASED-SM-MIB and SNMP-VIEW-BASED-ACM-MIB objects are not > shown here for brevity. The columns marked with a "*" are the items > that are USM specific. > > We'll refer back in later sections about how this changes when using > SNMP/SSH. > > An important point: the agent already needs configuration to be able > to send notifications regardless if ssh is the transport or > it's not. > > 1.3 Basic VACM Configuration > > The workings of the VACM is fortunately more widely understood, so I > won't break it out in detail here. The important thing to do know > from a notification point of view is that the only thing the VACM > needs to check is "am I allowed to send this notification". It does > that through the use of a securityName (and model and > level) given to > it by the NG. It doesn't care where that securityName came from nor > how it was technically authenticated. It completely trusts > the caller > to not have lied to it and it's the callers responsibility to have > checked the authenticity of the values. > > Here's the important key point: the VACM does not verify that the > other end is actually who they say they are. It's not the > VACMs job. > We'll need this later. > > 2.0 Notification Generation by a Notification Responder > > Notification Generators (NGs) need to send notifications to > management > stations acting as a Notification Responders (NRs). There are three > possibilities for how this might be done depending on the current > SNMP/SSH sessions available for use and the directionality > associated > with them. > > Section 2.1 describes 2 authentication mechanism procedures for how > a Notification Generator would open and authenticate a SNMP/SSH > connection to a Notification Receiver. > > Section 2.2 describes how a Notification Receiver can open a > connection (or more than one) to the Notification Generator and > configure it to send notifications over an existing connection. > > 2.1 A Notification Generator Opening a SNMP/SSH Connection to the > Notification Responder > > There are a number of interesting issues with how to do the case > where a Notification Generator needs to open a connection to the > Notification Receiver. The hardest issue with this has been > authentication mechanism to authenticate the NG at the NR side. > Additionally, the NR must be authenticated at the NG side and the > NG must properly check VACM settings to ensure each notification > sent to the NR is authorized. > > 2.1.1 Authentication Using a User Credential > > Devices could be configured with user credentials (EG, a user name > and the user's public-key or password) to use when connecting to a > NR. This would make use of the normal user-to-host mode of > operation of SSH. > > Steps to send the notification (this is a very terse > description of > what happens when you combine SSH and SNMP for notifications; it's > obviously a bit more complex as there are more steps > involved; this > is just a high level summary): > > 1) The NG would open a SNMP/SSH connection as an SSH > Client to the > NR acting as a SSH server. > > 2) The NR would send it's public (host) key and proof > of ownership > > 3) The NG would verify that it was talking to the > expected NR (by > verifying the public key against the proof and by verifying > that the public key presented matched the expected public key > for that destination; see below). > > 4) The NG would transmit it's user name and it's own SSH > authentication credentials (either the a public key, > and proof > or a password). > > 5) The NR would verify the authenticity of the received > credentials. > > 6) The NG would send the notification through the established > connection. > > The configuration pieces missing that are not currently available > in any modern MIBs at this time: > > 1) The ability to indicate that ISMS/SSH should be used as the > transport. > > EG: "Send a copy of the notification to host H using > SSH to port P" > > 2) The Ability to specify the SSH user credential type to use > (eg, public key or password) > > EG: "I'm 'Adam'" > > 3) The ability to configure that public-key or password > > EG: "I can prove I'm joe because I have the super secret > password or can prove I have the needed private key" > > 4) end-destination expected public SSH host-key > > - the public key of the NR acting as an SSH Server > that the NG > acting as a SSH Client should be connecting to. > > EG: "Now prove to me that you're Bob so I know that > you're not > Eve" > > Note one security risk that needs to be mentioned about the above: > > 1) Username/password combinations are horrible things > to use. SSH > allows for it but in order to use it securely in order to > prevent agent configuration theft compromising an entire > network (see USM Key Localization) you'd have to use a > different username/password configured into each agent. That > doesn't scale wonderfully from a configuration point of view. > Thus public/private keys should be used instead (of course). > I'm not going to get into the debate here about whether we > should support/allow username/password configuration for > sending something). > > 2.1.1.1 Changes to the TARGET-MIB configuration > > This would result in notification destination parameter > configuration that looked like (the settings explained next): > > snmpTargetParamsTable row: > snmpTargetParamsName toNR > (administrative string) > snmpTargetParamsMPModel 3 (SNMPv3) > * snmpTargetParamsSecurityModel 4 > (SNMP/SSH mapping) > * snmpTargetParamsSecurityName sshParams (The SSH > parameter name) > snmpTargetParamsSecurityLevel 3 (auth|encr) > snmpTargetParamsStorageType 3 (nonVolatile) > snmpTargetParamsRowStatus 4 (createAndGo) > > snmpTargetAddrTable row: > snmpTargetAddrName toNRAddr > (arbitrary string) > + snmpTargetAddrTDomain snmpTCPDomain > ++ snmpTargetAddrTAddress 0x0A00000100A2 (NR > address, port) > snmpTargetAddrTimeout 1500 (in > .01 sec) > snmpTargetAddrRetryCount 3 > snmpTargetAddrTagList toNRTag > snmpTargetAddrParams toNR > (must match prev) > snmpTargetAddrStorageType 3 > (nonVolatile) > snmpTargetAddrColumnStatus 4 > (createAndGo) > > > * = changed since previous example. > + = may change to snmpSSHDomain? subject to debate > (the security model already indicates SSH but if we want a v1 > or v2c security model then we'll need to use a snmpSSHDomain > instead; I think this is likely at this point) > ++ = shown as same but will likely change > (likely a new port number from IANA) > > Because we need 4 configuration settings (1-4 above) and > there is no > room in the existing tables for some of that information (config > setting #1 (use SSH) was done in the snmpTargetParamsSecurityModel > and/or snmpTargetAddrTDomain), we'll need to create > another table to > contain the other 3 needed settings. I'll call this the > snmpSSHParametersTable and it will contain the following > information: > > snmpSSHParametersTable: > > index: > snmpSSHParameterName sshParams (matches > 2nd * above) > > columns: > snmpSSHUserName Adam (the NG > says "I'm Adam") > snmpSSHUserCredentialType 1 (1 = > userPublicKey, > 2 = > userPassword, > 3 = > hostPublicKey > ... enum list) > snmpSSHNGUserKey +++ (the > expected NG Key if 1) > snmpSSHNGUserPass ++++ (the > passphrase to > use if 2) > snmpSSHNRHostKey +++ (the public key > > expected from the > expected NR) > > +++ = potential issue with config via SNMP/UDP since these are > potentially larger than SNMP/UDP would like. > ++++ = a GET should return "" at all times? > > With all of this in place it is possible for a NG to open a > connection to a NR and authenticate itself and verify the other > end is the expected end. Note that we still haven't > discussed user > names; be patient! > > It is implementation dependent how the NR decides whether to > accept notifications given the authentication provided by the NG. > This is already true for SNMPv3/USM NR engines today (there is no > NR authorization model in the SNMPv3 STDs). > > Notification delivery would fail if the snmpSSHNRHostKey didn't > match the returned SSH public certificate given by the NR or if it > failed to authenticate. The SSH connection also wouldn't > succeed if > the NR refused > > The question many should be asking at this point is, > "but... we're > trying *not* to configure so much stuff and we want to reuse > existing authentication systems". > > - There is no way to avoid the configuration of the NR host key to > be expected. Not doing so would be insecure. IE, > snmpSSHNRHostKey is required. This *could* be > bootstrapped using > the normal SSH known_hosts cache if it already had a setting. A > blank value, eg, could indicate use "use the existing > known_hosts > cache". Because this is expected to be a device that probably > hasn't done SSH Client logins before, it's unlikely this host > cache would exist. But it could be distributed via > rdist, etc, if > operators preferred that. It could be that this entire column > could be left to SSH Client side implementation, but > that doesn't > seem complete to me and I'd rather see it in place rather than > require an external distribution mechanism. > > - There is no way to avoid the configuration required by > the client > (snmpSSHUserName and related authentication data). > *However*, if > the snmpSSHUserCredentialType was 3 (hostPublicKey) and > snmpSSHNRUserKey was "" (blank) then that could > indicate to simply > use the system configured ssh host key instead of using > a separate > one. This would alleviate this configuration setting > and entirely > rely on the pre-configured ssh service's host key. This does > assume there is only one to choose from, however. If a > system had > more than one it is undefined what should happen. > > This is dual-using a SSH host key for both host usage and user > usage, and it's unclear whether this should be frowned upon or > not. Cryptography-wise it's generally not recommend > that keys not > be allowed to be shared between multiple identities (i.e. both a > host and a user named 'Adam'). SSH actually already has an > authentication mode designed to authenticate as a host directly > though. See the next section for details. > > 2.1.2 Authentication Using a SSH Host-Key > > Devices with deployed SSH Host public-key credentials > ("Host-Keys") > already have a public key that is likely already known to > a network > management station. This is the same host identity that must be > authenticated to when connecting to an agent operating as > a CR when > a management station takes on the role of a CG over SSH. It is > possible to reuse the CR's SSH public host key when operating as a > NG SSH-Client to open a connection back to a NR SSH-Server. > > To accomplish this, the NG would open a SSH connection to the NR > and both sides would authenticate each other. The NR would use a > host-key certificate per-normal SSH usage. The NG would present > it's own host-key certificate to authenticate itself rather than > present the more typical user-based credential as discussed in > section 2.1.1. > > How to accomplish this via the SSH protocol is discussed in > Section 9 of [RFC4252]. Note that for SSH this form of > authentication support is OPTIONAL in this document. The ISMS/SSH > document would have to require. > > > Steps to send the notification: > > 1) The NG would open a SNMP/SSH connection to the NR. > > 2) The NR would send it's public key and proof of ownership > > 3) The NG would verify that it was talking to the > expected NR (by > verifying the public key against the proof and by verifying > that the public key presented matched the expected public key > for that destination). > > 4) The NG would transmit it's special host-based user name (see > below) and it's host credential. > > 5) The NR would verify the authenticity of the received > credentials. > > 6) The NG would send the notification through the established > connection. > > Note: Section 9 of [RFC4252] actually specifies that for > authorization purposes the NR can ignore the user name field for > this authentication type. The NG must fill it in, however. > > For the new snmpSSHParametersTable settings, they would look > like: > > snmpSSHParametersTable: > snmpSSHParameterName sshParams (matches > 2nd * above) > snmpSSHUserName sshUser (the NG > says "I'm sshUser") > * snmpSSHUserCredentialType 3 (1 = > userPublicKey, > 2 = > userPassword, > 3 = > hostPublicKey > ... enum list > should be pulled > from > ssh auth types?) > * snmpSSHNGUserKey "" (the > expected NG Key) > (blank = > default host key) > snmpSSHNGUserPass "" (none) > snmpSSHNRHostKey +++ (the > expected NR Key) > > * = changed from last time > +++ = issue with config via SNMP since these are potentially > larger than SNMP/UDP would like. > > > With the above in place, it should be possible to open a host-key > based authentication from the NG to an NR. > > It is implementation dependent how the NR decides whether to > accept notifications given the authentication provided by the NG. > This is already true for SNMPv3/USM NR engines today. > > The primary advantage of this over the user-based credentials used > in Section 2.1.1 is that the host-key has likely already been > created and no credential configuration is needed and this is the > SSH supported mechanism for using a host-based authentication > mechanism. The NR, however, still needs to be configured > to accept > notifications from an NG using it's host-key credentials (and tied > to the snmpSSHUserName passed in the "user name" field of the > SSH_MSG_USERAUTH_REQUEST message described in Section 9 of > [RFC4252]. > > 2.2 Reusing an existing SNMP/SSH Connection That Was Previously > Established between the NG and NR. > > There has been desire to have an architecture where a Notification > Receiver connects to a Notification Generator and notifications > are then sent via this connection. This section describes how > this can be done via SNMP/SSH using additional MIB configuration > settings. Some of this desire has dropped a bit since > this section > was originally written. [I haven't re-proof-read this > section as much.] > > Steps to send the notification: > > 1) The NR would open a SNMP/SSH connection to the NG. There are > two choices here: > > a) Open only a single connection to the standard CR service > endpoint which also happens to be capable of sending > notifications back over the same stream (acting as a NG on > the same session). > b) One connection to the standard CR service, and a second to > a NG service port. > > Note that notifications would not be sent until the rest of > the following steps had taken place. > > 2) The CR and/or NG service(s) would send it's public key and > proof of ownership. > > 3) The CG and/or NR would verify that it was talking to the > expected CR/NG (by verifying the public key against the proof > and by verifying that the public key presented matched the > expected public key for that destination). > > 4) The CG/NR would transmit it's user name and credentials > (either a public key, password or other SSH authentication > mechanism). > > 5) The CR/NG would verify the authenticity of the received > credentials. > > 6) The CG would configure the CR to send notifications over the > already existing SNMP/SSH channels (configuration of the > snmpNotifyTable not shown as it matches that in section 1.2): > > snmpTargetParamsTable row: > snmpTargetParamsName toCR > (administrative string) > snmpTargetParamsMPModel 3 (SNMPv3) > * snmpTargetParamsSecurityModel 4 (SSH) > * snmpTargetParamsSecurityName XXX (see below) > snmpTargetParamsSecurityLevel 3 (auth|encr) > snmpTargetParamsStorageType 3 (nonVolatile) > snmpTargetParamsRowStatus 4 (createAndGo) > > snmpTargetAddrTable row: > snmpTargetAddrName toCRAddr > (arbitrary string) > * snmpTargetAddrTDomain snmpSSHSession > * snmpTargetAddrTAddress YYY (see below) > snmpTargetAddrTimeout 1500 (in > .01 sec) > snmpTargetAddrRetryCount 3 > snmpTargetAddrTagList toCRTag > snmpTargetAddrParams toCR > (must match prev) > snmpTargetAddrStorageType 3 > (nonVolatile) > snmpTargetAddrColumnStatus 4 > (createAndGo) > > > * = changed since previous example. > > > In order to enable the NG to start sending notifications over > either the current ssh session (the connection to the CR service) > or another SSH session (a connection to the NG service), the XXX > value of the snmpTargetParamsSecurityName and the YYY parameter of > the snmpTargetAddrTAddress field need to be filled into to point > to the proper session. This could be done in 2 different ways > that I can think of (possibly more): > > option 1) > > snmpTargetAddrTDomain = snmpSSHSession > snmpTargetParamsSecurityName = XXX = "NRUser" > snmpTargetAddrTAddress = YYY = "" > > This would effectively state that the NG could send > notifications > to all connected SNMP/SSH sessions that the incoming > (***only***) > SNMP/SSH connection had authenticated as the SNMP/SSH user > "NRUser". Outgoing sessions from the NG MUST NOT be checked for > when looking for sessions that match this criteria. The VACM > would be consulted based on the SNMP/SSH security model and the > security Name of "NRUser" in this example. > > option 2) > > snmpTargetAddrTDomain = snmpSSHSession > snmpTargetParamsSecurityName = XXX = "" > snmpTargetAddrTAddress = YYY = 0x00000001 (session id) > > This would effectively state that the NG could send > notifications to the SNMP/SSH session with a session id of 1. > This could potentially be the exact same session that the CG/CR > were speaking over, or it could be an "external" session such as > one connected to via the CR. The VACM would be consulted based > on the SNMP/SSH security model and the security name of the > ***remote*** user name associated with the remote session #1 for > incoming sessions. Outgoing sessions MUST NOT be referred to by > the NG (see ????) > > (???? aside: actually I'm not sure this is required from a > security stand point, but I don't like the security name > associations that would have to happen between the configuration > and the sessions... I'd rather just only do this for incoming > sessions as it doesn't make my hairs stand up as potentially > problematic). > > 3. VACM Authorization > > Here's where the important note discussed above comes > into play: the > VACM doesn't care how the securityName passed to it was > derived and > authenticated. It's not the job of the VACM to do that. > It trusts > the CR and NG engines to have done the right thing security wise. > > A lot of discussion has surrounded this point. What does the VACM > use when doing authorization lookups? The NR/SSH server doesn't > have a "user name" in the traditional sense of the word. It has > proven that it has an adequate host key, however. > > Choices: > > 1) The local configuration has already dictated a user name to use > via the snmpSSHUserName setting discussed above (assuming the > text in this document is followed). This is the value that > should be given to the VACM (along with an appropriate > model and > level settings based on the connection). It doesn't > matter that > the remote host didn't specify this value in the > connection; the > local configuration says this is the value that should be used > and the remote side *has* proven that it can authenticate the > NR host key that was expected. > > But, this doesn't allow for dual-user name support, > which brings > us to option 2: > > 2) If there is desire to have the NG/SSH-Client use one > user name to > authenticate itself to the remote NR/SSH-Server and another to > consider the remote NR/SSH-Server to be for purposes of VACM > authorization then another column in the snmpSSHParametersTable > would be needed that might have something like: > > snmpSSHRemoteUser "Jack" > > Again, it does not matter that the remote side didn't > technically > specify itself as "Jack". It's already proven that it has the > configure remote host key. > > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 16 03:04:56 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4213A6AEF; Fri, 16 May 2008 03:04:56 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741EB3A6AEF for ; Fri, 16 May 2008 03:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.095 X-Spam-Level: X-Spam-Status: No, score=-6.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtaKY3SzWPyV for ; Fri, 16 May 2008 03:04:54 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1BC353A6859 for ; Fri, 16 May 2008 03:04:53 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4GA4FwF014820; Fri, 16 May 2008 13:04:39 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 May 2008 13:04:36 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 May 2008 13:04:36 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 May 2008 13:04:35 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72A13AF0@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS/SSH and notifications Thread-Index: Aci16nMBexfw/x3ZSSGvyKByHBlx5ABUHWHA References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com><029c01c8b519$721a5f80$0601a8c0@allison><06b101c8b570$dccce800$0600a8c0@china.huawei.com><02aa01c8b59c$28c6c520$0601a8c0@allison> From: To: X-OriginalArrivalTime: 16 May 2008 10:04:36.0411 (UTC) FILETIME=[3F11C8B0:01C8B73C] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker wrote: > I would argue that for a symmetric cryptography using SM like USM > we'd expect them to be the same. I don't necessarily think that's > true for an asymmetric system like any public/private key system. > What we use to identify ourselves as the "client" will be > differently named than what we use to identify the remote side. > Naming wise, no, I don't think they need to be the same (since it > doesn't buy you anything). As a client I may be configured to be > "wes" but I'm not expecting to talk to "wes" at the other end. I'm > expecting to talk to "bob". > > Most importantly, I'm expecting to talk to another transport end > that meets my security requirements for proof of identity > requirements. SSH proves that sufficiently for me to trust it. > Thus I can choose to call the remote side "bob" (or "wes" too if you > really wanted to) as long as the more important aspect is still > true: they've cryptographically shown me I've connected to the right > place given the message I want to send. I honestly don't care about > the name; I care about the cryptography. I agree; if the Notification Originator side (probably either SSHTM or SSH module) has information mapping the local securityName (given the the NO application, and used locally for VACM checks) to the public host key that the SSH server must authenticate with, then we seem to have sufficient proof for sending the notification. The fact that there could be multiple local securityNames (possibly having different access rights in VACM) mapping to the same SSH server host public key doesn't make this proof insufficient. (I.e., if configured so, notifications with securityNames "alice" and "bob" could be sent to the same transport endpoint (SSH server), authenticating with a single host key.) Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 16 03:42:00 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A339728C17B; Fri, 16 May 2008 03:42:00 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DCD28C17B for ; Fri, 16 May 2008 03:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksSrzHmc3-W1 for ; Fri, 16 May 2008 03:41:55 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id EB09E3A6861 for ; Fri, 16 May 2008 03:41:54 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4GAf3DX012601; Fri, 16 May 2008 13:41:34 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 May 2008 13:40:48 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 May 2008 13:40:47 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 May 2008 13:40:46 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> In-Reply-To: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS/SSH and notifications Thread-Index: Acir6hmVy3ZUdaUvRT6mENS3EiZoJQKBBnLAAFRQFUA= References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> From: To: , X-OriginalArrivalTime: 16 May 2008 10:40:47.0970 (UTC) FILETIME=[4D6B6420:01C8B741] X-Nokia-AV: Clean Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, Thanks for a good explanation! I think there's a way to slightly refactor Wes's proposal to make it consistent with the architecture (since I'm making only small adjustments to Wes's text, I'm not quoting it all). When a PDU is sent, SSHTM will get transportAddress and securityName (and other information). If it needs to open a new connection, it will need some local information (which isn't necessarily a MIB table) to do so. This is almost the same as snmpSSHParametersTable in Wes's text, except that we need to index it by (transportAddress, securityName) and not parameter name (which isn't visible in SSHTM, right?). So the table would look something like this: snmpSSHOutgoingTable: index: snmpSSHTransportAddress 192.0.2.1:162 snmpSSHSecurityName "Alice" columns: snmpSSHUserName "Adam" (I say "I'm Adam") snmpSSHUserCredentialType 1 (1 = userPublicKey, 2 = userPassword, 3 = hostPublicKey ... enum list) snmpSSHUserKeyPair ++++ (the public/private key pair to use if 1) snmpSSHUserPassword ++++ (the passphrase to use if 2) snmpSSHRemoteHostPublicKey +++ (the public key expected from peer) Most importantly, this same table would be used when sending PDUs for command generator -- since SSHTM isn't supposed to know what's inside the PDU. (Although there's one difference in how the table would be typically configured; on management stations, a common configuration would use same string in both snmpSSHSecurityName and snmpSSHUserName, while on agents, they would be typically different.) The side acting as an SSH server also needs some information (which might not be a MIB table); this is similar to the 2nd snmpSSHParametersTable in Wes's text, except we index it by user name: snmpSSHIncomingTable: index: snmpSSHUserName "Adam" (peer says "I'm Adam") columns: snmpSSHSecurityName "adam" (this is what gets passed outside SSHTM) snmpSSHUserCredentialType 1 (1 = userPublicKey, 2 = userPassword, ...) snmpSSHUserPublicKey +++ (the public key to use if 1) snmpSSHUserPassword +++ (the correct password if 2) (In this setting, it's possible that there exists multiple snmpSSHOutgoingTable entries that contain the same snmpSSHRemoteHostPublicKey -- but I don't think this is really a big problem.) Would this be consistent with the architecture? Best regards, Pasi > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of ext David Harrington > Sent: 16 May, 2008 00:34 > To: 'Wes Hardaker'; isms@ietf.org > Subject: Re: [Isms] ISMS/SSH and notifications > > Hi, > > I think the starting point of this discussion has some incorrect > assumptions and that could be causing some problems, so I would like > to correct some of the starting point for configuration. I am paying > close attention to the layering called for by the architecture, > because it is important to correctly understanding how things get > done. > > The TSM describes how to work with the ParamsTable and the TargetTable > in Appendix A of the TSM document. Wes's examples showed other values. > > snmpTargetParamsSecurityModel would not be configured with (SNMP/SSH > Mapping). It should be configured with the securitymodel to be used, > not the transport model to be used. The securityModel to work with our > SSH design should be the TransportSecurityModel (TSM). > > This is a really important thing to know because it is the > securitymodel specified in snmpTargetParamsSecurityModel that knows > how to take the securityModel and securityLevel specified in > snmpTargetParamsSecurityName and snmpTargetParamsSecurityLevel and map > them to the appropriate security credentials. > > The Transport Security Model will determine from the transportDomain > (which should have a value of snmpSSHDomain) that the SSH transport > model should be used. For an outgoing message, it will check for an > existing securityStateReference. If the application is requesting that > a notification be sent, there will not be an existing > securityStateReference (which are used to ensure responses have the > same security as the request). > > The TSM will create a tmStateReference (the structure used to pass > info between the SM and the TM), and put in the securityName and > securityLevel. Then it will create the wholeMmessage from the parts > provided by the MPM and a zeroed-out securityParameter field, and give > that back to the MPM. > > The MPM will pass the request to send the wholeMsg to the specified > transport address (and pass along the tmStateReference). > > Note that up to this point, nobody has looked to see if there is an > existing connection. That's important because it is not their job to > do so. The six step process described in Wes's example is wrong for > that reason. > > The TM (in this case the SSH-TM) will take the address provided by the > MPM, plus the securityName and Level, and determine how to convert > that into SSH parameters. Then it will check whether a connection > exists that matches those parameters. It does this in an > implementation-dependent manner, but it probably uses the address and > the securityname and the securityLevel to see if the local > configuration datastore has a record of such an existing connection. > It is implementation-dependent whether it checks an SNMP datastore (a > MIB) or an SSH datastore (such as a ./ssh_config and an ssh_keys > directory). Maybe it doesn't check at all, but simply says "hey SSH, > send this for me, will you? and SSH finds an existing connection, or > establishes a new connection, and sends the message, or the SSH layer > returns an error. A lot is going to depend on the APIs provided by the > SSH implementation one is using. > > The really important part here is that the application knows nothing > of the transport processing except the address and domain, or the > security processing except the Model/Name/Level. The security model > knows nothing of the transport-specific processing, and the MPM knows > nothing of the transport-specific processing. Only the transport model > really knows about the processing for that transport. > > And if the transport layer (SSH) is providing the authentication, then > only the transport layer really know what processing occurs to do that > authentication. Only SSH knows whether authentication was done using > public keys or passwords or certificates or whatever. > > Now, if we want to store client credentials locally so we have the > necessary credentials to initiate an SSH session for notifications > when no connection is available, we can define a standardized > datastore to put that into (define an SSHTM-specific MIB as part of > the transport model). But before we decide the WG should do this we > should see if the SSH configuration datastore already has a mechanism > for storing such credentials, such as an ssh_keys directory. We should > also be careful to separate the SSH-MIB from the SSHTM-MIB, since > having an SSH-MIB would allow SSH used for other purposes to be > managed as well. > > So can we reach consensus that the issue we need to deal with is not > the TARGET-TABLE or PARAMS-TABLE, and not the application or the > security model? > > We should be talking about how the SSH-TM talks to an underlying SSH > implementation (whichever one that happens to be) in a standardized > manner, including implementation-dependent magic. We also need to > figure out how to bridge the gap from what we have for info > (securityName and Level and transport domain and address) to what SSH > needs to initate an outgoing connection. And we need to consider, for > incoming messages, how we get from what SSH has (user names, host > keys, or whatever) to what we need to pass up the stack (securityName > and Level and transport domain and address). > > Personally, I think we need to identify the securityModel that the TM > expects will process the provided securityName and Level, rather than > leave it to the MPM to decide which SM to use, but we can discuss that > again later. > > > dbh > > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > > Behalf Of Wes Hardaker > > Sent: Thursday, May 01, 2008 8:17 PM > > To: isms@ietf.org > > Subject: [Isms] ISMS/SSH and notifications > > > > > > The following is based on the message I sent out in January > > in 2007 and > > then later modified in July of 2007. I've now modified it for a > third > > time to fix some errors I found in it and have lengthened some of > the > > sections to talk more about the issues recently discussed here. > > > > I didn't know which email was the best to reply to in the current > > thread, so I gave up and started a new Subject: :-) > > > > (previous posting for anyone that wants to compare changes: > > > http://www.ietf.org/mail-archive/web/isms/current/msg02097.html > > ) > > > > This is *long* but hopefully clear. Please read the entire document > > before responding to bits in the top; it's not a complete set > > of thouhts > > without reading the whole thing (sorry). Hopefully it'll be > helpful, > > however. The VACM discussion in section 3 is entirely new. > > > > This is all about sending notifications over SNMP/SSH and the usable > > authentication mechanisms. It's been edited heavily for improved > > readability and usability. I can probably be coerced into further > > formalizing the writing for suitable inclusion into the > > resulting draft > > assuming the description below is sufficient for forward progress. > > > > Note: I have not trolled through all the docs to make sure > everything > > below is 100% accurate and secure. Think of it as a white-board > > diagram not an end-specification. > > > > 1.0 Background > > > > 1.1 Terminology > > > > Politically correct SNMP terms: > > > > CG = command generator > > CR = command responder > > NG = notification generator > > NR = notification responder > > > > SSH terms: > > > > LoF = Leap of Faith > > > > 1.2 Basic Notification Configuration > > > > The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB already allow for > > configuration of notification receivers destinations to which > > notifications should be sent. The following examples depict > > possible configuration of this setup using a USM configuration. > > > > snmpTargetParamsTable row: > > snmpTargetParamsName toNR > > (administrative string) > > snmpTargetParamsMPModel 3 (SNMPv3) > > * snmpTargetParamsSecurityModel 3 (USM) > > * snmpTargetParamsSecurityName usmUser (The USM user name) > > snmpTargetParamsSecurityLevel 3 (auth|encr) > > snmpTargetParamsStorageType 3 (nonVolatile) > > snmpTargetParamsRowStatus 4 (createAndGo) > > > > snmpTargetAddrTable row: > > snmpTargetAddrName toNRAddr > > (arbitrary string) > > snmpTargetAddrTDomain snmpUDPDomain > > snmpTargetAddrTAddress 0x0A00000100A2 (NR > > address, port) > > snmpTargetAddrTimeout 1500 (in .01 sec) > > snmpTargetAddrRetryCount 3 > > snmpTargetAddrTagList toNRTag > > snmpTargetAddrParams toNR (must > > match prev table) > > snmpTargetAddrStorageType 3 (nonVolatile) > > snmpTargetAddrColumnStatus 4 (createAndGo) > > > > > > snmpNotifyTable row: > > snmpNotifyName NRNotif > > (arbitrary string) > > snmpNotifyTag toNRTag > > (matches tag list above) > > snmpNotifyType 2 (inform) > > snmpNotifyStorageType 3 (nonVolatile) > > snmpNotifyColumnStatus 4 (createAndGo) > > > > > > The above will configure an agent to act as a NG and send informs > to > > the NR at 10.0.0.1 port 162 using the SNMPv3/USM user "usmUser". > > The configuration for the "usmUser" settings in the > > SNMP-USER-BASED-SM-MIB and SNMP-VIEW-BASED-ACM-MIB objects are not > > shown here for brevity. The columns marked with a "*" are the > items > > that are USM specific. > > > > We'll refer back in later sections about how this changes when > using > > SNMP/SSH. > > > > An important point: the agent already needs configuration to be > able > > to send notifications regardless if ssh is the transport or > > it's not. > > > > 1.3 Basic VACM Configuration > > > > The workings of the VACM is fortunately more widely understood, so > I > > won't break it out in detail here. The important thing to do know > > from a notification point of view is that the only thing the VACM > > needs to check is "am I allowed to send this notification". It > does > > that through the use of a securityName (and model and > > level) given to > > it by the NG. It doesn't care where that securityName came from > nor > > how it was technically authenticated. It completely trusts > > the caller > > to not have lied to it and it's the callers responsibility to have > > checked the authenticity of the values. > > > > Here's the important key point: the VACM does not verify that the > > other end is actually who they say they are. It's not the > > VACMs job. > > We'll need this later. > > > > 2.0 Notification Generation by a Notification Responder > > > > Notification Generators (NGs) need to send notifications to > > management > > stations acting as a Notification Responders (NRs). There are > three > > possibilities for how this might be done depending on the current > > SNMP/SSH sessions available for use and the directionality > > associated > > with them. > > > > Section 2.1 describes 2 authentication mechanism procedures for > how > > a Notification Generator would open and authenticate a SNMP/SSH > > connection to a Notification Receiver. > > > > Section 2.2 describes how a Notification Receiver can open a > > connection (or more than one) to the Notification Generator and > > configure it to send notifications over an existing connection. > > > > 2.1 A Notification Generator Opening a SNMP/SSH Connection to the > > Notification Responder > > > > There are a number of interesting issues with how to do the case > > where a Notification Generator needs to open a connection to the > > Notification Receiver. The hardest issue with this has been > > authentication mechanism to authenticate the NG at the NR side. > > Additionally, the NR must be authenticated at the NG side and > the > > NG must properly check VACM settings to ensure each notification > > sent to the NR is authorized. > > > > 2.1.1 Authentication Using a User Credential > > > > Devices could be configured with user credentials (EG, a user > name > > and the user's public-key or password) to use when connecting to > a > > NR. This would make use of the normal user-to-host mode of > > operation of SSH. > > > > Steps to send the notification (this is a very terse > > description of > > what happens when you combine SSH and SNMP for notifications; > it's > > obviously a bit more complex as there are more steps > > involved; this > > is just a high level summary): > > > > 1) The NG would open a SNMP/SSH connection as an SSH > > Client to the > > NR acting as a SSH server. > > > > 2) The NR would send it's public (host) key and proof > > of ownership > > > > 3) The NG would verify that it was talking to the > > expected NR (by > > verifying the public key against the proof and by verifying > > that the public key presented matched the expected public > key > > for that destination; see below). > > > > 4) The NG would transmit it's user name and it's own SSH > > authentication credentials (either the a public key, > > and proof > > or a password). > > > > 5) The NR would verify the authenticity of the received > > credentials. > > > > 6) The NG would send the notification through the established > > connection. > > > > The configuration pieces missing that are not currently > available > > in any modern MIBs at this time: > > > > 1) The ability to indicate that ISMS/SSH should be used as the > > transport. > > > > EG: "Send a copy of the notification to host H using > > SSH to port P" > > > > 2) The Ability to specify the SSH user credential type to use > > (eg, public key or password) > > > > EG: "I'm 'Adam'" > > > > 3) The ability to configure that public-key or password > > > > EG: "I can prove I'm joe because I have the super secret > > password or can prove I have the needed private key" > > > > 4) end-destination expected public SSH host-key > > > > - the public key of the NR acting as an SSH Server > > that the NG > > acting as a SSH Client should be connecting to. > > > > EG: "Now prove to me that you're Bob so I know that > > you're not > > Eve" > > > > Note one security risk that needs to be mentioned about the > above: > > > > 1) Username/password combinations are horrible things > > to use. SSH > > allows for it but in order to use it securely in order to > > prevent agent configuration theft compromising an entire > > network (see USM Key Localization) you'd have to use a > > different username/password configured into each agent. > That > > doesn't scale wonderfully from a configuration point of > view. > > Thus public/private keys should be used instead (of > course). > > I'm not going to get into the debate here about whether we > > should support/allow username/password configuration for > > sending something). > > > > 2.1.1.1 Changes to the TARGET-MIB configuration > > > > This would result in notification destination parameter > > configuration that looked like (the settings explained next): > > > > snmpTargetParamsTable row: > > snmpTargetParamsName toNR > > (administrative string) > > snmpTargetParamsMPModel 3 (SNMPv3) > > * snmpTargetParamsSecurityModel 4 > > (SNMP/SSH mapping) > > * snmpTargetParamsSecurityName sshParams (The SSH > > parameter name) > > snmpTargetParamsSecurityLevel 3 (auth|encr) > > snmpTargetParamsStorageType 3 (nonVolatile) > > snmpTargetParamsRowStatus 4 (createAndGo) > > > > snmpTargetAddrTable row: > > snmpTargetAddrName toNRAddr > > (arbitrary string) > > + snmpTargetAddrTDomain snmpTCPDomain > > ++ snmpTargetAddrTAddress 0x0A00000100A2 (NR > > address, port) > > snmpTargetAddrTimeout 1500 (in > > .01 sec) > > snmpTargetAddrRetryCount 3 > > snmpTargetAddrTagList toNRTag > > snmpTargetAddrParams toNR > > (must match prev) > > snmpTargetAddrStorageType 3 > > (nonVolatile) > > snmpTargetAddrColumnStatus 4 > > (createAndGo) > > > > > > * = changed since previous example. > > + = may change to snmpSSHDomain? subject to debate > > (the security model already indicates SSH but if we want a > v1 > > or v2c security model then we'll need to use a > snmpSSHDomain > > instead; I think this is likely at this point) > > ++ = shown as same but will likely change > > (likely a new port number from IANA) > > > > Because we need 4 configuration settings (1-4 above) and > > there is no > > room in the existing tables for some of that information (config > > setting #1 (use SSH) was done in the > snmpTargetParamsSecurityModel > > and/or snmpTargetAddrTDomain), we'll need to create > > another table to > > contain the other 3 needed settings. I'll call this the > > snmpSSHParametersTable and it will contain the following > > information: > > > > snmpSSHParametersTable: > > > > index: > > snmpSSHParameterName sshParams (matches > > 2nd * above) > > > > columns: > > snmpSSHUserName Adam (the NG > > says "I'm Adam") > > snmpSSHUserCredentialType 1 (1 = > > userPublicKey, > > 2 = > > userPassword, > > 3 = > > hostPublicKey > > ... enum list) > > snmpSSHNGUserKey +++ (the > > expected NG Key if 1) > > snmpSSHNGUserPass ++++ (the > > passphrase to > > use if 2) > > snmpSSHNRHostKey +++ (the public key > > > > expected from the > > expected NR) > > > > +++ = potential issue with config via SNMP/UDP since these are > > potentially larger than SNMP/UDP would like. > > ++++ = a GET should return "" at all times? > > > > With all of this in place it is possible for a NG to open a > > connection to a NR and authenticate itself and verify the other > > end is the expected end. Note that we still haven't > > discussed user > > names; be patient! > > > > It is implementation dependent how the NR decides whether to > > accept notifications given the authentication provided by the > NG. > > This is already true for SNMPv3/USM NR engines today (there is > no > > NR authorization model in the SNMPv3 STDs). > > > > Notification delivery would fail if the snmpSSHNRHostKey didn't > > match the returned SSH public certificate given by the NR or if > it > > failed to authenticate. The SSH connection also wouldn't > > succeed if > > the NR refused > > > > The question many should be asking at this point is, > > "but... we're > > trying *not* to configure so much stuff and we want to reuse > > existing authentication systems". > > > > - There is no way to avoid the configuration of the NR host key > to > > be expected. Not doing so would be insecure. IE, > > snmpSSHNRHostKey is required. This *could* be > > bootstrapped using > > the normal SSH known_hosts cache if it already had a setting. > A > > blank value, eg, could indicate use "use the existing > > known_hosts > > cache". Because this is expected to be a device that probably > > hasn't done SSH Client logins before, it's unlikely this host > > cache would exist. But it could be distributed via > > rdist, etc, if > > operators preferred that. It could be that this entire column > > could be left to SSH Client side implementation, but > > that doesn't > > seem complete to me and I'd rather see it in place rather than > > require an external distribution mechanism. > > > > - There is no way to avoid the configuration required by > > the client > > (snmpSSHUserName and related authentication data). > > *However*, if > > the snmpSSHUserCredentialType was 3 (hostPublicKey) and > > snmpSSHNRUserKey was "" (blank) then that could > > indicate to simply > > use the system configured ssh host key instead of using > > a separate > > one. This would alleviate this configuration setting > > and entirely > > rely on the pre-configured ssh service's host key. This does > > assume there is only one to choose from, however. If a > > system had > > more than one it is undefined what should happen. > > > > This is dual-using a SSH host key for both host usage and user > > usage, and it's unclear whether this should be frowned upon or > > not. Cryptography-wise it's generally not recommend > > that keys not > > be allowed to be shared between multiple identities (i.e. both > a > > host and a user named 'Adam'). SSH actually already has an > > authentication mode designed to authenticate as a host > directly > > though. See the next section for details. > > > > 2.1.2 Authentication Using a SSH Host-Key > > > > Devices with deployed SSH Host public-key credentials > > ("Host-Keys") > > already have a public key that is likely already known to > > a network > > management station. This is the same host identity that must be > > authenticated to when connecting to an agent operating as > > a CR when > > a management station takes on the role of a CG over SSH. It is > > possible to reuse the CR's SSH public host key when operating as > a > > NG SSH-Client to open a connection back to a NR SSH-Server. > > > > To accomplish this, the NG would open a SSH connection to the NR > > and both sides would authenticate each other. The NR would use > a > > host-key certificate per-normal SSH usage. The NG would present > > it's own host-key certificate to authenticate itself rather than > > present the more typical user-based credential as discussed in > > section 2.1.1. > > > > How to accomplish this via the SSH protocol is discussed in > > Section 9 of [RFC4252]. Note that for SSH this form of > > authentication support is OPTIONAL in this document. The > ISMS/SSH > > document would have to require. > > > > > > Steps to send the notification: > > > > 1) The NG would open a SNMP/SSH connection to the NR. > > > > 2) The NR would send it's public key and proof of ownership > > > > 3) The NG would verify that it was talking to the > > expected NR (by > > verifying the public key against the proof and by verifying > > that the public key presented matched the expected public > key > > for that destination). > > > > 4) The NG would transmit it's special host-based user name > (see > > below) and it's host credential. > > > > 5) The NR would verify the authenticity of the received > > credentials. > > > > 6) The NG would send the notification through the established > > connection. > > > > Note: Section 9 of [RFC4252] actually specifies that for > > authorization purposes the NR can ignore the user name field for > > this authentication type. The NG must fill it in, however. > > > > For the new snmpSSHParametersTable settings, they would look > > like: > > > > snmpSSHParametersTable: > > snmpSSHParameterName sshParams (matches > > 2nd * above) > > snmpSSHUserName sshUser (the NG > > says "I'm sshUser") > > * snmpSSHUserCredentialType 3 (1 = > > userPublicKey, > > 2 = > > userPassword, > > 3 = > > hostPublicKey > > ... enum list > > should be > pulled > > from > > ssh auth types?) > > * snmpSSHNGUserKey "" (the > > expected NG Key) > > (blank = > > default host key) > > snmpSSHNGUserPass "" (none) > > snmpSSHNRHostKey +++ (the > > expected NR Key) > > > > * = changed from last time > > +++ = issue with config via SNMP since these are potentially > > larger than SNMP/UDP would like. > > > > > > With the above in place, it should be possible to open a > host-key > > based authentication from the NG to an NR. > > > > It is implementation dependent how the NR decides whether to > > accept notifications given the authentication provided by the > NG. > > This is already true for SNMPv3/USM NR engines today. > > > > The primary advantage of this over the user-based credentials > used > > in Section 2.1.1 is that the host-key has likely already been > > created and no credential configuration is needed and this is > the > > SSH supported mechanism for using a host-based authentication > > mechanism. The NR, however, still needs to be configured > > to accept > > notifications from an NG using it's host-key credentials (and > tied > > to the snmpSSHUserName passed in the "user name" field of the > > SSH_MSG_USERAUTH_REQUEST message described in Section 9 of > > [RFC4252]. > > > > 2.2 Reusing an existing SNMP/SSH Connection That Was Previously > > Established between the NG and NR. > > > > There has been desire to have an architecture where a > Notification > > Receiver connects to a Notification Generator and notifications > > are then sent via this connection. This section describes how > > this can be done via SNMP/SSH using additional MIB configuration > > settings. Some of this desire has dropped a bit since > > this section > > was originally written. [I haven't re-proof-read this > > section as much.] > > > > Steps to send the notification: > > > > 1) The NR would open a SNMP/SSH connection to the NG. There > are > > two choices here: > > > > a) Open only a single connection to the standard CR service > > endpoint which also happens to be capable of sending > > notifications back over the same stream (acting as a NG > on > > the same session). > > b) One connection to the standard CR service, and a second > to > > a NG service port. > > > > Note that notifications would not be sent until the rest of > > the following steps had taken place. > > > > 2) The CR and/or NG service(s) would send it's public key and > > proof of ownership. > > > > 3) The CG and/or NR would verify that it was talking to the > > expected CR/NG (by verifying the public key against the > proof > > and by verifying that the public key presented matched the > > expected public key for that destination). > > > > 4) The CG/NR would transmit it's user name and credentials > > (either a public key, password or other SSH authentication > > mechanism). > > > > 5) The CR/NG would verify the authenticity of the received > > credentials. > > > > 6) The CG would configure the CR to send notifications over > the > > already existing SNMP/SSH channels (configuration of the > > snmpNotifyTable not shown as it matches that in section > 1.2): > > > > snmpTargetParamsTable row: > > snmpTargetParamsName toCR > > (administrative string) > > snmpTargetParamsMPModel 3 (SNMPv3) > > * snmpTargetParamsSecurityModel 4 (SSH) > > * snmpTargetParamsSecurityName XXX (see below) > > snmpTargetParamsSecurityLevel 3 (auth|encr) > > snmpTargetParamsStorageType 3 (nonVolatile) > > snmpTargetParamsRowStatus 4 (createAndGo) > > > > snmpTargetAddrTable row: > > snmpTargetAddrName toCRAddr > > (arbitrary string) > > * snmpTargetAddrTDomain snmpSSHSession > > * snmpTargetAddrTAddress YYY (see > below) > > snmpTargetAddrTimeout 1500 (in > > .01 sec) > > snmpTargetAddrRetryCount 3 > > snmpTargetAddrTagList toCRTag > > snmpTargetAddrParams toCR > > (must match prev) > > snmpTargetAddrStorageType 3 > > (nonVolatile) > > snmpTargetAddrColumnStatus 4 > > (createAndGo) > > > > > > * = changed since previous example. > > > > > > In order to enable the NG to start sending notifications over > > either the current ssh session (the connection to the CR > service) > > or another SSH session (a connection to the NG service), the XXX > > value of the snmpTargetParamsSecurityName and the YYY parameter > of > > the snmpTargetAddrTAddress field need to be filled into to point > > to the proper session. This could be done in 2 different ways > > that I can think of (possibly more): > > > > option 1) > > > > snmpTargetAddrTDomain = snmpSSHSession > > snmpTargetParamsSecurityName = XXX = "NRUser" > > snmpTargetAddrTAddress = YYY = "" > > > > This would effectively state that the NG could send > > notifications > > to all connected SNMP/SSH sessions that the incoming > > (***only***) > > SNMP/SSH connection had authenticated as the SNMP/SSH user > > "NRUser". Outgoing sessions from the NG MUST NOT be checked > for > > when looking for sessions that match this criteria. The VACM > > would be consulted based on the SNMP/SSH security model and > the > > security Name of "NRUser" in this example. > > > > option 2) > > > > snmpTargetAddrTDomain = snmpSSHSession > > snmpTargetParamsSecurityName = XXX = "" > > snmpTargetAddrTAddress = YYY = 0x00000001 (session id) > > > > This would effectively state that the NG could send > > notifications to the SNMP/SSH session with a session id of 1. > > This could potentially be the exact same session that the > CG/CR > > were speaking over, or it could be an "external" session such > as > > one connected to via the CR. The VACM would be consulted > based > > on the SNMP/SSH security model and the security name of the > > ***remote*** user name associated with the remote session #1 > for > > incoming sessions. Outgoing sessions MUST NOT be referred to > by > > the NG (see ????) > > > > (???? aside: actually I'm not sure this is required from a > > security stand point, but I don't like the security name > > associations that would have to happen between the > configuration > > and the sessions... I'd rather just only do this for incoming > > sessions as it doesn't make my hairs stand up as potentially > > problematic). > > > > 3. VACM Authorization > > > > Here's where the important note discussed above comes > > into play: the > > VACM doesn't care how the securityName passed to it was > > derived and > > authenticated. It's not the job of the VACM to do that. > > It trusts > > the CR and NG engines to have done the right thing security > wise. > > > > A lot of discussion has surrounded this point. What does the > VACM > > use when doing authorization lookups? The NR/SSH server doesn't > > have a "user name" in the traditional sense of the word. It has > > proven that it has an adequate host key, however. > > > > Choices: > > > > 1) The local configuration has already dictated a user name to > use > > via the snmpSSHUserName setting discussed above (assuming the > > text in this document is followed). This is the value that > > should be given to the VACM (along with an appropriate > > model and > > level settings based on the connection). It doesn't > > matter that > > the remote host didn't specify this value in the > > connection; the > > local configuration says this is the value that should be > used > > and the remote side *has* proven that it can authenticate the > > NR host key that was expected. > > > > But, this doesn't allow for dual-user name support, > > which brings > > us to option 2: > > > > 2) If there is desire to have the NG/SSH-Client use one > > user name to > > authenticate itself to the remote NR/SSH-Server and another > to > > consider the remote NR/SSH-Server to be for purposes of VACM > > authorization then another column in the > snmpSSHParametersTable > > would be needed that might have something like: > > > > snmpSSHRemoteUser "Jack" > > > > Again, it does not matter that the remote side didn't > > technically > > specify itself as "Jack". It's already proven that it has > the > > configure remote host key. > > > > -- > > Wes Hardaker > > Sparta, Inc. > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 16 07:02:03 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B333A6AE8; Fri, 16 May 2008 07:02:03 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FBCB28C0D9 for ; Fri, 16 May 2008 07:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smcB7kxA6ChT for ; Fri, 16 May 2008 07:02:00 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 614263A68D6 for ; Fri, 16 May 2008 07:02:00 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id SDgk1Z0030QkzPwA901e00; Fri, 16 May 2008 14:01:54 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id SE1s1Z0044HwxpC8N00000; Fri, 16 May 2008 14:01:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=1GjMxTEaQAorDhFr3ogA:9 a=ZugrwDdiNSCUzEKsZtsA:7 a=GdZ68Rl1HnApwkR13ZDk736iTIAA:4 a=1pxjJC3EenQA:10 a=si9q_4b84H0A:10 a=lZB815dzVvQA:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: , References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> Date: Fri, 16 May 2008 10:01:51 -0400 Message-ID: <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> Thread-Index: Acir6hmVy3ZUdaUvRT6mENS3EiZoJQKBBnLAAFRQFUAABCzXUA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Friday, May 16, 2008 6:41 AM > To: ietfdbh@comcast.net; isms@ietf.org > Subject: RE: [Isms] ISMS/SSH and notifications > > Hi, > > Thanks for a good explanation! I think there's a way to slightly > refactor Wes's proposal to make it consistent with the > architecture (since I'm making only small adjustments > to Wes's text, I'm not quoting it all). > > When a PDU is sent, SSHTM will get transportAddress and > securityName (and other information). If it needs to open a new > connection, it will need some local information (which isn't > necessarily a MIB table) to do so. This is almost the same as > snmpSSHParametersTable in Wes's text, except that we need to index > it by (transportAddress, securityName) and not parameter name > (which isn't visible in SSHTM, right?). So the table would look > something like this: Yes. and we would define this within the SSHTM specification, presumably. If we wanted to develop one that could work for multiple transports, with possible support for different securitylevels, then we could add transportdomain and securityLevel to the index so we could differentiate the different address types, and have connections with/without privacy (for example). The indexing is definitely SNMP-related. The other columns seem to be purely SSH-related. This raises the question, if we were to do a MIB, whether the two parts should be modeled separately, with a pointer in the SSHTM table to the relevant row (or whatever) in the SSH datastore. What we need for ISMS is the SSHTM side of the table, to get a mapping to an SSH-specific datastore. > > snmpSSHOutgoingTable: > > index: > snmpSSHTransportAddress 192.0.2.1:162 > snmpSSHSecurityName "Alice" > columns: > snmpSSHUserName "Adam" (I say "I'm Adam") > snmpSSHUserCredentialType 1 (1 = userPublicKey, > 2 = userPassword, > 3 = hostPublicKey > ... enum list) > snmpSSHUserKeyPair ++++ (the public/private > key pair to use if 1) > snmpSSHUserPassword ++++ (the passphrase to > use if 2) > snmpSSHRemoteHostPublicKey +++ (the public key > expected from peer) > > Most importantly, this same table would be used when sending PDUs for > command generator -- since SSHTM isn't supposed to know what's inside > the PDU. > > (Although there's one difference in how the table would be > typically configured; on management stations, a common > configuration would use same string in both snmpSSHSecurityName > and snmpSSHUserName, while on agents, they would be typically > different.) You used "management station"; did you mean SSH server? The SNMPv1 distinction between manager and agent went away with the RFC3411 architecture. From an RFC3411 architectural perspective, both ends are just entities that can include any of the applications. The TM, SM, MPM, and dispatcher don't know or care what role the entity is acting in, and in the case of a manager-to-manager Inform or agent-to-agent Inform, there is no manager/agent pairing. We need to avoid assumptions that TM and SM and MPM processing for manager and agent are different; the difference only happens inside the application layer. I would like to reach consensus on separating the SSHTM table from the SSH-specific stuff, with a pointer in the SSHTM table to a row in an SSH table. That would allow us to get from the TargetTable to the pointer in the SSHTM table. SSHTM table: index: snmpSSHTransportDomain snmpSSHDomain snmpSSHTransportAddress 192.0.2.1:162 snmpSSHSecurityName "Alice" snmpSSHSecurityLevel authPriv columns: snmpTMCredentialsEntry "27" then we narrow the discussion to become purely an SSH client vs server matter. > > The side acting as an SSH server also needs some information > (which might not be a MIB table); this is similar to the 2nd > snmpSSHParametersTable in Wes's text, except we index it > by user name: > > snmpSSHIncomingTable: Remember that requests, responses, and notifications are all outgoing messages. (RFC3411 was designed to permit additional applications to be added later if desired, possibly using new SNMP protocol versions, so we shouldn't preclude the possibility there are other message types as well.) What we know in the TM is what is passed via the ASIs. If we need to use server-auth rather than user-auth for notifications, then we need to tell operators they should configure the paramstable for notifications with the appropriate host identity. Assume user "Alice" is located at host "gandalf". If the admin wants to send traps to host gandalf, rather than specifically to Alice, then put an entry for gandalf in the target/paramstable configuration. To support ACM, add gandalf to the userToGroup table in VACM (or suitable table for other ACM). This might be the same or different group than Alice belongs to. Then, in the SSHTM table, we have an entry for Alice and one for gandalf. These point to SSH entries for "adam" and "gandalf". (I changed the indexing just to show that these values are not semantically important. Human-redaable tags could still be used to make it easier for operators in the general case) When securityname=Alice, such as for get-requests, that will map to user-auth for "adam". When securityname=gandalf, that will map to host-auth for gandalf. > > index: > snmpSSHIndex "27" > columns: > snmpSSHCredentialType 1 (1 = userPublicKey, > 2 = userPassword, 3 = hostPublicKey, ...) > snmpSSHuserName "adam" (user anme when using user-auth) > snmpSSHcredential +++ (user public key to use if type=1) (user password if type=2) (host public key if type=3) > > > index: > snmpSSHindex "28" > columns: > snmpSSHUserCredentialType 3 (1 = userPublicKey, > 2 = userPassword, 3 = hostPublicKey, ...) > snmpSSHHostName "gandalf" (this is what gets > passed outside SSHTM) > snmpSSHcredential +++ (user public key to use if type=1) (user password if type=2) (host public key if type=3) > -- This table can be expanded for different types of credentials using AUGMENTS if necessary. I think the union discriminator we are using is inappropriate; We need a column for authtype (user/host) and for authcredentials (public key, password, etc., because user-auth supports multiple credential types.) Ideally, the SSH credential is really only in the SSH confguration, not in the SNMP configuration. So we might be able to get by with an SSH table containing only the index value, user- or host- auth flag, and an (implementation-dependent) index into the associated SSH config that would contain the "adam" user-auth credentials and the "gandalf" host-auth credentials. OR, if we are really lucky, the index from the SSHTM table points directly to the SSH config without needing our own SSHTable. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon May 19 09:35:19 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC3F28C188; Mon, 19 May 2008 09:35:18 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABEA53A6E9D for ; Mon, 19 May 2008 09:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kc0g0qYZCEC for ; Mon, 19 May 2008 09:34:33 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id AB9833A6E8D for ; Mon, 19 May 2008 09:33:21 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m4JGWuM8028440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 May 2008 12:32:56 -0400 (EDT) Date: Mon, 19 May 2008 12:32:56 -0400 From: Jeffrey Hutzelman To: Pasi.Eronen@nokia.com, ietfdbh@comcast.net, isms@ietf.org Message-ID: <2E819746EB9AC2E50C7484DF@sirius.fac.cs.cmu.edu> In-Reply-To: <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Friday, May 16, 2008 01:40:46 PM +0300 Pasi.Eronen@nokia.com wrote: > snmpSSHOutgoingTable: > > index: > snmpSSHTransportAddress 192.0.2.1:162 > snmpSSHSecurityName "Alice" > columns: > snmpSSHUserName "Adam" (I say "I'm Adam") > snmpSSHUserCredentialType 1 (1 = userPublicKey, > 2 = userPassword, > 3 = hostPublicKey > ... enum list) If you're going to do this, the correct thing to record is not a made-up "credential type" number, but an ssh user auth method name. The problem is that then you need some way to record information about the credentials to be used (which may be one or more keys, or just a reference to something), and that's going to be specific not only to the method being used, but also potentially to the implementation and how it is configured. For example, it's fairly straightforward that "publickey" requires a key pair of some sort, and "password" requires a password, but what does "keyboard-interactive" require? The answer is that it depends on how the server implements keyboard-interactive and what questions it is going to ask. Similarly, what does "gssapi-with-mic" require? Well, at a minimum it requires a GSS-API mechanism OID, which is really not part of the credential but a sub-negotiation parameter, like a public key algorithm identifier. And then it's going to require some mechanism-specific credentials; for example, if you're using the Kerberos GSS-API mechanism, then you need some way to get a Kerberos ticket, which might involve knowing a symmetric key, but might not, depending on your Kerberos deployment. In other words, this is difficult to standardize, and if we're going to try, we had better leave holes into which it is possible to shove whatever kinds of credentials are required, instead of telling someone that he can't use SNMP with his existing authentication infrastructure (remember: this is the goal of ISMS) because we didn't anticipate what form of credentials his NO's would have. In addition, while I don't think this is very common in practice, the SSH protocol allows servers to require _multiple_ authentications with different methods before granting a client access. So you probably actually need a set of (method, credential) tuples. > snmpSSHRemoteHostPublicKey +++ (the public key > expected from peer) Again, you can't assume a public key is involved. Not all SSH key exchange mechanisms identify hosts by public keys. Some may use certificates, or underlying security mechanisms that do not involve public keys at all. What you actually end up needing here, I think, is a set of (keyex-method, keyex-data, key-type, public-key) tuples, where either of keyex-method or key-type can be "don't care". The implication is that the host is legitimate if there is a tuple for which - keyex-method matches the key exchange used - keyex-data matches the host in some key-exchange-specific way - key-type and public-key match the key presented by the host For example, the list for the sshd running on my desktop machine might look like this: (*,*, 'ssh-rsa', 'AAAA...GR/E=') (*,*, 'ssh-dss', 'AAAA.../HRU=') ('gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==', 'host@sirius.fac.cs.cmu.edu', *,*) The first two lines match my server's two public keys; the third allows use of GSS-krb5 regardless of host key, as long as the service name matches. On the SSH server side, I think you have a much easier time of it, because SSH does more of the work for you. Once an SSH session is set up, the SSH server knows the authenticated and authorized user name of the client. How the authentication mechanisms work and how the server decides what credentials are adequate to use what username are not things I believe are in scope for ISMS. It might be appropriate for some group to define an SSH server MIB someday that allows some configuration of this policy, but I do not believe that is within our charter and I'm not convinced enough of the SSH community is engaged in this group to get it right. Fortunately, we don't have to -- simple use the SSH user name as the SNMP securityName, as we had previously agreed, and the problem is solved. If people think it is necessary to introduce a mapping from SSH user names to SNMP securityNames, I won't object. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon May 19 10:16:21 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D36D28C6D7; Mon, 19 May 2008 09:58:00 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E843A6AFE for ; Mon, 19 May 2008 09:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygKoJVyHVR4s for ; Mon, 19 May 2008 09:56:54 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 0CFC328C4C4 for ; Mon, 19 May 2008 09:44:41 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m4JGiVms028999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 May 2008 12:44:31 -0400 (EDT) Date: Mon, 19 May 2008 12:44:31 -0400 From: Jeffrey Hutzelman To: David Harrington , Pasi.Eronen@nokia.com, isms@ietf.org Message-ID: In-Reply-To: <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Friday, May 16, 2008 10:01:51 AM -0400 David Harrington wrote: > I would like to reach consensus on separating the SSHTM table from the > SSH-specific stuff, with a pointer in the SSHTM table to a row in an > SSH table. That would allow us to get from the TargetTable to the > pointer in the SSHTM table. > > SSHTM table: > > index: > snmpSSHTransportDomain snmpSSHDomain > snmpSSHTransportAddress 192.0.2.1:162 > snmpSSHSecurityName "Alice" > snmpSSHSecurityLevel authPriv > columns: > snmpTMCredentialsEntry "27" > > then we narrow the discussion to become purely an SSH client vs server > matter. I agree with this approach in principle, as it puts the SSH-specific, mechanism-specific, and implementation-specific bits where they belong. However, I'm concerned that simply mapping to a "row number" is not very helpful, because there is no SSH MIB, there is no such table, and no SSH client implementation identifies servers by small positive integers. At least one major SSH implementation does support a database such as you envision, where each entry can contain complete information about the transport address of the server, what security algorithms to use, what public keys to expect the server to present (really an index into another database), and even what user name and authentication methods to use. OpenSSH allows all of this information to be stored in its configuration file on a per-server basis, and the "host name" you type on the command line is really an index into this database, with appropriate default values being computed if no entry is found. So, I think we would be much better off if snmpTMCredentialsEntry were a string, rather than simply a number. I can certainly see an implementation which simply passes this string to the ssh client, which looks it up in its config file but also handles "bob@192.0.2.1:162" just fine, provided there is a suitable entry in the host key databse for "192.0.2.1:162". -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon May 19 10:18:59 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43F43A6852; Mon, 19 May 2008 10:18:59 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F0453A6B28 for ; Mon, 19 May 2008 10:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrPtiZFKMzeK for ; Mon, 19 May 2008 10:17:33 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 71BA93A6C5B for ; Mon, 19 May 2008 10:16:42 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id TUGB1Z00616AWCUA107Y00; Mon, 19 May 2008 17:15:42 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id TVFf1Z00B4HwxpC8S00000; Mon, 19 May 2008 17:15:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=P3WSwAEscF1VQMjn-JIA:9 a=QWgVUbWqCpqQODbPjHUA:7 a=qYZA4-SvC1jDvBRghdHk6a1dVz4A:4 a=1pxjJC3EenQA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> Date: Mon, 19 May 2008 13:15:39 -0400 Message-ID: <08ea01c8b9d3$f79ae260$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aci5z6IoOarYzzNESNKdCegVrX3DAAAApTBA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I agree. Note that I have the number "27" in quotes - it is a string. I also said "(I changed the indexing just to show that these values are not semantically important. Human-redaable tags could still be used to make it easier for operators in the general case)" I used a number in my example only so that we would not assume any semantic value to the index, like "oh, this is the user's name" such as was likely when using indices like "adam". While I did refer to "rowe number in the SSH table", I agree that we should not assume any such database format. How the "index" gets converted into something meaningful to an SSH implementation is implementation dependent. I believe this "index into some other thing" should be a string (probably an OCTET STRING rather than a Display String or SnmpAdminString, which have limitations). dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Monday, May 19, 2008 12:45 PM > To: David Harrington; Pasi.Eronen@nokia.com; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] ISMS/SSH and notifications > > --On Friday, May 16, 2008 10:01:51 AM -0400 David Harrington > wrote: > > > I would like to reach consensus on separating the SSHTM > table from the > > SSH-specific stuff, with a pointer in the SSHTM table to a row in an > > SSH table. That would allow us to get from the TargetTable to the > > pointer in the SSHTM table. > > > > SSHTM table: > > > > index: > > snmpSSHTransportDomain snmpSSHDomain > > snmpSSHTransportAddress 192.0.2.1:162 > > snmpSSHSecurityName "Alice" > > snmpSSHSecurityLevel authPriv > > columns: > > snmpTMCredentialsEntry "27" > > > > then we narrow the discussion to become purely an SSH > client vs server > > matter. > > I agree with this approach in principle, as it puts the SSH-specific, > mechanism-specific, and implementation-specific bits where > they belong. > However, I'm concerned that simply mapping to a "row number" > is not very > helpful, because there is no SSH MIB, there is no such table, > and no SSH > client implementation identifies servers by small positive integers. > > At least one major SSH implementation does support a database > such as you > envision, where each entry can contain complete information about the > transport address of the server, what security algorithms to > use, what > public keys to expect the server to present (really an index > into another > database), and even what user name and authentication methods to use. > OpenSSH allows all of this information to be stored in its > configuration > file on a per-server basis, and the "host name" you type on > the command > line is really an index into this database, with appropriate > default values > being computed if no entry is found. > > So, I think we would be much better off if > snmpTMCredentialsEntry were a > string, rather than simply a number. I can certainly see an > implementation > which simply passes this string to the ssh client, which > looks it up in its > config file but also handles "bob@192.0.2.1:162" just fine, > provided there > is a suitable entry in the host key databse for "192.0.2.1:162". > > > -- Jeff > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 20 01:54:56 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B14C3A6BC7; Tue, 20 May 2008 01:54:56 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5591E3A6983 for ; Tue, 20 May 2008 01:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.106 X-Spam-Level: X-Spam-Status: No, score=-5.106 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNRQRjov7WaS for ; Tue, 20 May 2008 01:54:53 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id D7C5D3A6843 for ; Tue, 20 May 2008 01:54:52 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4K8rD9h015826; Tue, 20 May 2008 03:54:49 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 May 2008 11:54:46 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 May 2008 11:54:45 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 May 2008 11:54:44 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72AA13A9@vaebe104.NOE.Nokia.com> In-Reply-To: <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS/SSH and notifications Thread-Index: Acir6hmVy3ZUdaUvRT6mENS3EiZoJQKBBnLAAFRQFUAABCzXUADA3n6Q References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> From: To: , X-OriginalArrivalTime: 20 May 2008 08:54:45.0114 (UTC) FILETIME=[26839DA0:01C8BA57] X-Nokia-AV: Clean Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington wrote: > > Hi, > > > > Thanks for a good explanation! I think there's a way to slightly > > refactor Wes's proposal to make it consistent with the > > architecture (since I'm making only small adjustments > > to Wes's text, I'm not quoting it all). > > > > When a PDU is sent, SSHTM will get transportAddress and > > securityName (and other information). If it needs to open a new > > connection, it will need some local information (which isn't > > necessarily a MIB table) to do so. This is almost the same as > > snmpSSHParametersTable in Wes's text, except that we need to index > > it by (transportAddress, securityName) and not parameter name > > (which isn't visible in SSHTM, right?). So the table would look > > something like this: > > Yes. and we would define this within the SSHTM specification, > presumably. If we wanted to develop one that could work for > multiple transports, with possible support for different > securitylevels, then we could add transportdomain and securityLevel > to the index so we could differentiate the different address types, > and have connections with/without privacy (for example). > > The indexing is definitely SNMP-related. The other columns seem to > be purely SSH-related. This raises the question, if we were to do a > MIB, whether the two parts should be modeled separately, with a > pointer in the SSHTM table to the relevant row (or whatever) in the > SSH datastore. What we need for ISMS is the SSHTM side of the table, > to get a mapping to an SSH-specific datastore. > > > > > snmpSSHOutgoingTable: > > > > index: > > snmpSSHTransportAddress 192.0.2.1:162 > > snmpSSHSecurityName "Alice" > > columns: > > snmpSSHUserName "Adam" (I say "I'm Adam") > > snmpSSHUserCredentialType 1 (1 = userPublicKey, > > 2 = userPassword, > > 3 = hostPublicKey > > ... enum list) > > snmpSSHUserKeyPair ++++ (the public/private > > key pair to use if 1) > > snmpSSHUserPassword ++++ (the passphrase to > > use if 2) > > snmpSSHRemoteHostPublicKey +++ (the public key > > expected from peer) > > > > Most importantly, this same table would be used when sending PDUs > > for command generator -- since SSHTM isn't supposed to know what's > > inside the PDU. > > > > (Although there's one difference in how the table would be > > typically configured; on management stations, a common > > configuration would use same string in both snmpSSHSecurityName > > and snmpSSHUserName, while on agents, they would be typically > > different.) > > You used "management station"; did you mean SSH server? The SNMPv1 > distinction between manager and agent went away with the RFC3411 > architecture. From an RFC3411 architectural perspective, both ends are > just entities that can include any of the applications. The TM, SM, > MPM, and dispatcher don't know or care what role the entity is acting > in, and in the case of a manager-to-manager Inform or agent-to-agent > Inform, there is no manager/agent pairing. We need to avoid > assumptions that TM and SM and MPM processing for manager and agent > are different; the difference only happens inside the application > layer. I agree that the processing should be the same; by "management station", I simply meant an SNMP entity that (in this context) doesn't usually call isAccessAllowed(), while the "agent" does that all the time (for both commands and notifications). > I would like to reach consensus on separating the SSHTM table from the > SSH-specific stuff, with a pointer in the SSHTM table to a row in an > SSH table. That would allow us to get from the TargetTable to the > pointer in the SSHTM table. > > SSHTM table: > > index: > snmpSSHTransportDomain snmpSSHDomain > snmpSSHTransportAddress 192.0.2.1:162 > snmpSSHSecurityName "Alice" > snmpSSHSecurityLevel authPriv > columns: > snmpTMCredentialsEntry "27" > > then we narrow the discussion to become purely an SSH client > vs server matter. This would be the table used when SSMTM acts as SSH client. When it acts as SSH server, the information needed (and how it's indexed) is different -- see more below. > > The side acting as an SSH server also needs some information > > (which might not be a MIB table); this is similar to the 2nd > > snmpSSHParametersTable in Wes's text, except we index it > > by user name: > > > > snmpSSHIncomingTable: > > Remember that requests, responses, and notifications are all outgoing > messages. (RFC3411 was designed to permit additional applications to > be added later if desired, possibly using new SNMP protocol versions, > so we shouldn't preclude the possibility there are other message types > as well.) What we know in the TM is what is passed via the ASIs. Right, my choice of terminology was poor; "snmpSSHOutgoingTable" should have been called "snmpSSHClientTable" and "snmpSSHIncomingTable" is "snmpSSHServerTable". Even for ordinary request/response, both are needed, and TM doesn't indeed know what the PDU is. > If we need to use server-auth rather than user-auth for notifications, > then we need to tell operators they should configure the paramstable > for notifications with the appropriate host identity. Assume user > "Alice" is located at host "gandalf". If the admin wants to send traps > to host gandalf, rather than specifically to Alice, then put an entry > for gandalf in the target/paramstable configuration. > > To support ACM, add gandalf to the userToGroup table in VACM (or > suitable table for other ACM). This might be the same or different > group than Alice belongs to. Yes, this would work. The admin could also decide that the host authenticating with certain host key is "authorized representative" of Alice, and simply have single Alice entiry in VACM. This would be purely a configuration issue -- in this case, the tables could contain something like this: -- table that's used when SSHTM needs to open a connection in -- SSH client role snmpSSHTMClientTable: index: snmpSSHTransportDomain snmpSSHDomain snmpSSHTransportAddress 192.0.2.1:162 snmpSSHSecurityName "Alice" snmpSSHSecurityLevel authPriv columns: snmpSSHClientParameters "27x" snmpSSHClientParameterTable: index: snmpSSHClientParameters "27x" columns: snmpSSHUserCredentialType 1 (1 = userPublicKey, 2 = userPassword, 3 = hostPublicKey ... enum list) snmpSSHUserKeyPair ++++ (the public/private key pair to use if 1) snmpSSHUserPassword ++++ (the passphrase to use if 2) snmpSSHRemoteHostPublicKey +++ (the public key expected from peer) -- table used when SSHTM establishes a connection in SSH server role snmpSSHServerTable: index: snmpSSHUserName "alicek" (peer says "I'm alicek") columns: snmpSSHSecurityName "Alice" (this is what gets passed outside SSHTM) snmpSSHServerParameters "99foo" (how the SSH client is authenticated) snmpSSHServerParameterTable: index: snmpSSHServerParameteres "99foo" columns: snmpSSHUserCredentialType 1 (1 = userPublicKey, 2 = userPassword, ...) snmpSSHUserPublicKey +++ (the public key to use if 1) snmpSSHUserPassword +++ (the correct password if 2) And I agree that of these tables, snmpSSHClientParameterTable and SNMPSSHServerParameterTable don't have to be MIB tables, but could be just data structures in the SSH implementation. Since the details will anyway depend on the implementation (and as Jeffrey pointed out, get complex for GSS-API and keyboard-interactive), that's probably the best solution. Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 20 05:39:55 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861FF3A6994; Tue, 20 May 2008 05:39:55 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A152A3A6994 for ; Tue, 20 May 2008 05:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lrp11o0o9G3F for ; Tue, 20 May 2008 05:39:53 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 1D8E63A68D4 for ; Tue, 20 May 2008 05:39:53 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id Tn0d1Z0021GXsucA40Af00; Tue, 20 May 2008 12:39:53 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id Tofr1Z0024HwxpC8T00000; Tue, 20 May 2008 12:39:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=ahfscIEc1Jw-Em-gjDwA:9 a=LRSZtmQ6ehOroaIX_YMA:7 a=PNf-XjaRnUTWJ8-RZB5PpKYUaXYA:4 a=1pxjJC3EenQA:10 a=si9q_4b84H0A:10 a=lZB815dzVvQA:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: , References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72AA13A9@vaebe104.NOE.Nokia.com> Date: Tue, 20 May 2008 08:39:51 -0400 Message-ID: <094901c8ba76$9a0dc4c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1696498986EFEC4D9153717DA325CB72AA13A9@vaebe104.NOE.Nokia.com> Thread-Index: Acir6hmVy3ZUdaUvRT6mENS3EiZoJQKBBnLAAFRQFUAABCzXUADA3n6QAAal7jA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Tuesday, May 20, 2008 4:55 AM > To: ietfdbh@comcast.net; isms@ietf.org > Subject: RE: [Isms] ISMS/SSH and notifications > [...] > Right, my choice of terminology was poor; "snmpSSHOutgoingTable" > should have been called "snmpSSHClientTable" and > "snmpSSHIncomingTable" is "snmpSSHServerTable". Even for ordinary > request/response, both are needed, and TM doesn't indeed know what > the PDU is. > [...] > > The admin could also decide that the host > authenticating with certain host key is "authorized representative" > of Alice, and simply have single Alice entiry in VACM. This would > be purely a configuration issue -- in this case, the tables > could contain something like this: > > -- table that's used when SSHTM needs to open a connection in > -- SSH client role Here's the crux of the problem from the standpoint of editing the secshell draft - how does the TM know it needs to open a connection in a client role or in a server role? The information the TM is given includes transportDomain, transportAddress, securityName, securityLevel, and a wholeMsg which is opaque to the TM. It is asked to send the message. It checks to see if there is already a connection associated with (transportDomain, transportAddress, securityName, securityLevel) and does not find one. The PDU in wholeMsg might contain an outgoing GET-REQUEST or a Trap; it doesn't know. How does the TM determine whether to open the new connection as a client or as a server? Where in the system is that decision made? what information is needed by the module making that decision? which subsystem *has* the necessary information to make that decision? If an existing connection is available, should the TM use it? Does the TM need to know in which direction that connection was opened, i.e. does it need to know whether it is acting as a client or server to reuse the connection? Do the security properties differ if the TM's role is client or server? Is the TM the right place to make that reuse decision - it is obviously the only module that understand SSH client/server roles so it appears that it must, but if the security properties are different, which module should be making that decision (or should it be the admin)? And then, Should these decisions be admin-specified deployment decisions (e.g., in a MIB), implementation decisions, or hard-coded model-specific decisions? The information below requires the client/server decision be made first, so we know which tables to look in. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > snmpSSHTMClientTable: > index: > snmpSSHTransportDomain snmpSSHDomain > snmpSSHTransportAddress 192.0.2.1:162 > snmpSSHSecurityName "Alice" > snmpSSHSecurityLevel authPriv > columns: > snmpSSHClientParameters "27x" > > snmpSSHClientParameterTable: > index: > snmpSSHClientParameters "27x" > columns: > snmpSSHUserCredentialType 1 (1 = userPublicKey, > 2 = userPassword, > 3 = hostPublicKey > ... enum list) > snmpSSHUserKeyPair ++++ (the public/private > key pair to use if 1) > snmpSSHUserPassword ++++ (the passphrase to > use if 2) > snmpSSHRemoteHostPublicKey +++ (the public key > expected from peer) > > -- table used when SSHTM establishes a connection in SSH server role > snmpSSHServerTable: > index: > snmpSSHUserName "alicek" (peer says "I'm alicek") > columns: > snmpSSHSecurityName "Alice" (this is what gets > passed outside SSHTM) > snmpSSHServerParameters "99foo" (how the SSH client is > authenticated) > snmpSSHServerParameterTable: > index: > snmpSSHServerParameteres "99foo" > columns: > snmpSSHUserCredentialType 1 (1 = userPublicKey, > 2 = userPassword, ...) > snmpSSHUserPublicKey +++ (the public key to use if 1) > snmpSSHUserPassword +++ (the correct password if 2) > > And I agree that of these tables, snmpSSHClientParameterTable and > SNMPSSHServerParameterTable don't have to be MIB tables, but could be > just data structures in the SSH implementation. Since the details > will anyway depend on the implementation (and as Jeffrey pointed > out, get complex for GSS-API and keyboard-interactive), that's > probably the best solution. > > Best regards, > Pasi > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 20 20:35:48 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17E828CA84; Tue, 20 May 2008 20:35:48 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583BB28CA84 for ; Tue, 20 May 2008 20:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+h+dZs98pYO for ; Tue, 20 May 2008 20:35:44 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id B718C28C6C9 for ; Tue, 20 May 2008 06:44:38 -0700 (PDT) X-Trace: 30326036/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.135.203 X-SBRS: None X-RemoteIP: 62.188.135.203 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAH9yMkg+vIfL/2dsb2JhbACLYKJVAw X-IronPort-AV: E=Sophos;i="4.27,515,1204502400"; d="scan'208";a="30326036" X-IP-Direction: IN Received: from 1cust203.tnt6.lnd4.gbr.da.uu.net (HELO allison) ([62.188.135.203]) by smtp.pipex.tiscali.co.uk with SMTP; 20 May 2008 14:44:18 +0100 Message-ID: <02b801c8ba76$97ea96a0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , , References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com><1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> Date: Tue, 20 May 2008 14:38:34 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "David Harrington" To: ; Sent: Friday, May 16, 2008 4:01 PM Subject: Re: [Isms] ISMS/SSH and notifications > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: Friday, May 16, 2008 6:41 AM > > To: ietfdbh@comcast.net; isms@ietf.org > > Subject: RE: [Isms] ISMS/SSH and notifications > > > > If we need to use server-auth rather than user-auth for notifications, > then we need to tell operators they should configure the paramstable > for notifications with the appropriate host identity. Assume user > "Alice" is located at host "gandalf". If the admin wants to send traps > to host gandalf, rather than specifically to Alice, then put an entry > for gandalf in the target/paramstable configuration. > I keep coming back to this because I see this as the 'open issue' - SSH authentication is asymmetric - that remains stubbornly open while the rest may be tricky but it is more along the lines of 'implementation detail'. What is the host identity (or identifier)? (The public key?) SSH (RFC4251) says "Each server host SHOULD have a host key" " The server host key is used during key exchange to verify that the client is really talking to the correct server." "Two different trust models can be used. The client has a local database that associates each host name (as typed by the user) with the corresponding public host key.... The host name-to-key association is certified by a trusted certification authority " Wes seemed to be saying that once we have validated the public key, we can use any securityName we like; you seem to be suggesting that the trust model uses the SSH local database which is the SSHTM table and the host identity becomes the securityName. Where are Alice and Gandalf in this and what is the securityName used in the ASIs and PDUs? Please clarify. Tom Petch > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 20 21:05:16 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C98828C9BB; Tue, 20 May 2008 21:05:16 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5433A7044 for ; Tue, 20 May 2008 21:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgUQdevQL6uW for ; Tue, 20 May 2008 21:05:10 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 46D6C293033 for ; Tue, 20 May 2008 15:30:50 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id Tvf01Z0011GXsucA70JV00; Tue, 20 May 2008 22:30:50 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id TyWn1Z0054HwxpC8T00000; Tue, 20 May 2008 22:30:50 +0000 X-Authority-Analysis: v=1.0 c=1 a=Lk7MDpk6QR_1V3z6nXEA:9 a=vGJn0fi8xaC4-MyVMeAA:7 a=hdHSnHe_uLpPnI21881WGBB7FvkA:4 a=86L1PGDMzkIA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Wes Hardaker'" , "'tom.petch'" References: <1696498986EFEC4D9153717DA325CB72809B78@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72890CAD@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72924F92@vaebe104.NOE.Nokia.com><029c01c8b519$721a5f80$0601a8c0@allison><06b101c8b570$dccce800$0600a8c0@china.huawei.com><02aa01c8b59c$28c6c520$0601a8c0@allison> Date: Tue, 20 May 2008 18:30:46 -0400 Message-ID: <09d501c8bac9$27e76c90$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aci16OdwKr11GBCfQgWfBcsSKwG8pgE2lrEA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Wednesday, May 14, 2008 1:35 PM [...] > Most importantly, I'm expecting to talk to another transport end that > meets my security requirements for proof of identity > requirements. SSH > proves that sufficiently for me to trust it. Thus I can > choose to call > the remote side "bob" (or "wes" too if you really wanted to) > as long as > the more important aspect is still true: they've > cryptographically shown > me I've connected to the right place given the message I want to send. > I honestly don't care about the name; I care about the cryptography. > That sounds true as far as it goes. But ... All operations use the same transport security. Some operations will go on to use access controls. For those types of operations, the admins need to preconfigure an ACM. To do that, they need to know the securityName that will be reported by the transport model for a given principal. The transport model declares who the incoming message was authenticated as being on behalf of (regardless of whehter internally that principal is called bob or wes), and this principal is who the operations in the message will be done on behalf of. So, while it is not necessarily important that the SSH sender and SSH receiver agree on the securityName as long as they agree on the cryptography, it is important that the secure transport model and the operator doing ACM pre-configuration agree on the securityName for that principal. In a similar vein, the operator configuring the target and params tables and ACM tables may have expectations of which authentications will be performed (mutual authentication, client-only, or server-only) to secure the message in transit, and the securityName specifies to the secure transprt sender which principal should be authenticated. While in our modular architecture, the ACM has no visibility into the types of authentication performed by SSH, the admin does have visibility to that information. The admin also has responsibility for configuring SSH to determine which types of authentication are required for the principal. So the params table, the ACM, the transport model, and the SSH config need to agree on who the principal is, whatever he is called. And if the authentication uses RADIUS, the admin needs to somehow correlate the securityName with the identity of the principal in RADIUS-speak as well. If the "principal" in SSH is called something different than in SNMP, that's fine, but we need to have a predictable translation so the admin knows how the principal can be tracked through the different translations that occur. Of course, since the admin needs to configure the SSH and the AAA and the target/pamas tables and the ACM on multiple systems, it really would be helpful if the principal was identified using consistent names across the nodes in the system, so if we make the securityNames used by the sender and receiver consistent, we'll be doing our part to help reduce confusion. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > tp> Whatever, what is comes down to we do not have a satisfactory > tp> identity for the ssh host, one that we can authenticate. > > I'm saying you do. You can all it whatever you want. > Specifically, you > can use the name you assigned it when you are pointing to your local > configuration that says "use this SSH transport to talk to the remote > side". The important security bits that MUST be agreed upon have been > taken care of by the SSH layer. I don't see any benefit to > throwing up > your hands and declaring the whole thing off just because SSH doesn't > offer an adequate securityName for the server side of the connection. > > Either pull it from the configuration that specified the > session in the > first place or pull it from the SSH system's configuration, > such as the > offered host name. > > This exact problem is likely to bite us with many public/private type > transport layers. Somehow I think we'd rather figure out a workable > solution than throw up our hands and declare that USM is better. > Clearly that's been shown that it isn't in the terms of the > people using > the systems. > > tp> My point was really that if the engine on which the NO > runs becomes > tp> the ssh server, then, as emerged in the interim meeting some time > tp> ago, life is simpler; this is my preferred option. > > That may be an adequate solution too, but the transport doesn't work > that way if the NO needs to open the session. And I don't think any > solution that requires a management connection first as the > only way to > deliver a notification is a suitable one for all environments. > > (I have no objection to allowing a reverse mapping so the > manager needs > to connect; in fact I've even discussed MIB objects that would be > required to support that) > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 20 21:08:10 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F87128C749; Tue, 20 May 2008 21:08:09 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7413028C81A for ; Tue, 20 May 2008 21:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdyEzfNYgT3P for ; Tue, 20 May 2008 21:08:05 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 402F728D7A7 for ; Tue, 20 May 2008 10:07:12 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id TrNB1Z01Y0FhH24A304l00; Tue, 20 May 2008 17:07:12 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id Tt7A1Z0024HwxpC8U00000; Tue, 20 May 2008 17:07:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=2FP0cb7XGjS4wjsRqWYA:9 a=j-wSRo3TZ7l92R7QxqMA:7 a=1xXWTxSD5mM5h8EB3HgnaLYrnfsA:4 a=1pxjJC3EenQA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , , References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com><1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> <02b801c8ba76$97ea96a0$0601a8c0@allison> Date: Tue, 20 May 2008 13:07:09 -0400 Message-ID: <097901c8ba9b$f1ee1b70$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <02b801c8ba76$97ea96a0$0601a8c0@allison> Thread-Index: Aci6f6fddTebYrBSQLiE/BImjNEVDQAE8D8A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I answered this post explaining the need to maintain clarity about who has what info at what point in the process. Let me see if I can answer some of these questions more directly. comments inline. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Tuesday, May 20, 2008 8:39 AM > To: David Harrington; Pasi.Eronen@nokia.com; isms@ietf.org > Subject: Re: [Isms] ISMS/SSH and notifications > > ----- Original Message ----- > From: "David Harrington" > To: ; > Sent: Friday, May 16, 2008 4:01 PM > Subject: Re: [Isms] ISMS/SSH and notifications > > > > > -----Original Message----- > > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > > Sent: Friday, May 16, 2008 6:41 AM > > > To: ietfdbh@comcast.net; isms@ietf.org > > > Subject: RE: [Isms] ISMS/SSH and notifications > > > > > > > > If we need to use server-auth rather than user-auth for > notifications, > > then we need to tell operators they should configure the paramstable > > for notifications with the appropriate host identity. Assume user > > "Alice" is located at host "gandalf". If the admin wants to > send traps > > to host gandalf, rather than specifically to Alice, then > put an entry > > for gandalf in the target/paramstable configuration. > > > > I keep coming back to this because I see this as the 'open > issue' - SSH > authentication is asymmetric - that remains stubbornly open > while the rest may > be tricky but it is more along the lines of 'implementation detail'. For me the issue of assymmetry is about operator expectations, application-level configuration, and application-level access controls. If the admin configures "alice" to have certain permissions in ACM for request-response traffic, will it be acceptable to that admin to perform only host-level authentication when sending notifications to alice? Alice will only get notifications if alice is configured as a notification target in the target and params mib tables. If the asymmetry in access control is not acceptable to the admin, then don't configure alice to get notifications. Instead, the admin can configure the target and params tables to use the securityName "gandalf" (or maybe more accurately, application "HP Openview" at SSH address 192.0.1.297:162), and send notifications to that principal rather than to the user-level princiapl alice, and then you can configure "gandalf" or "HP OpenView" in the VACM tables, with approrpiate application-level access controls for that securityName. All of this is about the operator expectations and configuring the application-level tables, including target-mib, params-mib, and VACM. At this point in the process, it is not about configuring SSH-specific parameters. > > What is the host identity (or identifier)? (The public key?) Asking this means you have now moved down into the bowels of the interface between the SSHTM and SSH. > > SSH (RFC4251) says > "Each server host SHOULD have a host key" > " The server host key is used during key exchange to verify that the > client is really talking to the correct server." > "Two different trust models can be used. > The client has a local database that associates each host name (as > typed by the user) with the corresponding public host key.... > The host name-to-key association is certified by a trusted > certification authority " > > Wes seemed to be saying that once we have validated the > public key, we can use > any securityName we like; Deep down in the transport model, we can define a mapping table to translate from SSH-specific parameters to a security-model-independent securityName that can be used elsewhere in the system as a label for the authenticated identity, no matter how that identity was authenticated, or what transport was used. The securityName cna be anything an admin wants to preconfigure into the mapping table. The preconfigured mapping table will be part of the SSHTM local datastore. If we want to avoid requiring preconfiguration of a mapping table, we can do an automatic translation, such as by using the identity function, to take some unique identifier for the authenticated identity from the SSH layer and "plugging it into" the securityname (for incoming messages). For outgoing notifications, we almost certainly need to use preconfiguration beecause the admin needs to decide who shluld get notifications, but we might be able to automate the TM-to-SSH mapping by using the opposite identity function for converting from a securityName to SSH-specific parameters. > you seem to be suggesting that the > trust model uses > the SSH local database which is the SSHTM table and the host > identity becomes > the securityName. > > Where are Alice and Gandalf in this and what is the > securityName used in the > ASIs and PDUs? I don't think mulitplexing is justified, so I don't really distinguish between "alice" and "Alice". To me the difference between 'alice" and "gandlaf" is that alice is authenticated using user-auth, and gandalf is authenticated using host-auth only. The securityName to be used in the ASIs depends on the direction. For an outgoing message, the securityname is provided by the application requesting a message be sent. For an incoming message, the securityName can be determined either by a preconfigured mapping table, or by an automated transform of something SSH-specific. Since the securityName is meant to be meaningful only at layer 8, and simply an opaque label referring to a layer 8 principal for SNMP processing, I don't care what how the value is determined; the admin should care. If we do an automated mapping, then we should try to make the securityName something that would be meaningful at layer 8. The PDU contains no securityName. It never has. You might mean "what securityName is passed in the message?" The security parameters field in an SNMPv3 message are determined solely by the security model, and in the Transport-security-model, there is no securityName passed in the SNMPv3 message. > > Please clarify. > > Tom Petch > > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 20 21:08:36 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF1628CB12; Tue, 20 May 2008 21:08:36 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3298628C9FD for ; Tue, 20 May 2008 21:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4hGMSzoeGfz for ; Tue, 20 May 2008 21:08:27 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 4334D28CE5A for ; Tue, 20 May 2008 08:02:03 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id TpoH1Z00E0lTkoCA109f00; Tue, 20 May 2008 15:02:03 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id Tr201Z00H4HwxpC8Q00000; Tue, 20 May 2008 15:02:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=iDP8a8RAehEgT9yRoakA:9 a=L8zQSqO4G1h2uPYkMiMA:7 a=t7BCi0Po486eqt_SoZAAzKwAJa0A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=1pxjJC3EenQA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'tom.petch'" , , References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com><1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> <02b801c8ba76$97ea96a0$0601a8c0@allison> Date: Tue, 20 May 2008 11:02:00 -0400 Message-ID: <095801c8ba8a$75f20e70$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <02b801c8ba76$97ea96a0$0601a8c0@allison> Thread-Index: Aci6f6fddTebYrBSQLiE/BImjNEVDQAAP6xw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Tom, Because we have modules and ASIs in the architecture, we need to keep clear as to which module has access to what parameters at which point in the process. Unfortunately, Wes's examples did not so a good job of maintaining that clarity; he used a bunch of "shortcuts" that I think are confusing people who don't live-and-breath the architecural modularity. -- The securityName is an administratively-defined identifier for a security principal. A principal might be a user, an application, a host. We don't care, it is something the operator knows about, and which is provided as a value that SNMP normally does not ever try to interpret; from the SNMP perspective it is an opaque label for some layer-8 thing the operator knows about. The main purpose of securityName is to have a security-mechanism-independent value representing the principal. Part of the original goal of securityName was to have a human-readable value that could be used in system logs to record SNMP activity, such as "daveH" or "HP OpenView" or the host machine "helpdesk machine #4". In all cases, we should not need to know what authentication mechanism was used for an operator to understand which principal the value represents. -- For outgoing messages: The application specifies transportDomain, transportAddress, securityModel, securityName, and securityLevel. What the transport model sees for parameters coming from the "rest of the system" is an opaque wholeMsg and the 4-tuple (transportDomain, transportAddress, securityName, and securityLevel), plus some miscellaneous stuff not relevant to this conversation. The transport model can use the passed 4-tuple to lookup, in an implementation-dependent manner, the SSH-specific parameters to use from the local SSH configuration datastore (such as a MIB or an ssh_XXXX.conf file). Since the SSH config doesn't know about securityName and securitylevel, and transportDomain, we will probably need to have something that is SSH-TM-specific that translates from the 4-tuple to an implementation-dependent value that can be used to lookup connections/users/servers in the SSH config, as needed. This translation is often referred to in our discussions as the "mapping" between securityName and some security-specific parameters. It may well be that in the SSH case, the thing that the 4-tuple maps to is an SSH host-key. The SSH config and operators know about host keys; nothing in SNMP does. If an operator used a host key as a securityName, then when configuring the application-level datastore, such as the target-mib or parameters mib, when that securityName reaches the SSH transport model, the mapping from securityName to an SSH-specific configuration data for a "host" might be rather simple, and would require no preconfiguration by an operator; this could easily be automated as the identity function. -- For incoming messages: SSH receives a message through some connection that has been previously established. SSH authenticates whatever is on the other end of the connection, to arrive at some type of SSH-specific identity. The SSH layer negotiates whether the connection requires user-auth or host-auth authentication, but either way it somehow comes up with an authenticated identity. Now that it has an SSH-identity, it needs to perfrm a mapping to an SNMP 4-tuple - (transportDomain, transportAddress, securityName, and securityLevel). In the SSH case, three elements of the 4-tuple ar eobvious; the securityName is less obvious. The mapping from security-specific parameters to a securityName could be done by having an operator preconfigure a "mapping" table, but it would be nice if we could automate the process to not require preconfiguration. If the incoming authentication is host-based, then, in Wes's proposal, we presumably have a host key. If we simply set the value of securityName equal to the value of the host key, we can have an automatic mapping. -- So it might be possible to use a host key as input (and output) for the mapping algorithm for both outgoing and incoming messages, when host-auth is used. This is similar to using the SSH "user name" field as input and output for the mapping algorithm for both incoming and outgoing messages, when user-auth is used. However, in both these cases, if you must know that SSH was used, then I think that violates the original design goal of securityname. -- This description does NOT include an analysis of the multiplexing that Wes proposed. Personally I think that having to multiplex simply adds complexity that is unnecessary. I hope this helps, David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Tuesday, May 20, 2008 8:39 AM > To: David Harrington; Pasi.Eronen@nokia.com; isms@ietf.org > Subject: Re: [Isms] ISMS/SSH and notifications > > ----- Original Message ----- > From: "David Harrington" > To: ; > Sent: Friday, May 16, 2008 4:01 PM > Subject: Re: [Isms] ISMS/SSH and notifications > > > > > -----Original Message----- > > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > > Sent: Friday, May 16, 2008 6:41 AM > > > To: ietfdbh@comcast.net; isms@ietf.org > > > Subject: RE: [Isms] ISMS/SSH and notifications > > > > > > > > If we need to use server-auth rather than user-auth for > notifications, > > then we need to tell operators they should configure the paramstable > > for notifications with the appropriate host identity. Assume user > > "Alice" is located at host "gandalf". If the admin wants to > send traps > > to host gandalf, rather than specifically to Alice, then > put an entry > > for gandalf in the target/paramstable configuration. > > > > I keep coming back to this because I see this as the 'open > issue' - SSH > authentication is asymmetric - that remains stubbornly open > while the rest may > be tricky but it is more along the lines of 'implementation detail'. > > What is the host identity (or identifier)? (The public key?) > > SSH (RFC4251) says > "Each server host SHOULD have a host key" > " The server host key is used during key exchange to verify that the > client is really talking to the correct server." > "Two different trust models can be used. > The client has a local database that associates each host name (as > typed by the user) with the corresponding public host key.... > The host name-to-key association is certified by a trusted > certification authority " > > Wes seemed to be saying that once we have validated the > public key, we can use > any securityName we like; you seem to be suggesting that the > trust model uses > the SSH local database which is the SSHTM table and the host > identity becomes > the securityName. > > Where are Alice and Gandalf in this and what is the > securityName used in the > ASIs and PDUs? > > Please clarify. > > Tom Petch > > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 23 04:03:28 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD4828C197; Fri, 23 May 2008 04:03:28 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD5328C21D for ; Fri, 23 May 2008 04:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MheRH9kHftI0 for ; Fri, 23 May 2008 04:03:25 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B0DAD28C1FB for ; Fri, 23 May 2008 04:03:25 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4NB2Ls9017190; Fri, 23 May 2008 06:03:17 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 May 2008 14:02:11 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 May 2008 14:02:11 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 May 2008 14:02:10 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72B36081@vaebe104.NOE.Nokia.com> In-Reply-To: <094901c8ba76$9a0dc4c0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS/SSH and notifications Thread-Index: Acir6hmVy3ZUdaUvRT6mENS3EiZoJQKBBnLAAFRQFUAABCzXUADA3n6QAAal7jAAlQH1YA== References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72AA13A9@vaebe104.NOE.Nokia.com> <094901c8ba76$9a0dc4c0$0600a8c0@china.huawei.com> From: To: , X-OriginalArrivalTime: 23 May 2008 11:02:11.0314 (UTC) FILETIME=[733E6520:01C8BCC4] X-Nokia-AV: Clean Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington wrote: > > -- table that's used when SSHTM needs to open a connection in > > -- SSH client role > > Here's the crux of the problem from the standpoint of editing the > secshell draft - how does the TM know it needs to open a connection > in a client role or in a server role? > > The information the TM is given includes transportDomain, > transportAddress, securityName, securityLevel, and a wholeMsg which > is opaque to the TM. It is asked to send the message. It checks to see > if there is already a connection associated with (transportDomain, > transportAddress, securityName, securityLevel) and does not find one. > The PDU in wholeMsg might contain an outgoing GET-REQUEST or a Trap; > it doesn't know. > > How does the TM determine whether to open the new connection as a > client or as a server? Where in the system is that decision made? what > information is needed by the module making that decision? which > subsystem *has* the necessary information to make that decision? If there's no existing connection, and the TM needs to send a message, it needs to open connection. In SSH, the party opening the connection is always in the client role, so there's no decision needed. > If an existing connection is available, should the TM use it? Does the > TM need to know in which direction that connection was opened, i.e. > does it need to know whether it is acting as a client or server to > reuse the connection? Do the security properties differ if the TM's > role is client or server? Is the TM the right place to make that reuse > decision - it is obviously the only module that understand SSH > client/server roles so it appears that it must, but if the security > properties are different, which module should be making that decision > (or should it be the admin)? I guess for e.g. Response PDUs, we usually get a tmStateReference that identifies a connection -- if that connection still exists, that would be used, right? On the other hand, if transportAddress includes both the IP address and TCP port number, a "client" connection (connection I opened) wouldn't match a "server" connection (connection the other end opened), because in the latter case, the (remote) source port number isn't the well-known port, but some ephemeral randomly selected port. (Using the same well-known port for both source and destination wouldn't work in TCP.) However, in this case, if we're sending a Response PDU, and the connection identified by tmStateReference doesn't exist any more, we can't use that port number (=the ephemeral port used as source port by the entity that sent the GetRequest) to connect back. So responses would always have to use the same transport session as the request, unless we treat transportAddress in some special fashion. Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon May 26 05:10:49 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A9F3A6B90; Mon, 26 May 2008 05:10:48 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95A03A6B6C for ; Mon, 26 May 2008 05:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9iIDVy8meAg for ; Mon, 26 May 2008 05:10:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 19E583A6851 for ; Mon, 26 May 2008 05:10:44 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE763C0003 for ; Mon, 26 May 2008 14:10:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xQhczMVZGz54; Mon, 26 May 2008 14:10:41 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D4A8C002C; Mon, 26 May 2008 14:10:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EC6545A108B; Mon, 26 May 2008 14:10:40 +0200 (CEST) Date: Mon, 26 May 2008 14:10:40 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080526121040.GA13788@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [Isms] working group meeting at the 72nd ietf in dublin X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I have seen some good progress in the past weeks to solve the SSH notification handling issue which is blocking this WG from completing the charter items. Thanks to Wes for starting the discussion off with an email clarifying a number of issues and I am confident that the WG will be able to work out the remaining details of the options and turn everything into RFC 3411 compliant language. Meanwhile, I have requested a one hour working group meeting slot for the 72nd IETF meeting in Dublin. Here are the details: Working Group Name: Integrated Security Model for SNMP (isms) Area Name: Security Area (sec) Number of Sessions: 1 Length of Session 1: 1 hour Number of Attendees: 50 Conflicts to Avoid: First Priority: opsarea opsawg netmod netconf syslog radext eap dkim keyprov sasl tls saag Second Priority: opsec I have tried to ensure that all the key contributors can attend but in case I missed something that should be listed as a first priority conflict, please let me know. /js PS: The fact that I requested a face-to-face meeting slot should not cause discussion to stop here. It would be very nice if we manage to sort out all issues well before the IETF meeting so that we can documents ready for WG last call before the meeting. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon May 26 17:26:30 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A18C3A6C0B; Mon, 26 May 2008 17:26:30 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25943A6C15 for ; Mon, 26 May 2008 17:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVPeCedfhOqo for ; Mon, 26 May 2008 17:26:28 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id F14173A6C11 for ; Mon, 26 May 2008 17:26:27 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA03.westchester.pa.mail.comcast.net with comcast id WPR81Z00A0Fqzac5306800; Tue, 27 May 2008 00:25:52 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id WQSV1Z00B4HwxpC3U00000; Tue, 27 May 2008 00:26:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=U7Mcxo1HH7QZJAhuAx0A:9 a=5Z24H3kqUH10WmXlhmwA:7 a=l6LuOS9Ux1lpigYOxO32LU6EqRUA:4 a=50e4U0PicR4A:10 From: "David Harrington" To: , References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72AA13A9@vaebe104.NOE.Nokia.com> <094901c8ba76$9a0dc4c0$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72B36081@vaebe104.NOE.Nokia.com> Date: Mon, 26 May 2008 20:26:29 -0400 Message-ID: <029e01c8bf90$4f4b7440$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <1696498986EFEC4D9153717DA325CB72B36081@vaebe104.NOE.Nokia.com> thread-index: Acir6hmVy3ZUdaUvRT6mENS3EiZoJQKBBnLAAFRQFUAABCzXUADA3n6QAAal7jAAlQH1YAAF0iWw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, > > How does the TM determine whether to open the new connection as a > > client or as a server? Where in the system is that decision > made? what > > information is needed by the module making that decision? which > > subsystem *has* the necessary information to make that decision? > > In SSH, the party opening the connection > is always in the client role, so there's no decision needed. Duh! Forget I asked. ;-) > > > If an existing connection is available, should the TM use > it? Does the > > TM need to know in which direction that connection was opened, i.e. > > does it need to know whether it is acting as a client or server to > > reuse the connection? Do the security properties differ if the TM's > > role is client or server? Is the TM the right place to make > that reuse > > decision - it is obviously the only module that understand SSH > > client/server roles so it appears that it must, but if the security > > properties are different, which module should be making > that decision > > (or should it be the admin)? > > I guess for e.g. Response PDUs, we usually get a tmStateReference that > identifies a connection -- if that connection still exists, that would > be used, right? Yes, for responses, we're all set. the securityStatereference caches the transport information to ensure the same session can be used. > On the other hand, if transportAddress includes both the IP address > and TCP port number, a "client" connection (connection I opened) > wouldn't match a "server" connection (connection the other end > opened), because in the latter case, the (remote) source port number > isn't the well-known port, but some ephemeral randomly selected port. > > (Using the same well-known port for both source and destination > wouldn't work in TCP.) > The WG decided that reuse of existing connections was acceptable, so one connection could be used for both R/R traffic and notifications. I don't think we discussed the different port numbers used and how that might impact this approach. Are you saying that reuse might be a problem? Or that the application would need to deliberately request reuse of a (presumably) existing connection (by specifying the right destination port)? (We did discuss that the receiving port would need to be listening for incoming traffic of both types.) I usually work with UDP and I don't think I've ever tried to use the same port number for source and destination. Is using the same port for source and destination a problem in TCP? or just for well-known ports? Is this something I should be recognizing as obvious and am simply overlooking? ;-) dbh _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon May 26 18:16:02 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2B7E3A6ACE; Mon, 26 May 2008 18:16:02 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E4B3A6942 for ; Mon, 26 May 2008 18:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X26GW17ZrLs7 for ; Mon, 26 May 2008 18:16:00 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id DDDED3A6921 for ; Mon, 26 May 2008 18:15:59 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA06.westchester.pa.mail.comcast.net with comcast id WLYu1Z00416LCl0560LX00; Tue, 27 May 2008 01:16:02 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id WRG11Z00K4HwxpC3S00000; Tue, 27 May 2008 01:16:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=2UyIUeAcRBP8IFefQ8QA:9 a=2f4T6lKXrGMOWwmrwZ0A:7 a=Vjjr0voUj0_it2kXyp0W2cWfjz8A:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <037201c8b070$85442300$0600a8c0@china.huawei.com> <20080526085932.GA13279@elstar.local> Date: Mon, 26 May 2008 21:16:01 -0400 Message-ID: <02a201c8bf97$3abf4680$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20080526085932.GA13279@elstar.local> thread-index: Aci/DtvpyZqxjDqJRwG0mx3H51O7dgAgXSdw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: [Isms] draft updates X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I intend to publish an updated draft before the document cut-off for Dublin. If I can, I will publish it earlier than that. I just changed divisions in my company. I am heading off to China for a month starting June 10. The next two weeks I will be pretty busy preparing for China. I expect to have some, possibly limited, time in China to work on the ISMS drafts and other drafts I am editing, plus any chair work I need to do. I started looking at the drafts to see what should be updated relative to the ongoing discussion. Unfortunately, I am not finding a lot to update. The drafts represent what I believe has been, and remains WG consensus - that the format of the LCD is implementation-dependent, and processing related to the LCD and SSH remains implementation-dependent. Most of what we are talking about is some abstractions and possible details of implementation-dependent stuff. I think it has been valuable for understanding how the problem can be addressed by people developing implementation-dependent designs. I do think it would be really unfortunate to not have some of the current discussion summarized in the document, possible in an "implementor recommendations" section. But the discussion has meandered quite a bit, and has had a lot of RFC3411-incorrect explanations, so I'm not quite sure what to write at this time. Cleaned-up proposed text is welcome. It might be helpful to include an SSHTM-MIB as a sample LCD, but we've started this and removed it and started this again and removed it. We have not reached consensus what needs to be in the LCD. Even in the current discussion, we have not reached any consensus on what the "pointer into SSH config" must be able to represent. While the current discussion seems to be reaching consensus that storing client credentials is acceptable for establishing a connection for notifications, what those credentials look like are strictly implementation-dependent. The standardized part of notification config (target and params-mib config) is already described in the TSM document, and the secshell document says that the SSH and LCD details are implementation-dependent. As far as the documents are concerned, I don't understand the edits. We need to drive the discussion to be more specific about how the text in the documents should be changed. I am not sure whether reusing an existing connection makes sense any more. It has been WG consensus, but supporting both client credentials and reuse adds unnecessary complexity. especially given some of Pasis's comments. I am also not sure how all this works for informs between two manager applications or between two agents, or if that makes any difference. I think the WG needs to go through the documents closely, with RFC3411 modularity in mind, to determine what new text is needed, what text needs to be changed, and whether the proposed approaches work in all instances. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, May 26, 2008 5:00 AM > To: David Harrington > Subject: Re: FYI: my priorities > > On Wed, May 07, 2008 at 02:30:55PM -0400, David Harrington wrote: > > > In ISMS, we have about four difficult issues that have halted our > > progress. Pasi and Wes Hardaker and Juergen and Joe Saloway > and Randy > > and others have been making progress on resolving the > issues with the > > SSH draft. As those issues get resolution, I will give my third > > highest priority to getting a new draft published. I hope > to have one > > done, and to make sure the other drafts are consistent with the new > > revision, by the Dublin meeting. > > David, > > some time has passed since this message and I am wondering whether you > will be able to revise the SSH document (and the other documents as > needed) well before the next IETF. I believe the thread Wes started > has been really helpful. But to make forward progress, we have to turn > the resulting ideas into concrete words that we all can review and > hopefully agree on - so some updated document will be very useful. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon May 26 23:25:31 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9D23A6BF8; Mon, 26 May 2008 23:25:31 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6248F28C1DB for ; Mon, 26 May 2008 23:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se+-it4KEyWu for ; Mon, 26 May 2008 23:25:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2A41C3A6858 for ; Mon, 26 May 2008 23:25:29 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C120C0010 for ; Tue, 27 May 2008 08:25:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mP3sBA14UVTj; Tue, 27 May 2008 08:25:27 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFCF9C000E; Tue, 27 May 2008 08:25:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 28C795A28B3; Tue, 27 May 2008 08:25:27 +0200 (CEST) Date: Tue, 27 May 2008 08:25:27 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080527062527.GC16024@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, to make progress on draft-ietf-isms-secshell, we need to turn results of discussion threads into concrete words to be put into the document. It will help our editor tremendously if those who have been following the discussion closely can take a look at draft-ietf-isms-secshell-10 and come up with concrete proposals what should be added or changed. It seems that some of the issues discussed recently are already covered (or at least implicitely covered) and it seems some other discussion topics are more likely candidates for an appendix where some background information is provided while yet other stuff seems to be implementation considerations since we assume SSH configuration to be out of scope for this work. So please, help us by taking a look at the document and sending out proposals what you think need to be changed or let us know that you took a look at the documents and they appear to be fine already. Thanks, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon May 26 23:50:14 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640C63A6C16; Mon, 26 May 2008 23:50:14 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766273A6C16 for ; Mon, 26 May 2008 23:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcaNUna9ryjx for ; Mon, 26 May 2008 23:50:12 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 942B63A6B4C for ; Mon, 26 May 2008 23:50:12 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4R6mQse008131; Tue, 27 May 2008 01:50:11 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 May 2008 09:49:30 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 May 2008 09:49:30 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 May 2008 09:48:39 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72BDC3B1@vaebe104.NOE.Nokia.com> In-Reply-To: <029e01c8bf90$4f4b7440$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS/SSH and notifications Thread-Index: Acir6hmVy3ZUdaUvRT6mENS3EiZoJQKBBnLAAFRQFUAABCzXUADA3n6QAAal7jAAlQH1YAAF0iWwALoKQ9A= References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com> <07dd01c8b75d$65989880$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72AA13A9@vaebe104.NOE.Nokia.com> <094901c8ba76$9a0dc4c0$0600a8c0@china.huawei.com> <1696498986EFEC4D9153717DA325CB72B36081@vaebe104.NOE.Nokia.com> <029e01c8bf90$4f4b7440$0600a8c0@china.huawei.com> From: To: , X-OriginalArrivalTime: 27 May 2008 06:49:30.0309 (UTC) FILETIME=[D03B9F50:01C8BFC5] X-Nokia-AV: Clean Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington wrote: > > On the other hand, if transportAddress includes both the IP > > address and TCP port number, a "client" connection (connection I > > opened) wouldn't match a "server" connection (connection the other > > end opened), because in the latter case, the (remote) source port > > number isn't the well-known port, but some ephemeral randomly > > selected port. > > > > (Using the same well-known port for both source and destination > > wouldn't work in TCP.) > > The WG decided that reuse of existing connections was acceptable, so > one connection could be used for both R/R traffic and notifications. > I don't think we discussed the different port numbers used and how > that might impact this approach. Are you saying that reuse might be a > problem? Or that the application would need to deliberately request > reuse of a (presumably) existing connection (by specifying the right > destination port)? (We did discuss that the receiving port would need > to be listening for incoming traffic of both types.) Let's see how this could work... Suppose a management station (apologies for sloppy use of terminology -- this is just an example :-) at 192.0.2.1 opens an SSH connection to an agent at 192.0.2.33. The TCP connection would be, for example, from 192.0.2.1/1418 (where 1418 is a random ephemeral port) to 192.0.2.33/NNN (where NNN is the port allocated by IANA for SSHTM). Let's assume that there's a GetRequest/Response exchange, but the SSH connection is left open in case it's needed in the future. The SSHTM on the agent side will have a table (or something) containing all the currently open transport connections, probably indexed by (at least) transportDomain, transportAddress, securityName, and securityLevel. The most obvious choice (but perhaps not the only one) for transportAddress in this case would 192.0.2.1/1418. If the agent now wants to send a notification, the transportAddress given by notification originator application would probably be 192.0.2.1/NNN -- so it won't match the existing transport connection (and the agent will open a new one). In general, it seems if the transportAddress contains the TCP port number, and TCP source ports are ephemeral random ports, there are situations when two simultaneous connections between two entities are needed (e.g., a connection opened by manager for sending requests will be used also for responses, but not notifications). However, I don't think this is really a problem. This comes from using TCP (and is not really SSH specific), and it seems to be exactly how the current TCP transport mapping (RFC 3430) works: TCP connections are established on behalf of the SNMP applications which initiate a transaction. In particular, command generator applications are responsible for opening TCP connections to command responder applications and notification originator applications are responsible for initiating TCP connections to notification receiver applications, which are selected as described in Section 3 of STD 62, RFC 3413 [8]. Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 27 08:57:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB863A6B4E; Tue, 27 May 2008 08:57:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2715928C0F0 for ; Tue, 27 May 2008 08:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrEQ4b+lfGw6 for ; Tue, 27 May 2008 08:57:44 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 6472428C0E2 for ; Tue, 27 May 2008 08:57:44 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 9397C39A213 for ; Tue, 27 May 2008 08:55:57 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=/qUrBJ3/rZq4KKTata8HsNjuaSs=; b=iNO80FYUAlUeCNG1ZV8F5Ym0YK9+9kkIuvWLfkwJQf/NKNoC53JQCLRGMHMBW6O/p4jzpapSBjEUe8iHJ7B+HTE5DRBUDGPXt/1nQq2FORCVZrVTQqVK8QLET9vi9L9jLCJTZa9fSdRzzaZEIyQevFLR7wJqFjJ3n4W/XvMHO58= Received: by wes.hardakers.net (Postfix, from userid 274) id 73BBA39A26F; Tue, 27 May 2008 08:55:57 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20080527062527.GC16024@elstar.local> Date: Tue, 27 May 2008 08:55:57 -0700 In-Reply-To: <20080527062527.GC16024@elstar.local> (Juergen Schoenwaelder's message of "Tue, 27 May 2008 08:25:27 +0200") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Tue, 27 May 2008 08:25:27 +0200, Juergen Schoenwaelder said: JS> It seems that some of the issues discussed recently are already JS> covered (or at least implicitely covered) and it seems some other JS> discussion topics are more likely candidates for an appendix where JS> some background information is provided while yet other stuff seems to JS> be implementation considerations since we assume SSH configuration to JS> be out of scope for this work. I think it would be a grave failing of the working group not to make the defined transport domain completely workable from an interoperable point of view for all the expected use cases. Will notifications work over SSH without a defined MIB that allows the TARGET-MIB and NOTIFICATION-MIB to be useful? Yes, assuming that vendors provide a LCD configurable implementation themselves (as David points out). How is it useful to the community to make the configuration of the needed parameters for sending a notification implementation-specific? The O&M community has long jumped up and down stating that vendors should implement a standardized configuration mechanism for their features as soon as the features themselves are implemented. How are they supposed to do that if we don't provide a standardized MIB for doing so? It's not like it's a huge undertaking and a giant MIB to write. It's a single table with a few columns that are linked to the existing notification and target tables. We're fighting over the linking and the architecture diagram, not whether it should be done or not. Where was that discussion? I don't think in this case "SSH configuration to be out of scope" is the appropriate stance to take. We're not configuring all of SSH (that'd take a lot more table). But we do need to configure our usage of SSH and how we're going to call it at a minimum level or else we're making the transport useless (at least from an interoperability standpoint). From the CG side of things, it doesn't matter as much because the CG parameters are already implementation specific (and that's ok). Every app has their own dialog box, and that works because there is only a few apps that exist and only 1-2 sets in use at a given organization. However, there are many more implementations of agents that need to be able to send notifications back to their management stations. And the need for a standardized way to configure how those notifications should be sent is critical. I don't consider this "SSH configuration". I consider it "Notification Generator" configuration. Aside: yes, the TARGET-MIB can be used for CG configuration too and MIBs like the DISMAN-EVENT-MIB will be equally as useless over SSH without a standardized configuration system there as well. I think notifications are more important, which is why I'm harping on them. But we'll get two for the price of one in this case. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 27 12:22:55 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370C43A68B8; Tue, 27 May 2008 12:22:55 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E20A3A68B3 for ; Tue, 27 May 2008 12:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBtt3pFT0ETR for ; Tue, 27 May 2008 12:22:53 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 247B23A683E for ; Tue, 27 May 2008 12:22:50 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CCA1C0011; Tue, 27 May 2008 21:15:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id e6Z+msBPoSSc; Tue, 27 May 2008 21:15:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4423EC0014; Tue, 27 May 2008 21:15:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0B5D55A3D23; Tue, 27 May 2008 21:15:00 +0200 (CEST) Date: Tue, 27 May 2008 21:14:59 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20080527191459.GB18071@elstar.local> Mail-Followup-To: Wes Hardaker , isms@ietf.org References: <20080527062527.GC16024@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, May 27, 2008 at 08:55:57AM -0700, Wes Hardaker wrote: > I don't think in this case "SSH configuration to be out of scope" is the > appropriate stance to take. We're not configuring all of SSH (that'd > take a lot more table). But we do need to configure our usage of SSH > and how we're going to call it at a minimum level or else we're making > the transport useless (at least from an interoperability standpoint). My reading of the charter is such that it does not cover the remote management and configuration of SSH itself, including things such as defining how SSH implementations identitify keys or how to remotely install keys to be used by SSH implementations. Perhaps my reading of the charter is wrong, or your issue is that you do not agree with the charter as it is written. We need to distinguish between these two things. > Aside: yes, the TARGET-MIB can be used for CG configuration too and > MIBs like the DISMAN-EVENT-MIB will be equally as useless over SSH > without a standardized configuration system there as well. I think > notifications are more important, which is why I'm harping on them. We are talking about a layered system and the WG agreed before in some other context that we treat SSH as a black box and do not try to sneak inside. I am not trying to discourage anyone from starting work on SSH configuration MIBs. However, right now, we do have well defined WG deliverables that are overdue and we should focus on getting them out before expanding the scope. Summary: I am not saying SSH configuration should not be standardized. I am just saying that we have to deliver what our charter calls for first. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 27 12:52:29 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF853A69B2; Tue, 27 May 2008 12:52:29 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2693A6A3D for ; Tue, 27 May 2008 12:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLqbkfAwPeWc for ; Tue, 27 May 2008 12:52:28 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id E72483A69B2 for ; Tue, 27 May 2008 12:52:27 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id CB8D139A213; Tue, 27 May 2008 12:50:40 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=KheUxFXp4hQe+a8Oe4dhPhUFvmI=; b=ZhxAebWZtR3JZ+Wg2jz+sc2f9tMhUCbgBOfXVJ5UpizKRzK8a6ETTyucqaAglAmSL2cfN8vRPSxE2Du0xUr2gIex1GqGVIO2AfL/669F2tZ/JJNjXRxzPc5wxKE/43sKdVOl2FVw+n6UQZHfXFrn56yMFzdMENxkoYjTOnfA8No= Received: by wes.hardakers.net (Postfix, from userid 274) id CE62239A214; Tue, 27 May 2008 12:50:39 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> Date: Tue, 27 May 2008 12:50:37 -0700 In-Reply-To: <20080527191459.GB18071@elstar.local> (Juergen Schoenwaelder's message of "Tue, 27 May 2008 21:14:59 +0200") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Tue, 27 May 2008 21:14:59 +0200, Juergen Schoenwaelder said: JS> On Tue, May 27, 2008 at 08:55:57AM -0700, Wes Hardaker wrote: >> I don't think in this case "SSH configuration to be out of scope" is the >> appropriate stance to take. We're not configuring all of SSH (that'd >> take a lot more table). But we do need to configure our usage of SSH >> and how we're going to call it at a minimum level or else we're making >> the transport useless (at least from an interoperability standpoint). JS> My reading of the charter is such that it does not cover the remote JS> management and configuration of SSH itself It doesn't cover or prohibit it. Which is half the problem. What it defines is a set of goals (yay! that's what charters really should define). JS> , including things such as defining how SSH implementations JS> identitify keys or how to remotely install keys to be used by SSH JS> implementations. JS> Perhaps my reading of the charter is wrong, or your issue is that you JS> do not agree with the charter as it is written. We need to distinguish JS> between these two things. >> Aside: yes, the TARGET-MIB can be used for CG configuration too and >> MIBs like the DISMAN-EVENT-MIB will be equally as useless over SSH >> without a standardized configuration system there as well. I think >> notifications are more important, which is why I'm harping on them. JS> We are talking about a layered system and the WG agreed before in some JS> other context that we treat SSH as a black box and do not try to sneak JS> inside. That's all well and good where it works. It doesn't, it turns out, work in a few important cases. JS> Summary: I am not saying SSH configuration should not be standardized. JS> I am just saying that we have to deliver what our charter calls for JS> first. The charter calls for six things, three of which are SSH related. The three that this discussion are: - Specify a mapping from locally-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. That hasn't been done within the current document for notification systems. The word "locally" there may be a show-stopper if you want to read it in a literal way. - Define how to use SSH between the two SNMP engines The current SSH document does this. Almost. It defines how to use it between CG's and CR operating engines. It fails, in the real world, when it comes to NGs trying to communicate with NRs. Can you declare victory because the engine's can "communicate" but can't trust the communications because there is no way to perform the needed authorization checks on the agent's side? I'm arguing no. - Specify the SSH security model for SNMP. Whoops. We can never complete. We aren't developing a SSH Security Model at all. If you want to discuss the charter literally and be sure we meet ever word in it and do nothing else then the current draft is entirely out of scope. We're defining a SSH transport model not a security model, after all. I hope you'll agree that the point of the charter is to make it possible to use existing SNMP operations over SSH in an interoperable way. We will not achieve that goal if we don't support all the existing use cases. This includes an interoperable way to send notifications from a NG in a remote device to a NR housed within the management system. Can we technically declare success? Sure (with the above caveats) Will it be a complete solution? no. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 27 13:13:36 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B735C3A6AB2; Tue, 27 May 2008 13:13:36 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C8A43A6A7B for ; Tue, 27 May 2008 13:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKsNOu2wPc9Z for ; Tue, 27 May 2008 13:13:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AF0803A6AF5 for ; Tue, 27 May 2008 13:13:32 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A87FC0016; Tue, 27 May 2008 22:13:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id flf+nuAIcoEF; Tue, 27 May 2008 22:13:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E35D8C0011; Tue, 27 May 2008 22:13:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AFE765A3EAF; Tue, 27 May 2008 22:13:32 +0200 (CEST) Date: Tue, 27 May 2008 22:13:32 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20080527201332.GA18214@elstar.local> Mail-Followup-To: Wes Hardaker , isms@ietf.org References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, May 27, 2008 at 12:50:37PM -0700, Wes Hardaker wrote: [...] > I hope you'll agree that the point of the charter is to make it possible > to use existing SNMP operations over SSH in an interoperable way. We > will not achieve that goal if we don't support all the existing use > cases. This includes an interoperable way to send notifications from a > NG in a remote device to a NR housed within the management system. > > Can we technically declare success? Sure (with the above caveats) > > Will it be a complete solution? no. I like to see forward progress on the current document set. I like to see discussions converging towards concrete things that need to be added / changed in these documents so we can put them into WG last call. I do have some doubts that the SNMP over SSH transport mapping document is the right place to define how SSH identifies keys or how to configure keys to be used by SSH. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 27 13:31:39 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6973A682C; Tue, 27 May 2008 13:31:39 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9283A682C for ; Tue, 27 May 2008 13:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Junrf5RT4Mjj for ; Tue, 27 May 2008 13:31:37 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id DD5753A69A9 for ; Tue, 27 May 2008 13:30:24 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 11D4E39A213; Tue, 27 May 2008 13:28:10 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=ePO6gJADEXiFazH3kqGJLxzqPcc=; b=FZLQXkN7cVZjQXloaD1iTYGSmMGhcc3Mh2roLzxG1TQ6p9DsIu4HmbJjRD6NhG7z+pNphCIrjRa/fux3aGDNtVZxfrbIWorTIScEhw8d1lglbcSN4yODU7qMH2p7jrxH6H/y9YpDEbrI6Av6zzInxA4TLxeAAGqk9IPTuPEt/2s= Received: by wes.hardakers.net (Postfix, from userid 274) id E7D9B39A214; Tue, 27 May 2008 13:28:09 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> <20080527201332.GA18214@elstar.local> Date: Tue, 27 May 2008 13:28:09 -0700 In-Reply-To: <20080527201332.GA18214@elstar.local> (Juergen Schoenwaelder's message of "Tue, 27 May 2008 22:13:32 +0200") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Tue, 27 May 2008 22:13:32 +0200, Juergen Schoenwaelder said: JS> I like to see forward progress on the current document set. As do we all. JS> I like to see discussions converging towards concrete things that JS> need to be added / changed in these documents so we can put them JS> into WG last call. Would that include proposals for fixing the issues I'm trying to identify as "important"? JS> I do have some doubts that the SNMP over SSH transport mapping JS> document is the right place to define how SSH identifies keys or how JS> to configure keys to be used by SSH. It's hard to tell if you're speaking as a chair or a technical contributor (or both). Are you, as chair, stating that the current solution is sufficient without notification configuration support and we should stop discussing it? -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 27 14:19:52 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFC13A69D0; Tue, 27 May 2008 14:19:52 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A2D3A69D0 for ; Tue, 27 May 2008 14:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+zzuvs75Zer for ; Tue, 27 May 2008 14:19:49 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 3F3E03A6811 for ; Tue, 27 May 2008 14:19:49 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA02.westchester.pa.mail.comcast.net with comcast id WfSb1Z05y0EZKEL520Y300; Tue, 27 May 2008 21:12:19 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.westchester.pa.mail.comcast.net with comcast id WlCJ1Z0034HwxpC3M00000; Tue, 27 May 2008 21:12:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=n43vT7MTpzIA:10 a=c9wP-4JFU4YA:10 a=r-YomyAuwnp0Td5j0qIA:9 a=INs3Rkumo2uXx87l9qgA:7 a=Q_VJ_kxVafJlqr7GOh64fIQDDnAA:4 a=D8hcdMkdJKAA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Wes Hardaker'" , References: <20080527062527.GC16024@elstar.local> Date: Tue, 27 May 2008 17:12:18 -0400 Message-ID: <03a001c8c03e$58f78160$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: thread-index: AcjAEnZ+OtaFkv7bT02zxD3OA9vN5AAHxDxg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, comments inline. > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Tuesday, May 27, 2008 11:56 AM > To: isms@ietf.org > Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 > > >>>>> On Tue, 27 May 2008 08:25:27 +0200, Juergen > Schoenwaelder said: > > JS> It seems that some of the issues discussed recently are already > JS> covered (or at least implicitely covered) and it seems some other > JS> discussion topics are more likely candidates for an appendix where > JS> some background information is provided while yet other > stuff seems to > JS> be implementation considerations since we assume SSH > configuration to > JS> be out of scope for this work. > > I think it would be a grave failing of the working group not > to make the > defined transport domain completely workable from an > interoperable point > of view for all the expected use cases. > > Will notifications work over SSH without a defined MIB that allows the > TARGET-MIB and NOTIFICATION-MIB to be useful? Yes, assuming that > vendors provide a LCD configurable implementation themselves (as David > points out). As demonstrated from our discussions, we can provide a MIB module that is indexed by tranportDomain, transportAddress, securityNme, and securityLevel, but then we don't know what the other columns must contain. The current drafts say that lookup in the LCD should be indexed by these parameters, but the actual LCD format is implementation-specific. > > How is it useful to the community to make the configuration of the > needed parameters for sending a notification implementation-specific? > The O&M community has long jumped up and down stating that vendors > should implement a standardized configuration mechanism for their > features as soon as the features themselves are implemented. I am not an implementer, so I can only take the word of those who have studied this problem. As I understand it, different SSH implementatioins use different configuration mechanisms and different APIs. To specify the LCD format beyond a standardized ASI and index columns really gets us into selecting which SSH toolkit configuration/lookup design should be used, and we do not want to dictate implementation choices. > How are > they supposed to do that if we don't provide a standardized MIB for > doing so? We have provided a standardized ASI that contains a set of standardized columns for indexing a LCD (Local Configuration Datastore). If you really want to provide a standardzied MIB, we can, but it will only have the index and probably an implementation-dependent octet string that maps to the local configuration datastore of an implementation-dependent toolkit in an implementation-dependent manner. And as Jeff points out, a single "handle" may not be enough to index some configuration use cases. Is having a MIB with a standardized index and an implementation-dependent octet string pointer to an implementation-dependent SSH-LCD better than saying "here are the values to use to index the LCD, but the actual design of the LCD is implementation-dependent"? I don't see much difference between what we have and what that would offer. > It's not like it's a huge undertaking and a giant MIB to > write. It's a single table with a few columns that are linked to the > existing notification and target tables. We're fighting over the > linking and the architecture diagram, not whether it should be done or > not. Where was that discussion? I think we already have the linkage from target and params tables, as described in Appendix A of the Transport Security Model. The TSM extracts the transportDomain, transportAddress, securityName, and securityLevel from the target and params tables, and passes them to the SSHTM via the sendMessage() ASI and the tmStateReference. SSHTM setion 5.2 says: 1) Determine the target index by extracting the transportDomain, transportAddress, securityName, and securityLevel from the tmStateReference. 2) Lookup the session in the Local Configuration Datastore using the target index if there is no session entry in the LCD, then SSHTM calls the OpenSession ASI, as described in SSHTM section 5.3. Is th etext in section 5.3 adequate to show the mapping from the transportDomain, transportAddress, securityName, and securityLevel parameters? If not, what more do you think is necessary? > > I don't think in this case "SSH configuration to be out of > scope" is the > appropriate stance to take. We're not configuring all of SSH (that'd > take a lot more table). But we do need to configure our usage of SSH > and how we're going to call it at a minimum level or else we're making > the transport useless (at least from an interoperability standpoint). Section 3.1.2 specifies required properties for interoperability. SSHTM depends on the SSH Connection Protocol. RFC4253 (SSH Connection Protocol) says: " This protocol is assumed to run on top of a secure, authenticated transport. User authentication and protection against network-level attacks are assumed to be provided by the underlying protocols." RFC4251 (SSH architecture) says: " One design goal has been to keep the base protocol as simple as possible, and to require as few algorithms as possible. However, all implementations MUST support a minimal set of algorithms to ensure interoperability (this does not imply that the local policy on all hosts would necessarily allow these algorithms). The mandatory algorithms are specified in the relevant protocol documents." RFC 4252 (SSH Authentication Protocol) says: " The only REQUIRED authentication 'method name' is "publickey" authentication. All implementations MUST support this method; however, not all users need to have public keys, and most local policies are not likely to require public key authentication for all users in the near future." From an interoperability standpoint, we could specify a minimal mandatory-to-implement configuration for use with SNMP that depends on the "publickey" algorithm used with the SSH Authentication Protocol. The "hostbased" method name is optional in SSH, but I suppose we could make it mandatory to implement for use with SSHTM, but using the already mandatory-to-implement "publickey" method would seem less burden to implementers and deployers. Would it satisfy you to say something in the Security Considerations about requiring "publickey" or "hostname" for interoperability? > > From the CG side of things, it doesn't matter as much because the CG > parameters are already implementation specific (and that's ok). Every > app has their own dialog box, and that works because there is > only a few > apps that exist and only 1-2 sets in use at a given organization. > > However, there are many more implementations of agents that need to be > able to send notifications back to their management stations. And the > need for a standardized way to configure how those > notifications should > be sent is critical. I don't consider this "SSH configuration". I > consider it "Notification Generator" configuration. > > > Aside: yes, the TARGET-MIB can be used for CG configuration > too and MIBs > like the DISMAN-EVENT-MIB will be equally as useless over SSH > without a > standardized configuration system there as well. I have not looked at the DISMAN-EVENT-MIB and its needs for SSH configuration. I would think it depends on the target and params tables, and SSHTM provides the linkage you are seeking. > I think > notifications > are more important, which is why I'm harping on them. But > we'll get two > for the price of one in this case. > -- David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue May 27 17:49:02 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7AC3A6894; Tue, 27 May 2008 17:49:02 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0C13A69DD for ; Tue, 27 May 2008 17:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohFenIWnfwbj for ; Tue, 27 May 2008 17:49:00 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [61.144.161.7]) by core3.amsl.com (Postfix) with ESMTP id 3EFE63A6817 for ; Tue, 27 May 2008 17:48:57 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1J00246ZLP24@szxga04-in.huawei.com> for isms@ietf.org; Wed, 28 May 2008 08:49:02 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K1J00E1VZLP9U@szxga04-in.huawei.com> for isms@ietf.org; Wed, 28 May 2008 08:49:01 +0800 (CST) Received: from l67563 ([10.111.12.60]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K1J004QTZLP1Z@szxml03-in.huawei.com> for isms@ietf.org; Wed, 28 May 2008 08:49:01 +0800 (CST) Date: Wed, 28 May 2008 08:49:01 +0800 From: li chunxiu To: isms@ietf.org Message-id: <004b01c8c05c$9f00e7a0$3c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_brEuZqqL0oaX6va4rnIXhg)" Thread-index: AcjAIcMd3EqFoTjWR0GbZMVYRu3wIAAOtNWQ Subject: [Isms] FW: I-D ACTION:draft-li-isms-svacm-00.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_brEuZqqL0oaX6va4rnIXhg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, May 28, 2008 1:45 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-li-isms-svacm-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Simplified View-based Access Control Model (SVACM) for > the Simple Network Management Protocol (SNMP) > Author(s) : C. Li, Y. Li > Filename : draft-li-isms-svacm-00.txt > Pages : 24 > Date : 2008-5-26 > > This document introduces a Simplified View-based Access Control Model > (SVACM) for the Simple Network Management Protocol (SNMP), which is > useful for the access control application of SNMP protocol. > > This document describes the procedure of access control in SVACM with > Remote Authentication Dial In User Service (RADIUS) server for > authorization. > This document also includes a Management Information Base (MIB) for > remotely managing the configuration parameters for SVACM. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-li-isms-svacm-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --Boundary_(ID_brEuZqqL0oaX6va4rnIXhg) Content-type: Message/External-body; name=draft-li-isms-svacm-00.txt Content-transfer-encoding: 7bit Content-disposition: attachment; filename=draft-li-isms-svacm-00.txt Content-Type: text/plain Content-ID: <2008-5-27104107.I-D@ietf.org> --Boundary_(ID_brEuZqqL0oaX6va4rnIXhg) Content-type: text/plain; name=ATT00034.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00034.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Boundary_(ID_brEuZqqL0oaX6va4rnIXhg) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms --Boundary_(ID_brEuZqqL0oaX6va4rnIXhg)-- From isms-bounces@ietf.org Wed May 28 01:54:20 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85E13A6C7D; Wed, 28 May 2008 01:54:20 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A849C3A6B1F for ; Wed, 28 May 2008 01:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exIDEC7aaO58 for ; Wed, 28 May 2008 01:54:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 391EC3A6805 for ; Wed, 28 May 2008 01:54:18 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34961C0008; Wed, 28 May 2008 10:54:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TCHYmznejwts; Wed, 28 May 2008 10:54:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6ECEFC000D; Wed, 28 May 2008 10:54:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3DD305A42B9; Wed, 28 May 2008 10:54:19 +0200 (CEST) Date: Wed, 28 May 2008 10:54:19 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20080528085419.GA18649@elstar.local> Mail-Followup-To: Wes Hardaker , isms@ietf.org References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> <20080527201332.GA18214@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, May 27, 2008 at 01:28:09PM -0700, Wes Hardaker wrote: > JS> I like to see discussions converging towards concrete things that > JS> need to be added / changed in these documents so we can put them > JS> into WG last call. > > Would that include proposals for fixing the issues I'm trying to > identify as "important"? I think it does not help to discuss such an abstract and in my view also not very precise question. I want to see concrete proposals how to change the document(s) and then we can evaluate them one by one and see (a) where we have consensus and (b) whether we can all agree this is in the scope of the charter. > JS> I do have some doubts that the SNMP over SSH transport mapping > JS> document is the right place to define how SSH identifies keys or how > JS> to configure keys to be used by SSH. > > It's hard to tell if you're speaking as a chair or a technical > contributor (or both). Are you, as chair, stating that the current > solution is sufficient without notification configuration support and we > should stop discussing it? As chair, I am saying we should concentrate on the WG documents we already have and try to get them finalized. As technical contributor, I believe SSH configuration is something that belongs into an SSH MIB module and not into an SNMP over SSH transport mapping MIB module. As chair, I believe writing an SSH MIB module is not part of our current charter. Hopefully this makes things clearer. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 28 07:57:12 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3DD28C131; Wed, 28 May 2008 07:57:12 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D66C28C131 for ; Wed, 28 May 2008 07:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLF3e+kzCJiO for ; Wed, 28 May 2008 07:57:10 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 0A0F928C126 for ; Wed, 28 May 2008 07:57:09 -0700 (PDT) X-Trace: 35087223/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.60.30 X-SBRS: None X-RemoteIP: 213.116.60.30 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoEACMPPUjVdDwe/2dsb2JhbACLaqJUAw X-IronPort-AV: E=Sophos;i="4.27,555,1204502400"; d="scan'208";a="35087223" X-IP-Direction: IN Received: from 1cust30.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.30]) by smtp.pipex.tiscali.co.uk with SMTP; 28 May 2008 15:57:11 +0100 Message-ID: <009901c8c0ca$123be0e0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , , References: <07c601c8b6d3$69bce180$0600a8c0@china.huawei.com><1696498986EFEC4D9153717DA325CB72A13B84@vaebe104.NOE.Nokia.com><07dd01c8b75d$65989880$0600a8c0@china.huawei.com><1696498986EFEC4D9153717DA325CB72AA13A9@vaebe104.NOE.Nokia.com><094901c8ba76$9a0dc4c0$0600a8c0@china.huawei.com><1696498986EFEC4D9153717DA325CB72B36081@vaebe104.NOE.Nokia.com> <029e01c8bf90$4f4b7440$0600a8c0@china.huawei.com> Date: Wed, 28 May 2008 12:25:51 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org ----- Original Message ----- From: "David Harrington" To: ; Sent: Tuesday, May 27, 2008 2:26 AM Subject: Re: [Isms] ISMS/SSH and notifications > > > > (Using the same well-known port for both source and destination > > wouldn't work in TCP.) > > > The WG decided that reuse of existing connections was acceptable, so > one connection could be used for both R/R traffic and notifications. > I don't think we discussed the different port numbers used and how > that might impact this approach. Are you saying that reuse might be a > problem? Or that the application would need to deliberately request > reuse of a (presumably) existing connection (by specifying the right > destination port)? (We did discuss that the receiving port would need > to be listening for incoming traffic of both types.) > > I usually work with UDP and I don't think I've ever tried to use the > same port number for source and destination. Is using the same port > for source and destination a problem in TCP? or just for well-known > ports? Is this something I should be recognizing as obvious and am > simply overlooking? ;-) > I have seen the same (well-known) port used as UDP source and destination quite frequently; I have wondered why and then why not? TCP is different and the TCP source port is usually used cyclically, starting at some value, may be determined by the implementation but sometimes appears to be pseudo-random. But does it have to be? (I remain convinced that reusing a CR/CG connection for a NO+CR entity remains the simplest deployment, even if the CR/CG is just used for the retrieval of a one well-known object eg snmpTsmHereiamsendmenotificationsplease ) Tom Petch > dbh > > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 28 08:42:43 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C673A6C85; Wed, 28 May 2008 08:42:43 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37AC33A6C85 for ; Wed, 28 May 2008 08:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4f9y4inJjh0 for ; Wed, 28 May 2008 08:42:41 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 5D2163A6C2E for ; Wed, 28 May 2008 08:42:41 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id ED98439A213; Wed, 28 May 2008 08:40:52 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=EhWsdmk7O802do8PuRBqJhNxtlY=; b=M+ZoQqBFdrBqqaQyBVHDZ9xZckWyIFD1C76gl+tEd0o72RDAXkjw31lTCbtl9kOVYKVVsVfXaU2ABjYDpf9J7u5zAvSdDUjhmHr5wzhelauLz+OHDeAIMed6Vq+ZOsABmkmj+3Eg1nxiX4dArLVHv2oaM21UBstoEyC2BPDRYsQ= Received: by wes.hardakers.net (Postfix, from userid 274) id C8E3839A214; Wed, 28 May 2008 08:40:52 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> <20080527201332.GA18214@elstar.local> <20080528085419.GA18649@elstar.local> Date: Wed, 28 May 2008 08:40:52 -0700 In-Reply-To: <20080528085419.GA18649@elstar.local> (Juergen Schoenwaelder's message of "Wed, 28 May 2008 10:54:19 +0200") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 28 May 2008 10:54:19 +0200, Juergen Schoenwaelder said: JS> I want to see concrete proposals how to change the document(s) and JS> then we can evaluate them one by one and see (a) where we have JS> consensus and (b) whether we can all agree this is in the scope of the JS> charter. That doesn't help me. My question was: If I come up with a technical solution that is insertable into the document that is the form of a MIB that allows for minimal setup to allow notifications to be sent from a NG to a NR using the TARGET-MIB, NOTIFICATION-MIB and new objects would that be an acceptable thing to consider? I don't want to spend the effort to give you a concrete proposal if you will decide later that (b) above takes precedence and even though the proposal is sound it's now out of scope of the charter so the work was in vein. You are saying two things at once: 1) do work 2) the work is (possibly) out of scope. No one wants to do work if it's going to be declared of out scope. JS> As chair, I believe writing an SSH MIB module is not part of our JS> current charter. Making a SSH usable for SNMP is, though, and with whatever work that might entail. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 28 08:57:48 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCC23A6CBC; Wed, 28 May 2008 08:57:48 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD163A6CBB for ; Wed, 28 May 2008 08:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xA3k3zPtTt5M for ; Wed, 28 May 2008 08:57:46 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id B7A2628C231 for ; Wed, 28 May 2008 08:56:48 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA06.westchester.pa.mail.comcast.net with comcast id X3ul1Z0020xGWP85600Y00; Wed, 28 May 2008 15:56:56 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA12.westchester.pa.mail.comcast.net with comcast id X3vt1Z00E4HwxpC3Y00000; Wed, 28 May 2008 15:55:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=n43vT7MTpzIA:10 a=c9wP-4JFU4YA:10 a=48vgC7mUAAAA:8 a=4Mhsl8aaUBEal6eKCIAA:9 a=ydGHfsaCn0p5hnyOkOgA:7 a=lIvr3R3gzQxg7aeGKhsf6Ts62cQA:4 a=i53e45ETfeoA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Wes Hardaker'" References: <20080527062527.GC16024@elstar.local><20080527191459.GB18071@elstar.local><20080527201332.GA18214@elstar.local><20080528085419.GA18649@elstar.local> Date: Wed, 28 May 2008 11:55:53 -0400 Message-ID: <040f01c8c0db$4f7de280$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: thread-index: AcjA2YAe5qxi54FBRRymnVhVnB/Q9wAAQnNg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Wes, As chair of other WGs, I have had to make similar determinations. If you write a MIB module, the WG/chairs/ADs will need to determine if it is in scope. They will need to determine if the work is well-constrained and achieveable, or if the work opens a tarpit that is definiteky out of scope. Without seeing it, the chairs, WG, and ADs cannot necessarily tell whether it would be out of scope. If you do the work, there is no reason it could not be published. Even if it is decided that the MIB is out of scope, you can always publish it as an individual draft. And if the WG recharters, and work remains to be done on the MIB, then the WG might choose to take on that work, and the IESG might approve such a charter item. Without seeing the proposal, I do not think a chair can determine whether it is appropriate for the WG. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Wednesday, May 28, 2008 11:41 AM > To: Wes Hardaker > Cc: isms@ietf.org > Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 > > >>>>> On Wed, 28 May 2008 10:54:19 +0200, Juergen > Schoenwaelder said: > > JS> I want to see concrete proposals how to change the document(s) and > JS> then we can evaluate them one by one and see (a) where we have > JS> consensus and (b) whether we can all agree this is in the > scope of the > JS> charter. > > That doesn't help me. My question was: > > If I come up with a technical solution that is insertable into the > document that is the form of a MIB that allows for minimal setup to > allow notifications to be sent from a NG to a NR using the > TARGET-MIB, NOTIFICATION-MIB and new objects would that be an > acceptable > thing to consider? > > I don't want to spend the effort to give you a concrete > proposal if you > will decide later that (b) above takes precedence and even though the > proposal is sound it's now out of scope of the charter so the work was > in vein. > > You are saying two things at once: 1) do work 2) the work is > (possibly) > out of scope. No one wants to do work if it's going to be declared of > out scope. > > JS> As chair, I believe writing an SSH MIB module is not part of our > JS> current charter. > > Making a SSH usable for SNMP is, though, and with whatever work that > might entail. > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 28 09:06:07 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B9D28C117; Wed, 28 May 2008 09:06:07 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E7F3A67AD for ; Wed, 28 May 2008 09:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmdYXhtsRNvc for ; Wed, 28 May 2008 09:06:03 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 0D6CD28C0DE for ; Wed, 28 May 2008 09:06:02 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 9EF8A39A213; Wed, 28 May 2008 09:04:14 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=X4vfOEdMMLrlsijNLMuBE4M/ZDI=; b=XmF6Wm/bqlW8tm0qcqgpt7HZDfTY0d/IzT7RB5YxSwcM6SNpLZ1vlzO992tihmygAzIC3q/rcUcmGjlL6yEuoHlPhA0GR+no/yLPhF3iksypZJCNXq/HyNv197kz8km/mXIQ7f3/y67UOr5skL8deP7S/C4D/sjk+WgdUXjIIYg= Received: by wes.hardakers.net (Postfix, from userid 274) id 767A239A214; Wed, 28 May 2008 09:04:14 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> <20080527201332.GA18214@elstar.local> <20080528085419.GA18649@elstar.local> <040f01c8c0db$4f7de280$0600a8c0@china.huawei.com> Date: Wed, 28 May 2008 09:04:14 -0700 In-Reply-To: <040f01c8c0db$4f7de280$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 28 May 2008 11:55:53 -0400") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 28 May 2008 11:55:53 -0400, "David Harrington" said: DH> Without seeing the proposal, I do not think a chair can determine DH> whether it is appropriate for the WG. I understand your points. But hopefully you'll understand mine in that if the decision has already been made (which is the question at hand) then it'll affect the motivation of people to work on and review the work. DH> you can always publish it as an individual draft. Yep. But that means they'll be less community involvement, which may not be a good thing. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 28 09:24:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3A23A6AD0; Wed, 28 May 2008 09:24:26 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09AB3A6AE4 for ; Wed, 28 May 2008 09:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.14 X-Spam-Level: X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAhtbmewRN5o for ; Wed, 28 May 2008 09:24:24 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id E98653A6AC7 for ; Wed, 28 May 2008 09:24:23 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA03.westchester.pa.mail.comcast.net with comcast id X4LA1Z0030cZkys5300t00; Wed, 28 May 2008 16:23:49 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id X4QP1Z00E4HwxpC3W00000; Wed, 28 May 2008 16:24:27 +0000 X-Authority-Analysis: v=1.0 c=1 a=n43vT7MTpzIA:10 a=c9wP-4JFU4YA:10 a=h42nG6X2noj02tpQZjEA:9 a=KAKZIc9qB209QZuCzwMq3KRP4RcA:4 a=i53e45ETfeoA:10 a=D8hcdMkdJKAA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Wes Hardaker'" References: <20080527062527.GC16024@elstar.local><20080527191459.GB18071@elstar.local><20080527201332.GA18214@elstar.local><20080528085419.GA18649@elstar.local> Date: Wed, 28 May 2008 12:24:22 -0400 Message-ID: <041001c8c0df$4c2767b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: thread-index: AcjA2YAe5qxi54FBRRymnVhVnB/Q9wAA5rew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Wes, > If I come up with a technical solution in the form of a MIB that allows for minimal setup to > allow notifications to be sent from a NG to a NR using the > TARGET-MIB, NOTIFICATION-MIB and new objects would that be an > acceptable > thing to consider? I am trying to understand what you think is missing that we need to address. I think notifications can be sent from an NG to an NR using the TARGET-MIB and NOTIFICATION-MIB and an implementation-dependent SSH LCD indirectly indexed by domain, address, name, and level. What is Appendix A of TSM missing that is not addressed by the ASIs and elements of procedures of the secshell document? What new MIB objects do you think are necessary for TSM and/or SSHTM? Do you want an explicit MIB INDEX capturing the domain, address, name, and level? Would it satisfy you if the only other column contained implementation-dependent "index" to perform a lookup in an implementation-dependent SSH LCD?Are you looking for a standardized "index" into implementation-dependent SSH LCDs? Are you looking for a mandatory-to-implement algorithm beyond what SSH already provides? dbh _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 28 10:04:32 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DF23A6AE4; Wed, 28 May 2008 10:04:32 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F6A3A6AB1 for ; Wed, 28 May 2008 10:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH3Mnc08MYfd for ; Wed, 28 May 2008 10:04:30 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id A3BD53A6C86 for ; Wed, 28 May 2008 10:04:13 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 5014839A213; Wed, 28 May 2008 10:02:25 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=HvAJAGjq7eCimSZ8H0nuzvxUNYY=; b=OZxTdv0UrOuujXdYCiR/UH7aofiFnjA9nCFGRUZd8R2pzcB4onhW3LtjDAVSM7mYWBX18Ns5I3ITY1eguPYCs0OSFdd3LBbmChUpXJ+dzKEEt9b8ntO/Iu7HcCnaQOavG9IUsfUM1VTRgULS9ANtaD1lVrTgK30M8YLWAhEzjcw= Received: by wes.hardakers.net (Postfix, from userid 274) id 267FE39A214; Wed, 28 May 2008 10:02:25 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> <20080527201332.GA18214@elstar.local> <20080528085419.GA18649@elstar.local> <041001c8c0df$4c2767b0$0600a8c0@china.huawei.com> Date: Wed, 28 May 2008 10:02:24 -0700 In-Reply-To: <041001c8c0df$4c2767b0$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 28 May 2008 12:24:22 -0400") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 28 May 2008 12:24:22 -0400, "David Harrington" said: DH> I think notifications can be sent from an NG to an NR using the DH> TARGET-MIB and NOTIFICATION-MIB and an implementation-dependent SSH ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DH> LCD indirectly indexed by domain, address, name, and level. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What does the NG use for a SecurityName as an input to the VACM for authorization purposes? What user credentials are used on the NG as a client to open the SSH session? (I suspect this is what you mean by the ^^^ mapping section above) Can those two questions be answered in an interoperable way via interoperable configuration knobs? If the answer to this is "it can be done only via implementation-dependent methods" then I think that's a failure case. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 28 10:04:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FC203A691C; Wed, 28 May 2008 10:04:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00DA3A6888 for ; Wed, 28 May 2008 10:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVmDWT9aczMp for ; Wed, 28 May 2008 10:04:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 99E983A67F4 for ; Wed, 28 May 2008 10:04:17 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 879B4C0007; Wed, 28 May 2008 19:04:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u4P0gaQpmOAB; Wed, 28 May 2008 19:04:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E64B8C000B; Wed, 28 May 2008 19:04:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AEE7D5A5005; Wed, 28 May 2008 19:04:14 +0200 (CEST) Date: Wed, 28 May 2008 19:04:14 +0200 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20080528170414.GA19580@elstar.local> Mail-Followup-To: "tom.petch" , David Harrington , Pasi.Eronen@nokia.com, isms@ietf.org References: <029e01c8bf90$4f4b7440$0600a8c0@china.huawei.com> <009901c8c0ca$123be0e0$0601a8c0@allison> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <009901c8c0ca$123be0e0$0601a8c0@allison> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org Subject: Re: [Isms] ISMS/SSH and notifications X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Wed, May 28, 2008 at 12:25:51PM +0200, tom.petch wrote: > TCP is different and the TCP source port is usually used cyclically, starting at > some value, may be determined by the implementation but sometimes appears to be > pseudo-random. But does it have to be? > > (I remain convinced that reusing a CR/CG connection for a NO+CR entity remains > the simplest deployment, even if the CR/CG is just used for the retrieval of a > one well-known object eg snmpTsmHereiamsendmenotificationsplease ) As I pointed out in some WG meeting, reusing a SSH (or simply TCP) connection means to install SNMP target configuration that is only meaningful as long as the connection exists. I doubt it very much that there is a portable way to share a listening TCP endpoint and a connection TCP endpoint; I would be surprised if this works at all in any meaningful way if I look at the TCP state machine. Hence, when the SSH (or simply TCP) connection goes away, the SNMP target configuration pointing to it needs to be garbage collected. This implies that once the TCP connection is gone, there is either no way to send a notification anymore or you have to have a backup SNMP target configuration to be used after the connection has disappeared (which again requires configuration information so that the SNMP engine hosting the notification originator knows about this fail-over situation). To make this work, several extensions to the SNMP target tables are needed and I recall that we abstained from this when we wrote the SNMP over TCP mapping since all this creates several new failure modes. /js (speaking as technical contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 28 11:32:59 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C773A6B83; Wed, 28 May 2008 11:32:59 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667B33A6B97 for ; Wed, 28 May 2008 11:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpqvAGxkMMhx for ; Wed, 28 May 2008 11:32:46 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 73DBA3A6987 for ; Wed, 28 May 2008 11:32:21 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA04.westchester.pa.mail.comcast.net with comcast id X06p1Z0020EZKEL540Us00; Wed, 28 May 2008 18:32:29 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.westchester.pa.mail.comcast.net with comcast id X6YP1Z00d4HwxpC3M00000; Wed, 28 May 2008 18:32:25 +0000 X-Authority-Analysis: v=1.0 c=1 a=n43vT7MTpzIA:10 a=c9wP-4JFU4YA:10 a=zny4BAL468lBhs-Mg6gA:9 a=bE6yCW6CjmzGGk9X4Y0A:7 a=ljX47LWUIuNUbVYHQ538iMRVqbQA:4 a=D8hcdMkdJKAA:10 a=86L1PGDMzkIA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Wes Hardaker'" References: <20080527062527.GC16024@elstar.local><20080527191459.GB18071@elstar.local><20080527201332.GA18214@elstar.local><20080528085419.GA18649@elstar.local><041001c8c0df$4c2767b0$0600a8c0@china.huawei.com> Date: Wed, 28 May 2008 14:32:23 -0400 Message-ID: <000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjA5OGYaF8zYxU0TQe5BgrkzJcYjgAAu8Ug In-Reply-To: Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Wednesday, May 28, 2008 1:02 PM > To: David Harrington > Cc: 'Wes Hardaker'; isms@ietf.org > Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 > > >>>>> On Wed, 28 May 2008 12:24:22 -0400, "David Harrington" > said: > > DH> I think notifications can be sent from an NG to an NR using the > DH> TARGET-MIB and NOTIFICATION-MIB and an > implementation-dependent SSH > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > DH> LCD indirectly indexed by domain, address, name, and level. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > What does the NG use for a SecurityName as an input to the VACM for > authorization purposes? It uses the securityName specified in snmpTargetParamsSecurityName. > > What user credentials are used on the NG as a client to open > the SSH session? > (I suspect this is what you mean by the ^^^ mapping section above) It uses the credentials it gets from the SSH local configuration datastore. this might be a key stored in the ssh_keys directory, for example. How it finds the right credentials is implementation-specific because different SSH implementations might store the creentials in different locations or in different formats. In SSHTM, there is an LCD indexed by domain, address, securityname, securitylevel that indicates how to get the appropriate set of SSH credentials. This must be implementation-dependent because we do not know which SSH implementation is going to be used. > > > Can those two questions be answered in an interoperable way via > interoperable configuration knobs? The first question is "yes, absolutely"; the TargetParamsTable is a configuration database for the NG application, and it provides the securityModel, securityname and securitylevel to be used when the NG is performing access control. The TargetTable is also part of the configuration database for the NG application, and it provides the transportDomain and transportAddress to be used. > If the answer to this is > "it can be > done only via implementation-dependent methods" then I think that's a > failure case. We have standardized the index (transportDomain, transportAddress, securityName, and securityLevel) to lookup the corresponding implementation-dependent SSH credentials to open the SSH session. For comparison, look at the usmUsertable. The authKey - the credential that is actually used by the authentication protocol such as HMAC-MD5-96 - is not visible via SNMP: " authKey If messages sent on behalf of this user can be authenticated, the (private) authentication key for use with the authentication protocol. Note that a user's authentication key will normally be different at different authoritative SNMP engines. The authKey is not accessible via SNMP. The length requirements of the authKey are defined by the authProtocol in use." The mapping from the usmSecurityName (or the identical usmUserName) to the (for example, HMAC-MD5-96) authkey is implementation-dependent. We only need a similar implementation-dependent mapping. We do not need all the other stuff provided in the usmUsertable - we know the transportDomain and transportAddress so we don't need engineID in the INDEX; we are using the identity transform between SSH user name and SNMP securityName; we know that SSH is our auth and priv protocol (and which auth and priv mechanisms SSH is configured to use to perform auth and priv for the user name is not our business); and we are not handling SSH key changes via SNMP. dbh > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 28 12:36:33 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D433A6AEA; Wed, 28 May 2008 12:36:33 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14483A6AEA for ; Wed, 28 May 2008 12:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbaCygKXKvlk for ; Wed, 28 May 2008 12:36:31 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id C00483A69EE for ; Wed, 28 May 2008 12:36:31 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id D3D4B39A213; Wed, 28 May 2008 12:34:42 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=BLBGw8BNogK1+zYbuA/Lqjn4Uf4=; b=IqtH5PZHu3JRhxzJ08E8wJBMUiR0iUo7qSOzwTZys9TfpdWWy0S3RCnf8cMG1TXNff3YZnt43oED+X5CYgnskGXYaTNVrxpkM2mEFLHxsyOkVAcQmelXiTYp8tX9ZlvsuOugdSf3ksnwKpsO2qC1V6e0aT0xrqiqrzKoycy7sGE= Received: by wes.hardakers.net (Postfix, from userid 274) id AA60339A214; Wed, 28 May 2008 12:34:42 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> <20080527201332.GA18214@elstar.local> <20080528085419.GA18649@elstar.local> <041001c8c0df$4c2767b0$0600a8c0@china.huawei.com> <000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com> Date: Wed, 28 May 2008 12:34:42 -0700 In-Reply-To: <000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 28 May 2008 14:32:23 -0400") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Wed, 28 May 2008 14:32:23 -0400, "David Harrington" said: >> What does the NG use for a SecurityName as an input to the VACM for >> authorization purposes? DH> It uses the securityName specified in snmpTargetParamsSecurityName. (this is actually different than I last remember reading; but that's fine with me... I thought that was still up for debate, but there is a thread I haven't finished reading so I'm sure it must be in there). >> What user credentials are used on the NG as a client to open the SSH >> session? DH> It uses the credentials it gets from the SSH local configuration DH> datastore. I assume this also includes the acceptable server-side credentials (eg, host certificate) that is expected on the other end? DH> We have standardized the index (transportDomain, transportAddress, DH> securityName, and securityLevel) to lookup the corresponding DH> implementation-dependent SSH credentials to open the SSH session. Ok, just to be sure. In order for me to set up 10k boxes to send notifications to a notification receiver or two I need to first configure through an out-of-band mechanism the user's credentials and the server's expected credentials (host certificate) that the notification receiver must present? Right? And if I need to add another notification receiver I need to manually out-of-band reconfigure all 10k nodes right? Or if I change the NR certificate (say on a regular basis of every year) then I need to manually out-of-band reconfigure the device? In a implementation-dependent way. If that's acceptable to you, then the conversation is probably at a stand still. DH> For comparison, look at the usmUsertable. The usmUserTable requires a single bootstap, not endless. That's a huge difference. And, with SSH the bootstrap is actually possibly handled by prior management station credentials (ssh users already set up for coming into an ssh agent). But devices today like don't have outgoing ssh credentials in place. That mapping you're referring to into the LCD doesn't exist today and thus must be manually configured for notifications to be usable. I'm not saying it can't be done. It can be. Painfully and in a non-interoperable way. Once that's in place, yes notifications can be sent in an interoperable way. I really do understand the reasons behind wanting to shelve this and saying "we're not going to do configuration at that level of detail". But it will affect scalability of the results. DH> The authKey - the credential that is actually used by the DH> authentication protocol such as HMAC-MD5-96 - is not visible via DH> SNMP But it can be changed and uploaded. I don't care about reading it as much as I do writing it. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed May 28 14:04:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDAD63A6B15; Wed, 28 May 2008 14:04:34 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466073A6BA1 for ; Wed, 28 May 2008 14:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mXT6ECciAO3 for ; Wed, 28 May 2008 14:04:31 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id DCFBE3A6831 for ; Wed, 28 May 2008 14:04:30 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA01.westchester.pa.mail.comcast.net with comcast id X8qQ1Z00A0xGWP85101800; Wed, 28 May 2008 21:04:38 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA12.westchester.pa.mail.comcast.net with comcast id X94X1Z0034HwxpC3Y00000; Wed, 28 May 2008 21:04:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=n43vT7MTpzIA:10 a=c9wP-4JFU4YA:10 a=hObF7l2YRABirBAE3w0A:9 a=AcdPurUfvOgDFjJUxYYA:7 a=Wh9QXqUtEp_upnl5J90BrOI-BpYA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Wes Hardaker'" References: <20080527062527.GC16024@elstar.local><20080527191459.GB18071@elstar.local><20080527201332.GA18214@elstar.local><20080528085419.GA18649@elstar.local><041001c8c0df$4c2767b0$0600a8c0@china.huawei.com><000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com> Date: Wed, 28 May 2008 17:04:30 -0400 Message-ID: <002f01c8c106$6cf836f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjA+il128fzK903R7i74g/+k6e6swABd+Bg In-Reply-To: Cc: isms@ietf.org Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > >> What does the NG use for a SecurityName as an input to the VACM for > >> authorization purposes? > > DH> It uses the securityName specified in > snmpTargetParamsSecurityName. > > (this is actually different than I last remember reading; but that's > fine with me... I thought that was still up for debate, but > there is a > thread I haven't finished reading so I'm sure it must be in there). See Transport Security Model Appendix A. > > >> What user credentials are used on the NG as a client to > open the SSH > >> session? > > DH> It uses the credentials it gets from the SSH local configuration > DH> datastore. > > I assume this also includes the acceptable server-side > credentials (eg, > host certificate) that is expected on the other end? If SNMP agents are going to become SSH clients, they will need the credentials typically needed by an SSH client, which I also assume includes knowledge of acceptable server-side credentials. I believe you are correct that most devices containing SNMP agents do not also support SSH clients, so adding SSH client support to SNMP agents will certainly be a significant change. Because a typical network may contain many workstations or other devices that do contain SSH clients, I would expect that operations staff have already addressed the scalability of configuring multiple SSH clients, and they probably address the scalability issue of heterogeneous SSH implementation support. If they currently use CLI scripts to configure SSH clients on workstations, that solution could probably also be used to configure the devices that now will need SSH clients for sending SNMP notifications. I don't consider having a myriad of non-standardized configurations or management functionality a good thing. If I did, I probably would not have spent 16 years doing IETF NM work. As a network management standards engineer, I will confess to be less than impressed by the standardized manageability of the IETF security protocols. I think the SecSH WG should have been required to produce a MIB module for management, just as most other WGs were required to do for their protocols. But somehow, the message that security protocols need to be manageable got lost in the IETF. If operators realy care about the scalability problems associated with configuring and managing SSH, they would push the vendors and the IETF to produce standardized solutions. However, that problem is not one assigned to this WG to resolve. > > DH> We have standardized the index (transportDomain, transportAddress, > DH> securityName, and securityLevel) to lookup the corresponding > DH> implementation-dependent SSH credentials to open the SSH session. > > Ok, just to be sure. In order for me to set up 10k boxes to send > notifications to a notification receiver or two I need to first > configure through an out-of-band mechanism the user's credentials and > the server's expected credentials (host certificate) that the > notification receiver must present? Right? I understand the desire for standardized configuration. However, the operartors were very clear that they want to reuse their existing solutions rather than have the SNMP community develop new solutions for user and key management. from the charter: "The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem, for which there is one currently defined model - the User-based Security Model (USM). However, the USM approach has seen limited deployment so far. One frequently reported reasons is the lack of integration of USM key and user management into deployed authentication infrastructures. SSH is a widely deployed access protocol for remote devices configuration. Many devices support the integration of SSH user authentication with AAA systems via protocols such as RADIUS. The goal of the ISMS working group is developing a new security model for SNMP that integrates with widely deployed user and key management systems, as a supplement to the USM security model." Hopefully the work we do integrating with AAA will help to minimize the scalability issues of user management, and the existing key management and configuration mechanisms for SSH will resolve the key distribution problem. > And if I need to add > another notification receiver I need to manually out-of-band You would need to reconfigure out-of-band, but you might have an automated out-of-band reconfiguration capability, such as CLI scripts or Netconf data models. > reconfigure > all 10k nodes right? Or if I change the NR certificate (say on a > regular basis of every year) then I need to manually out-of-band > reconfigure the device? In a implementation-dependent way. The good news is that this implementation-dependent way is consistent with configuring syslog notifications as well. of course, the bad news is that syslog chose to use TLS instead of SSH, and netconf chose a completely different approach to notifications). > > If that's acceptable to you, then the conversation is probably at a > stand still. The real question is whether it is acceptable to operators. I suggest we ask the OPS directorate for their thoughts on this. > > DH> For comparison, look at the usmUsertable. > > The usmUserTable requires a single bootstap, not endless. I'm sorry, I don't buy this argument. Both the usmUsertable and an SSH table for notifications may need constant reconfiguration. I expect that, absent AAA, the usmUserTable needs to be reconfigured for frequent user adds/modifies/deletes, which will probably happen much more frequently then SSH server certificate changes. And I do not expect that operators change the logging aggregators in their networks very often. Given a choice between existing widely-deployed key distribution mechanism and an SNMP-specific one, operators have already told us they don't really want the SNMP-specific key change mechansism. It is just extra overhead. In addition, the SNMP key change mechanisms has some scalability problems of its own, especially in light of SNMP implementations such as command-line tools and other SNMP entities that are not "always-on". It can difficult to synchronize all the players in a network management system on a timely basis, and that work is better left to existing widely-deployed key distribution systems. > That's a huge > difference. And, with SSH the bootstrap is actually possibly > handled by > prior management station credentials (ssh users already set up for > coming into an ssh agent). But devices today like don't have outgoing > ssh credentials in place. That mapping you're referring to > into the LCD > doesn't exist today and thus must be manually configured for > notifications to be usable. I'm not saying it can't be done. It can > be. Painfully and in a non-interoperable way. Once that's in place, > yes notifications can be sent in an interoperable way. > > I really do understand the reasons behind wanting to shelve this and > saying "we're not going to do configuration at that level of detail". > But it will affect scalability of the results. I think we might be better to expect that at some point in the future, SSH configuration should be standardized, as should syslog, and TLS and other non-standardzied management functionality for security protocols. I think Netconf might be a better protocol than SNMP for standardizing configuration of SSH. I would be happy to add an Operability and Manageability section to the ISMS documents to include discussion of scalable configuration, management, and key distribution for notifications. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 30 04:42:56 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A68AC3A68C0; Fri, 30 May 2008 04:42:56 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5243A68D8 for ; Fri, 30 May 2008 04:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeSn+b3u-l8D for ; Fri, 30 May 2008 04:42:50 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 2DDF03A67DD for ; Fri, 30 May 2008 04:42:50 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA02.westchester.pa.mail.comcast.net with comcast id XltC1Z00F0cZkys5207l00; Fri, 30 May 2008 11:42:48 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id Xnin1Z0094HwxpC3W00000; Fri, 30 May 2008 11:42:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=vEeLAe6aKXYA:10 a=BAAOSocF1wTL2LzyhV0A:9 a=cmvK-uP2ZU5y1II4U6G0YDoU33cA:4 a=lZB815dzVvQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: Date: Fri, 30 May 2008 07:42:47 -0400 Message-ID: <019001c8c24a$48e4ecf0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjCJ+5xGZ/cuHRFQ4mmOeXEsrv8LgAIlYrg Subject: [Isms] FW: [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Friday, May 30, 2008 3:34 AM To: David Harrington Cc: ops-dir@ietf.org; 'OPS Area' Subject: Re: [OPS-DIR] SNMP notification configuration On Wed, 28 May 2008, David Harrington wrote: > Question #1: > For SNMP notifications, the SNMP agent will need to act as an SSH > client, and the SNMP notification receivers will need to act as an SSH > server. Will operators find this objectionable? In our case, routers, switches, etc. are not allowed to log in (ssh allow_hosts, firewall rules in various places) to the management systems. As a result this approach would require significant changes to ACL policies. I'm not saying this is a show-stopper, but I suspect many (most?) other networks will require similar changes, and depending how easy for them it is to enumerate all the possible IP addresses or prefixes their SNMP-notifying equipment might use could be a challenge. > Question #2: > Would operators prefer to modify their existing user and key > management solutions, such as implementation-dependent CLI scripts, to > configure SSH clients on devices where they may not be found now, or > would operators prefer to have the ISMS WG develop a standard MIB > module to configure and manage the SSH credentials needed to have SNMP > agents act as SSH clients? I expects scripts to be used. I would not expect SNMP (write) MIBs to be used. It's possible that a MIB could be used in a read-only mode to verify configuration correctness, however. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 30 04:43:09 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C0E28C197; Fri, 30 May 2008 04:43:09 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C14428C19C for ; Fri, 30 May 2008 04:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99nrIkLQ+EUu for ; Fri, 30 May 2008 04:43:04 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 6C86E28C195 for ; Fri, 30 May 2008 04:43:04 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA09.westchester.pa.mail.comcast.net with comcast id XnHS1Z0040SCNGk5901g00; Fri, 30 May 2008 11:43:03 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA09.westchester.pa.mail.comcast.net with comcast id Xnj21Z00A4HwxpC3V00000; Fri, 30 May 2008 11:43:03 +0000 X-Authority-Analysis: v=1.0 c=1 a=vEeLAe6aKXYA:10 a=f_IArZgwXGSdys2pzPEA:9 a=pXLVqNiD9xjkAJJybGCaee3Ez0oA:4 a=lZB815dzVvQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: Date: Fri, 30 May 2008 07:43:02 -0400 Message-ID: <019101c8c24a$51b6ebd0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjCHaZNQxQ3xWKARG2HKt6nHdFo+gALKfNg Subject: [Isms] FW: [OPS-DIR] SNMP notification configuration X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org -----Original Message----- From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] Sent: Friday, May 30, 2008 2:23 AM To: Bernard Aboba Cc: David Harrington; ops-dir@ietf.org; 'OPS Area' Subject: Re: [OPS-DIR] SNMP notification configuration On 29 maj 2008, at 16.38, Bernard Aboba wrote: > > Question #1: > > For SNMP notifications, the SNMP agent will need to act as an SSH > > client, and the SNMP notification receivers will need to act as an > SSH > > server. Will operators find this objectionable? > > Assuming that the SNMP notification receivers are hosts running sshd, > this doesn't seem problematic. > > > Question #2: > > Would operators prefer to modify their existing user and key > > management solutions, such as implementation-dependent CLI > scripts, to > > configure SSH clients on devices where they may not be found now, or > > would operators prefer to have the ISMS WG develop a standard MIB > > module to configure and manage the SSH credentials needed to have > SNMP > > agents act as SSH clients? > > Personally, it seems a lot easier to deal with scripts than to > attempt to configure SSH via MIBs. I would actually agree with Bernard. In addition, we have for years been trying to get more vendors to implement SSHv2 public key authentication, i.e no user/password login exactly to make it easier to script. Best regards, - kurtis - _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 30 06:52:01 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F6D28C1C5; Fri, 30 May 2008 06:52:01 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7285C3A69B6 for ; Fri, 30 May 2008 06:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDXS2WdiAqXP for ; Fri, 30 May 2008 06:51:59 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 0F1FD28C1D6 for ; Fri, 30 May 2008 06:51:34 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA09.westchester.pa.mail.comcast.net with comcast id XpLN1Z04E0cZkys5901C00; Fri, 30 May 2008 13:51:33 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id XprY1Z00B4HwxpC3W00000; Fri, 30 May 2008 13:51:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=4o07yw9cE812fPvUTVQA:9 a=c7en_MoI1ccvyJzyKDUA:7 a=xdvlmGfvcNq62oxTMIZ1muuw2IIA:4 a=86L1PGDMzkIA:10 a=JfD0Fch1gWkA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <20080527062527.GC16024@elstar.local><20080527191459.GB18071@elstar.local><20080527201332.GA18214@elstar.local><20080528085419.GA18649@elstar.local><041001c8c0df$4c2767b0$0600a8c0@china.huawei.com><000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com><002f01c8c106$6cf836f0$0600a8c0@china.huawei.com><483FE009.3040808@cisco.com> Date: Fri, 30 May 2008 09:51:32 -0400 Message-ID: <01b001c8c25c$45509d70$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjCVtqR8DcfgglGTRqJvJK78cDbKwAAV5ew In-Reply-To: Subject: [Isms] Issue # ??? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Wes, Eliot chose to restrict this discussion because he thought it was water under the bridge. I don't know what issue he thinks is water under the bridge. So I'm going back to the WG with the discussion. I have asked repeatedly for proposed changes to text in the current documents. Two of the reasons I keep asking for this is because 1) I think we may be talking past each other, and 2) I want to be sure I understand what you think the issue is. I cannot edit the documents to represent your proposed changes because I am not sure what you think needs to be changed. I am not resisting the changes you want; I just don't know what changes you want. Maybe I'm just thick. Can you please provide a fairly simple explanation of what you think the problem is, and explain how the current drafts do not address the problem, but should? (and PLEASE read TSM appendix A before replying.) Don't just tell me that the documents don't address your problem and you're tired of standing on your head; tell me ***how*** they should address the problem. Maybe then I will have a better understanding of what you are trying to fix, and can edit the documents to address your concerns. I may still be too thick to do that editing; If you can provide proposed text and tell me where in the documents that text should be put, and the WG agrees, I'll be happy to put them in. dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Friday, May 30, 2008 9:10 AM > To: Eliot Lear > Cc: David Harrington; 'Wes Hardaker' > Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 > > >>>>> On Fri, 30 May 2008 13:07:53 +0200, Eliot Lear > said: > > EL> I'm reducing because my understanding is that this is > supposed to be > EL> water under the bridge, and as such perhaps we should > move on. I say > EL> this as the guy who stood on his head on this issue some time ago. > > Yeah... I realize that I think I'm the only one left on my head. > > >> SSH is a widely deployed access protocol for remote devices > >> configuration. Many devices support the integration of SSH user > >> authentication with AAA systems via protocols such as RADIUS. > > EL> Right. That's not the problem. But securing host keys > is a problem > EL> because that's not in radius. It's a one time issue so > long as you do > EL> not rekey the server. > > Or add a new trap receiver (or heck, even change it's address). Or > rekey the hosts. > > EL> I do think it would help if there was another example > that used TSM, > EL> like TLS. > > I actually have a DTLS based TSM draft that I'll be publishing before > Dublin... But it won't be considered till the SSH draft is finished. > (and that lets you know how much I think the scalability of > the current > draft should be dealt with; trying to fix this means delaying the SSH > draft during the conversation and that slows down my own > attempt to get > another draft in the door... But I still think it's the > right thing to do) > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 30 07:09:32 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08E93A6964; Fri, 30 May 2008 07:09:32 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440513A69E8 for ; Fri, 30 May 2008 07:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUn+b55SVAq3 for ; Fri, 30 May 2008 07:09:31 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 08FB83A68F4 for ; Fri, 30 May 2008 07:09:30 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Xmi41Z0020Fqzac570BB00; Fri, 30 May 2008 14:08:36 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id Xq9Q1Z0044HwxpC3U00000; Fri, 30 May 2008 14:09:25 +0000 X-Authority-Analysis: v=1.0 c=1 a=yOsLR9kwX8KzaXzcv34A:9 a=jChMWbi5Meb0sYMCRoYA:7 a=Uoob01qaWq-fzIzfTfAHXQ3ETY8A:4 a=86L1PGDMzkIA:10 a=JfD0Fch1gWkA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <20080527062527.GC16024@elstar.local><20080527191459.GB18071@elstar.local><20080527201332.GA18214@elstar.local><20080528085419.GA18649@elstar.local><041001c8c0df$4c2767b0$0600a8c0@china.huawei.com><000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com><002f01c8c106$6cf836f0$0600a8c0@china.huawei.com><483FE009.3040808@cisco.com> Date: Fri, 30 May 2008 10:09:24 -0400 Message-ID: <01b101c8c25e$c411e2c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjCVtqR8DcfgglGTRqJvJK78cDbKwABW2bw In-Reply-To: Subject: [Isms] Issue #9 - securing host keys X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Wes and Eliot, I'm bringing this to the list. The chair can tell us to take the discussion off this list if the issue has already been settled. comments inline. > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Friday, May 30, 2008 9:10 AM > To: Eliot Lear > Cc: David Harrington; 'Wes Hardaker' > Subject: Re: [Isms] ssh notifications and draft-ietf-isms-secshell-10 > > >>>>> On Fri, 30 May 2008 13:07:53 +0200, Eliot Lear > said: > > EL> I'm reducing because my understanding is that this is > supposed to be > EL> water under the bridge, and as such perhaps we should > move on. I say > EL> this as the guy who stood on his head on this issue some time ago. > > Yeah... I realize that I think I'm the only one left on my head. > > >> SSH is a widely deployed access protocol for remote devices > >> configuration. Many devices support the integration of SSH user > >> authentication with AAA systems via protocols such as RADIUS. > > EL> Right. That's not the problem. I was quoting a three paragraph section of the charter. I was not suggesting that this paragraph addressed the problem, only pointing out what operators had asked for. > EL> But securing host keys > is a problem > EL> because that's not in radius. It's a one time issue so > long as you do > EL> not rekey the server. > > Or add a new trap receiver (or heck, even change it's address). Or > rekey the hosts. I think it is fair to characterize SSH host key distribution as a one-time issue 90% of the time, but we also need to recognize that there is another 10%. I am not sure that securing SSH host keys is a problem to be addressed by this WG. I think host keys are already found in existing infrastructure, and they are secured using implementation- and/or deployment-specific ways. I think those same solutions should be used here, when possible. Where not possible, the problem needs to be recognized and addressed, but I think securing host keys is an SSH infrastructure issue, not an ISMS issue. We **are** proposing that the infrastrucure be deployed differently than it is currently deployed, and I absolutely think we should at least discuss this in the Security Considerations. dbh _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 30 07:09:56 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C523A69E8; Fri, 30 May 2008 07:09:56 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368FC28C1D6 for ; Fri, 30 May 2008 07:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4NpH5WaTs6g for ; Fri, 30 May 2008 07:09:53 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 5259828C1CC for ; Fri, 30 May 2008 07:09:53 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id B847F39A213; Fri, 30 May 2008 07:07:46 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=2/3WEAw/ZUGvec4LqUx37BOr4ao=; b=laKTgNPeryZirEhYUQ6M2T4UJ7PkyNhfjql4g3+qfTbVo+yjL3eOIJPO6Lb93ePZ5ARpsQB2kKSyv9N074F0Sz8DqX0aa+FO4p4igdaGUbPXMF/inrUmRVFyMox0fgzAgQ5vecYIW0Hqruju3cEVyweLaKwoG7z7L/6kz1tPYFo= Received: by wes.hardakers.net (Postfix, from userid 274) id 952AF39A214; Fri, 30 May 2008 07:07:46 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <20080527062527.GC16024@elstar.local> <20080527191459.GB18071@elstar.local> <20080527201332.GA18214@elstar.local> <20080528085419.GA18649@elstar.local> <041001c8c0df$4c2767b0$0600a8c0@china.huawei.com> <000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com> <002f01c8c106$6cf836f0$0600a8c0@china.huawei.com> <483FE009.3040808@cisco.com> <01b001c8c25c$45509d70$0600a8c0@china.huawei.com> Date: Fri, 30 May 2008 07:07:46 -0700 In-Reply-To: <01b001c8c25c$45509d70$0600a8c0@china.huawei.com> (David Harrington's message of "Fri, 30 May 2008 09:51:32 -0400") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] Issue # ??? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Fri, 30 May 2008 09:51:32 -0400, "David Harrington" said: DH> I cannot edit the documents to represent your proposed changes because DH> I am not sure what you think needs to be changed. I am not resisting DH> the changes you want; I just don't know what changes you want. I believe that I may be standing alone here (and I do think everyone now understands what I was concerned about including you, since you wrote a note to the ops-area list and the contents showed you understood what I wished would be standardized). So... because of the fact I'm potentially alone here and because a few responses on the ops-area list have backed up the opinions here that a full interoperable configuration method may not be needed I think there is consensus that the additional parts to the document shouldn't be written. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 30 07:31:29 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637DF3A6853; Fri, 30 May 2008 07:31:28 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DC528C297 for ; Fri, 30 May 2008 07:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRIC+Y7RUJbl for ; Fri, 30 May 2008 07:31:10 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id DAEB428C2AE for ; Fri, 30 May 2008 07:26:22 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA04.westchester.pa.mail.comcast.net with comcast id XpNP1Z03D0xGWP85402700; Fri, 30 May 2008 14:26:20 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA12.westchester.pa.mail.comcast.net with comcast id XqSK1Z0014HwxpC3Y00000; Fri, 30 May 2008 14:26:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=7K0GUoq-AyAA:10 a=BU-lyOFQp2zNdczyjF8A:9 a=wXMMlyFSa9UNEW3yKLQA:7 a=B5NI5x4_uJbz69AyBgb_2gM5CkUA:4 a=86L1PGDMzkIA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Wes Hardaker'" References: <20080527062527.GC16024@elstar.local><20080527191459.GB18071@elstar.local><20080527201332.GA18214@elstar.local><20080528085419.GA18649@elstar.local><041001c8c0df$4c2767b0$0600a8c0@china.huawei.com><000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com><002f01c8c106$6cf836f0$0600a8c0@china.huawei.com><483FE009.3040808@cisco.com> <01b001c8c25c$45509d70$0600a8c0@china.huawei.com> Date: Fri, 30 May 2008 10:26:18 -0400 Message-ID: <01be01c8c261$20fac220$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjCXtSfLpy6ObZsS26tvxcjS9ioXgAAQBjA In-Reply-To: Cc: isms@ietf.org Subject: Re: [Isms] Issue # ??? => Issue#2/3 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, If the issue you are raising is the lack of a standardized mapping table from a mechanism-specific identity to a securityName, then that issue has already been identified in secshell-10 as Issue#2 in the Open Issues list. If the issue you are raising is the lack of a standardized mapping table to a mechanism-specific identity from a securityName, then that issue has already been identified in secshell-10 as Issue#3 in the Open Issues list. I think your discussion of the problem has been somewhat different than Issue#2 and Issue#3, but I'm not sure because you have not discussed them under these issue#s. You seem to be wandering into other areas of concern, and I cannot tell whether you are raising new Open Issues or not. If you agree these are the issues you want to raise, then please use these Issue#s in your subject lines, so we can keep the issues properly separated. I have added a new Issue#9 to discuss securing SSH host keys, since that came up in the discussion and seems to be a different issue. dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Friday, May 30, 2008 10:08 AM > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] Issue # ??? > > >>>>> On Fri, 30 May 2008 09:51:32 -0400, "David Harrington" > said: > > DH> I cannot edit the documents to represent your proposed > changes because > DH> I am not sure what you think needs to be changed. I am > not resisting > DH> the changes you want; I just don't know what changes you want. > > I believe that I may be standing alone here (and I do think > everyone now > understands what I was concerned about including you, since > you wrote a > note to the ops-area list and the contents showed you > understood what I > wished would be standardized). > > So... because of the fact I'm potentially alone here and > because a few > responses on the ops-area list have backed up the opinions here that a > full interoperable configuration method may not be needed I > think there > is consensus that the additional parts to the document > shouldn't be written. > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 30 07:39:57 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90FAA3A69A2; Fri, 30 May 2008 07:39:57 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4FB3A69A2 for ; Fri, 30 May 2008 07:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNNzxnySq826 for ; Fri, 30 May 2008 07:39:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E4BE03A6898 for ; Fri, 30 May 2008 07:39:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,566,1204498800"; d="scan'208";a="10355904" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 May 2008 16:39:53 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4UEdrDK017143; Fri, 30 May 2008 16:39:53 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4559.cisco.com [10.61.81.206]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4UEdr6P026426; Fri, 30 May 2008 14:39:53 GMT Message-ID: <484011B9.5030805@cisco.com> Date: Fri, 30 May 2008 16:39:53 +0200 From: Eliot Lear User-Agent: Thunderbird 3.0a2pre (Macintosh/2008052803) MIME-Version: 1.0 To: David Harrington References: <20080527062527.GC16024@elstar.local><20080527191459.GB18071@elstar.local><20080527201332.GA18214@elstar.local><20080528085419.GA18649@elstar.local><041001c8c0df$4c2767b0$0600a8c0@china.huawei.com><000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com><002f01c8c106$6cf836f0$0600a8c0@china.huawei.com><483FE009.3040808@cisco.com> <01b101c8c25e$c411e2c0$0600a8c0@china.huawei.com> In-Reply-To: <01b101c8c25e$c411e2c0$0600a8c0@china.huawei.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1548; t=1212158393; x=1213022393; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Isms]=20Issue=20#9=20-=20securing=20ho st=20keys |Sender:=20; bh=XvCdJV1wvWvRns4Lp+MkQ9vGqSX3crOHi+6aPUxzrGY=; b=YkcGuEr/TwA98VTsNAOWdwG+fQieAvbuseGh3mIYFPsB6if6e/WmGLms5e sI6wFhnFuimWwO3CV/0C/h9WXyqtGxqmzryo64/kvakUXPlheILs8zGDGlm/ M5Lk/6APkU; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: isms@ietf.org Subject: Re: [Isms] Issue #9 - securing host keys X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Dave, FWIW the reason I didn't bring this stuff to the list was that I believe it went to the core of the decision to use SSH. That is the water under the bridge to which I referred. As to the issue below: > I think it is fair to characterize SSH host key distribution as a > one-time issue 90% of the time, but we also need to recognize that > there is another 10%. > I think these numbers are as good as any, and would accept them for purposes of discussion. > I am not sure that securing SSH host keys is a problem to be addressed > by this WG. I think host keys are already found in existing > infrastructure, and they are secured using implementation- and/or > deployment-specific ways. I think those same solutions should be used > here, when possible. I do not think securing host keys necessarily needs to be accomplished in this group, and I'm not even sure one should go to great effort to discuss them in security considerations, except as it directly relates to SNMP. If you think we need specific text for that, I'd be happy to give it a swag as a starting point, but it strikes me that Jeff is The Man for this one. On the other hand, the issue I had with host keys is that they do not lend themselves easily today to autoconfiguration out of the box when you have tens of thousands of devices. That is something X.509 might prove to be more useful, and hence my interest in that area. Please do not take this text as an objection to the current draft. Regards, Eliot _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 30 09:08:07 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADE23A6A27; Fri, 30 May 2008 09:08:07 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4F03A693E for ; Fri, 30 May 2008 09:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnQW27QtESsj for ; Fri, 30 May 2008 09:08:05 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id A0BC33A6B3A for ; Fri, 30 May 2008 09:08:04 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA01.westchester.pa.mail.comcast.net with comcast id XnyE1Z0080mv7h0510DZ00; Fri, 30 May 2008 16:08:03 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.westchester.pa.mail.comcast.net with comcast id Xs811Z00N4HwxpC3X00000; Fri, 30 May 2008 16:08:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=v4ZqM3l5XC4qVUebCIsA:9 a=G4JDbpDmXHrX2_JelJ-yBxP7q08A:4 a=86L1PGDMzkIA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Wes Hardaker'" References: <20080527062527.GC16024@elstar.local><20080527191459.GB18071@elstar.local><20080527201332.GA18214@elstar.local><20080528085419.GA18649@elstar.local><041001c8c0df$4c2767b0$0600a8c0@china.huawei.com><000c01c8c0f1$2cce7b80$0600a8c0@china.huawei.com><002f01c8c106$6cf836f0$0600a8c0@china.huawei.com><483FE009.3040808@cisco.com> <01b001c8c25c$45509d70$0600a8c0@china.huawei.com> Date: Fri, 30 May 2008 12:08:01 -0400 Message-ID: <01c801c8c26f$5675fab0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjCXtSfLpy6ObZsS26tvxcjS9ioXgAAmz5Q In-Reply-To: Cc: isms@ietf.org Subject: [Isms] Issue#2 - standardized mapping X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I think the discussion that has been carried on recently demonstrates that the lack of any **standardized mapping table** in the specification makes it hard to understand the specification and how to apply it to notifications. If the people in this discussion are having trouble understanding what has to be specified where in the system, and how they relate, then implementers and users will have a very hard time. I recognize that credentials should not be stored in a MIB, and that the internal SSH mechanisms used to perform suthentication should not be exposed, since that might be a layer violation. I suggest that we add a mapping table to the SSHTM-MIB that includes 1) an INDEX based on values of tmTransportDomain, tmTransportAddress, tmSecurityName, and tmSecurityLevel from the tmStateReference, and 2) an SSHIndex column that is an OCTET STRING, whose format and value is implementation-dependent, but the DESCRIPTION would be that it is a value that can be used in an implementation-dependent manner to refer to an SSH set of credentials associated with a particular SSH entity. If we want to require SSHindex to be human-readable to make it easier for operators, we can use an SnmpAdminString. If the same SSH identity might be authenticated using different algorithms, then I would not be averse to adding columns that can specify the authProtocol values, similar to usmUserTable. dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Friday, May 30, 2008 10:08 AM > To: David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] Issue # ??? > > >>>>> On Fri, 30 May 2008 09:51:32 -0400, "David Harrington" > said: > > DH> I cannot edit the documents to represent your proposed > changes because > DH> I am not sure what you think needs to be changed. I am > not resisting > DH> the changes you want; I just don't know what changes you want. > > I believe that I may be standing alone here (and I do think > everyone now > understands what I was concerned about including you, since > you wrote a > note to the ops-area list and the contents showed you > understood what I > wished would be standardized). > > So... because of the fact I'm potentially alone here and > because a few > responses on the ops-area list have backed up the opinions here that a > full interoperable configuration method may not be needed I > think there > is consensus that the additional parts to the document > shouldn't be written. > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 30 10:26:40 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442293A6B21; Fri, 30 May 2008 10:26:40 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69EBF3A6B21 for ; Fri, 30 May 2008 10:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKJDCpuUelLn for ; Fri, 30 May 2008 10:26:38 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id CF39A28C1F5 for ; Fri, 30 May 2008 10:20:12 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA05.westchester.pa.mail.comcast.net with comcast id XpRl1Z00j0QuhwU5509N00; Fri, 30 May 2008 17:20:11 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.westchester.pa.mail.comcast.net with comcast id XtLA1Z0084HwxpC3N00000; Fri, 30 May 2008 17:20:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=5trYRZ3PLdQA:10 a=6b_6Eu8p2oJbmzOPOngA:9 a=aRoevvn6-QbUShKseooA:7 a=lJXxLcfSTXetWeSAowV87Uza5zEA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Fri, 30 May 2008 13:20:10 -0400 Message-ID: <01de01c8c279$6a92b510$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjCeWnbnRXcfTRJSMqFzFmk/MdFuw== Subject: [Isms] Issue#10 - TSM aggregated security names X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, If a system supports both SSH-TM and TLS-TM, and we use a default 1:1 mapping from the mechanism-specific principal to securityName, we could hit a situation where SSH:David and TLS:David are actually different principals, but get assigned the same securityName by the TSM. I think this is a problem. I also think that without giving mechanism-specific knowledge to the TSM, the TSM cannot solve this on its own. Should TSM have a table that specifies how the mapping should be done per transportModel supported? This table would be agent-generated and contain a row for each supported TM. A writable column would support four admin-configurable options; the default setting for each supported TM would be #1: 1) use the default mapping specified by the TM (usually this will be some type of algorithmic 1:1 mapping); 2) Do not allow a specific transport model to be used at all (do not assign a securityName to any identity authenticated by the specific transport model); 3) use an optional admin-configurable table that provides explicit mappings from an mechanism-specific and implementation-specific algorithmically derivable identity to a user-chosen securityName (and vice-versa). Only identities found in this table are allowed to be assigned securityNames. Wildcards might be supported. 4) The same table as 3), but if a name is not found in the table, then fallback to using the default mechanism. Comments? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri May 30 12:17:25 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42923A6AB5; Fri, 30 May 2008 12:17:25 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D04C3A6B09 for ; Fri, 30 May 2008 12:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7en2Gs-lYc9Y for ; Fri, 30 May 2008 12:17:23 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 1B7973A68EB for ; Fri, 30 May 2008 12:17:16 -0700 (PDT) Received: (qmail 22418 invoked from network); 30 May 2008 14:17:11 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 30 May 2008 14:17:11 -0400 From: "David B. Nelson" To: References: <01de01c8c279$6a92b510$0600a8c0@china.huawei.com> Date: Fri, 30 May 2008 14:17:21 -0400 Organization: Elbrys Networks, Inc. Message-ID: <1151176007DF4D57A413B49A664AD467@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: <01de01c8c279$6a92b510$0600a8c0@china.huawei.com> Thread-Index: AcjCeWnbnRXcfTRJSMqFzFmk/MdFuwABnwOw Subject: Re: [Isms] Issue#10 - TSM aggregated security names X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington writes... > If a system supports both SSH-TM and TLS-TM, and we use a default > 1:1 mapping from the mechanism-specific principal to securityName, > we could hit a situation where SSH:David and TLS:David are actually > different principals, but get assigned the same securityName by > the TSM. > > I think this is a problem. I also think that without giving > mechanism-specific knowledge to the TSM, the TSM cannot solve this > on its own. I think this is a more general problem. Any time you draw identities multiple name-spaces and use that identity in an interchangeable fashion without a name-space tag, you have a potential problem. To use a simplistic example, host names are often ambiguous unless they are represented as fully qualified domain names. The fact that you have multiple secure transports does not automatically mean you have multiple name-spaces. If SSH-TM and TLS-TM are both using the same RADIUS server for authentication of the principal, the names will be from the same name-space. Conversely if you have a single secure transport that somehow uses multiple authentication sources (e.g. RADIUS and LCD) at the same time, name collision can occur. The simplest solution is to require (administratively) one of: (a) all secure transports utilize the same source of authentication, i.e. a single name-space, or (b) all names to be represented in a fully qualified format, e.g. name@name-space. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms