From dbharrington@comcast.net Thu Feb 5 07:16:08 2009 Return-Path: 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 08D3528C1B2 for ; Thu, 5 Feb 2009 07:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 CwqEvByJnOTb for ; Thu, 5 Feb 2009 07:16:06 -0800 (PST) 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 688EF28C18F for ; Thu, 5 Feb 2009 07:16:06 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA07.westchester.pa.mail.comcast.net with comcast id CBhL1b0030EZKEL57FFnWm; Thu, 05 Feb 2009 15:15:47 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA01.westchester.pa.mail.comcast.net with comcast id CFFn1b0050UQ6dC3MFFn3z; Thu, 05 Feb 2009 15:15:47 +0000 From: "David B Harrington" To: , References: <20090127083933.GC12355@elstar.local> <20090205080119.GA1186@elstar.iuhb02.iu-bremen.de> Date: Thu, 5 Feb 2009 10:15:45 -0500 Message-ID: <063301c987a4$9ee4f080$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090205080119.GA1186@elstar.iuhb02.iu-bremen.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmHZ/lBQ6lSk9kkSS+UApYkWblRKgAOjz9A Subject: Re: [Isms] [j.schoenwaelder@jacobs-university.de: Re: secshell-pre14] 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: , X-List-Received-Date: Thu, 05 Feb 2009 15:16:08 -0000 Hi, The two ports issue is resolved. We now use two ports; the document now asks IANA for two ports; and I think the use of two ports has no effect on the EOP, because the choice of ports is done strictly by the applications. I will, of course double-check this. I think the EOP needs to be updated somewhat to address Pasi's comments. I have not gone through the EOP to see just what needs changing yet. I think the EOP needs to be modified to make sure the message processing model can match the outgoing transportaddress for a request and the incoming transportaddress from the response, which is how the MPM determines which application is waiting for a response. If the request was sent using a user@foo.com address, then SSHTM uses parses the address into a foo.com address and uses foo instead of the tmsecurityname specified by the security model. When we get a response from user at foo.com, we need to make the TM pass the MPM a transport address of the user@foo.com format, and set the tmsecurityname to match what was requested by the security model. I don't think it will be terribly difficult to update the EOP, but I am not sure where the TM stores the request-state (tmsecurityname) that it must restore when it gets the response. I'll try to get a revision posted within the next week. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, February 05, 2009 3:01 AM > To: Dave Harrington > Subject: Re: [j.schoenwaelder@jacobs-university.de: Re: > [Isms]secshell-pre14] > > On Tue, Jan 27, 2009 at 09:39:33AM +0100, Juergen Schoenwaelder wrote: > > David, > > > > can you quickly explain the issues? I would like to move > forward with > > resolving them and push for a second last call. > > David, > > where are we with the open issues. You once mentioned: > > > We still need work on > > 1) the processes for client versus server > > 2) two ports > > Then there was some discussion around the SSH username embedded in an > SSH TAddress. So we might have three issues still to solve but I am > not 100% sure what the issues are. Can you help us by stating the > issue clearly? I want to get this ISMS thing done; and it needs to be > good enough not perfect for Proposed Standard. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From dave.shield@googlemail.com Fri Feb 6 03:02:01 2009 Return-Path: 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 64A003A6BB2 for ; Fri, 6 Feb 2009 03:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 sWl06Xhdluqp for ; Fri, 6 Feb 2009 03:02:00 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 86E673A6BB1 for ; Fri, 6 Feb 2009 03:02:00 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so710432rvf.49 for ; Fri, 06 Feb 2009 03:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XMkRF3vbDeZRjrl9ui7ulN76+lNQGy4ZJu8oqCwMpjc=; b=mpXJF6yBlRY0fRS844BxWtZtVTW1+mVwhqZJuamoRjj6yaXG0EgAyY/8pp9eoWpIuo HWzPTlTX1PYDTxc56FolqmSE9A5uduBBi2v2rrmyHEHj4OQvrXVBZJy7KLb4iEk4Hp4f DO0bJ6TxObJwOlGeo2qzXe+XKcWoXYDvWI9tg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=CeYJkSuI3aQtYKYwaLubk6miPnkXj7M9M+g/QnX/stVvYjUpl8MkmRhrw3nYKxhJQO eLsUycmmQaWsmTN5stlfNaxKQXJJIiGBkl6UWglCLsLd2BQ8q4BqUXFMovpY3W2EyPPn 2GpbhTUFOX8VHN/6al90i0RJYI/0Zwm7OvpN0= MIME-Version: 1.0 Sender: dave.shield@googlemail.com Received: by 10.141.179.5 with SMTP id g5mr1180235rvp.32.1233918122157; Fri, 06 Feb 2009 03:02:02 -0800 (PST) Date: Fri, 6 Feb 2009 11:02:02 +0000 X-Google-Sender-Auth: 154710ab48079ee7 Message-ID: From: Dave Shield To: j.schoenwaelder@jacobs-university.de, David Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: Re: [Isms] tmsm pre-16 - minor 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: , X-List-Received-Date: Fri, 06 Feb 2009 11:02:01 -0000 2009/1/23 Juergen Schoenwaelder : > On Thu, Jan 22, 2009 at 03:43:13PM -0500, David Harrington wrote: > >> I think I have covered all the WGLC comments. > > Can the WG members please review the changes? A few minor nits which seem to be still present: Section 5.2 The standard contents of the tmStateReference cache include entries 'transportDomain' and 'transportAddress'. However, wherever these fields are mentioned in the other documents (and in section 6.2.2), they are called 'tmTransportDomain' and 'tmTransportAddress' s/transportDomain/tmTransportDomain/ s/transportAddress/tmTransportAddress/ Section 5.2.1 s/o transportDomain/o tmTransportDomain/ s/o transportAddress/o tmTransportAddress/ (as above) Note that the second mention of transport{Domain,Address} in this section refers to the ASI parameters which *are* transportDomain and transportAddress. Section 6.2 This section starts with a DISCUSS block (which has been present since at least draft 13). Is this still needed? Section 6.2.2 The security subsystem pritives are 'generate{Request,Response}Msg', but the first paragraph mentions 'prepareOutgoingMessage' instead. s/prepareOutgoingMessage/generateRequestMsg/ Dave From dave.shield@googlemail.com Fri Feb 6 03:02:08 2009 Return-Path: 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 72CB428C11C for ; Fri, 6 Feb 2009 03:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 YJNnB+sJ9em2 for ; Fri, 6 Feb 2009 03:02:07 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id A370128C0E5 for ; Fri, 6 Feb 2009 03:02:07 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so710432rvf.49 for ; Fri, 06 Feb 2009 03:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=av1KTm/a42ZigtpLLFttat8kU47eElIQmwvXS0nYKMU=; b=ACNkP2mlciL3pN3GkHKX6lnJ5qMgC9Q0tEDbbKGpJBIGk2V7anF+oLoT2XaNnhzzWW kcsYuWPyfY9gTq8o5k51Hqx695xfCe50OFshss5IKRWk/tlelbv7XZ4YVmmSWKPzZU1/ K9qXiZHPogBYy+ihgGK8BYXl4K83z5pG3xlEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=NejIpclXiQeb/G6NJVUMstFCxdMuHThkyXaB5jLsRP5lPMLA+5JuNn4s7zRsVP84Be 7/EQik7fjgohbKzoe0F6egmm/U2WM0W0XujVlm7Bql8F62ZBqhpAWPZKFUcBpBcKZI5W J5oaw/0SkeJV0pvn7frJbK2hqXx+azZmK8gtI= MIME-Version: 1.0 Sender: dave.shield@googlemail.com Received: by 10.140.170.12 with SMTP id s12mr533561rve.53.1233918129945; Fri, 06 Feb 2009 03:02:09 -0800 (PST) Date: Fri, 6 Feb 2009 11:02:09 +0000 X-Google-Sender-Auth: 9dec1f92a709513a Message-ID: From: Dave Shield To: j.schoenwaelder@jacobs-university.de, David Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: Re: [Isms] secshell-pre14 - minor 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: , X-List-Received-Date: Fri, 06 Feb 2009 11:02:08 -0000 2009/1/23 Juergen Schoenwaelder : > On Thu, Jan 22, 2009 at 03:42:22PM -0500, David Harrington wrote: > >> This is an updated draft for secshell. > Can the WG members please review the changes? A few minor nits which seem to be still present: Section 3.1.1 2. The references to RFC4253 (para 2) and RFC4252 (para 3) are enclosed in both round and square brackets. All other references throughout the document use square brackets only. s/([RFC4252])/[4252]/ s/([RFC4253])/[4253]/ Section 5 Para 3 of the introduction includes ".... for the returned OID and value contextEngineID would be set ..." Insert a comma after "value". Section 5.3 step 3 states "If the attempt to establish a connection is unsuccessful, or server authentication fails, then sshtmSessionOpenErrors is incremented... and openProcessing stops." This is the only time that sshtmSessionOpenErrors is mentioned. The definition of the sshtmSessionOpenErrors MIB object states "The number of times an openSession() request failed to open a session as a SSH client, for any reason." <====== "For any reason" is wrong. Dave From dave.shield@googlemail.com Fri Feb 6 03:02:48 2009 Return-Path: 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 CDD9E28C0EB for ; Fri, 6 Feb 2009 03:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 i5ONjsWzDyKR for ; Fri, 6 Feb 2009 03:02:48 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 205C63A6BB1 for ; Fri, 6 Feb 2009 03:02:48 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so710662rvf.49 for ; Fri, 06 Feb 2009 03:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+tZTiXxCGMOjfPQmD5ONzw82WkHQKF/UAeykEFj4kkQ=; b=HE6rMU4gAvO1aX2C0ak5pKPYta7bBlhgXQbZSl9LbHXi7pu+KG/IaCzikyjiW3vZwD j8q2/gJ1jj99y+Pe5EVii8Gp+9cZDu2pa9DbqI8VhFSlxpIBUvChuOthYHazACGBj6Ul mQUGixDh+5UgUTECgtOdyNJYFrL1ym2YE0YnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=ASiwW1GsdyMLe/QqRqa8GV49ogMIiIz3ZDnv0J5z9uEcmOMe5utqfYuyPWbbcVp0dE 2S2fDdsQ3+47ghc2D+LM5CC9MFCeojrOq1tRDWoGd29+ZRYevIUr9zWSMQk9kXKVJD09 OWq4tJNoPH3+7jc2k9nxKIruM01X2MK0xhfDU= MIME-Version: 1.0 Sender: dave.shield@googlemail.com Received: by 10.141.99.2 with SMTP id b2mr474912rvm.3.1233918169152; Fri, 06 Feb 2009 03:02:49 -0800 (PST) Date: Fri, 6 Feb 2009 11:02:49 +0000 X-Google-Sender-Auth: f488745899545cad Message-ID: From: Dave Shield To: j.schoenwaelder@jacobs-university.de, David Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: Re: [Isms] tsm pre11 - minor 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: , X-List-Received-Date: Fri, 06 Feb 2009 11:02:48 -0000 2009/1/23 Juergen Schoenwaelder : > On Thu, Jan 22, 2009 at 03:43:47PM -0500, David Harrington wrote: > >> I think I have covered all the WGLC comments > > Can the WG members please review the changes? A few minor nits which seem to be still present: Section 4.2 Step 1) explains the presence of a securityStateReference as being "(Response or Report message)" Step 2) simply states that no securityStateReference is present. It would probably be worth indicating the context here too. s/no securityStateReference/no securityStateReference (Request message)/ Section 4.2, step 2) Add a comma into the list of assignments to tmStateReference cache fields. s/transportDomain tmTransportAddress/transportDomain, tmTransportAddress/ Section 5.2 Step 3) includes a (single) substep numbering "a." The equivalent text in section 4.2 has no such numbering. s/a./ / Dave From dave.shield@googlemail.com Fri Feb 6 03:10:47 2009 Return-Path: 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 4F5DB3A6AF8 for ; Fri, 6 Feb 2009 03:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 e7wof6uN8wHe for ; Fri, 6 Feb 2009 03:10:46 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id A8DAB3A685D for ; Fri, 6 Feb 2009 03:10:46 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so713274rvf.49 for ; Fri, 06 Feb 2009 03:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=o6L0bZ3eYJedxkLt+jXd2l4Sq4pGCNbYwmSFzS/9l3A=; b=al5FtIBsTM0I+cBrCBlfcMB5ZyIEiDZAwpDNNgeZMF25sz0Pccrmlw9enf9nvTMOre oZFhtX8yYi/4mbZiE/d9OuHnlj3LdFWE/Yr8qNmPphMkFech/+uAkxHixF2H68sGnIYM 4eMhrpcVOSWakU12yQF+vgUQ0jeCSlsS6J/po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=oLxkVWgz4W9QIvWkX9el+aPQXzFmysIN36MLxRn4iY18n/xgcab3M3Anc58ctmsCK+ pq8xQJuuc4Mg7ltC7T6tafWIbVbGrImoCcSGYaq0doztpEX28J0dYK0vovVCHWQ5E+qm mf/bZMKq3S3agVpRUKNYqy3LSCWkSW/mpn8xY= MIME-Version: 1.0 Sender: dave.shield@googlemail.com Received: by 10.141.106.14 with SMTP id i14mr1186858rvm.27.1233918648168; Fri, 06 Feb 2009 03:10:48 -0800 (PST) Date: Fri, 6 Feb 2009 11:10:48 +0000 X-Google-Sender-Auth: e351b764b49b146a Message-ID: From: Dave Shield To: j.schoenwaelder@jacobs-university.de, David Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: Re: [Isms] tmsm pre-16 - mandatory transport model 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: , X-List-Received-Date: Fri, 06 Feb 2009 11:10:47 -0000 2009/1/23 Juergen Schoenwaelder : > On Thu, Jan 22, 2009 at 03:43:13PM -0500, David Harrington wrote: > >> I think I have covered all the WGLC comments. > > Can the WG members please review the changes? One issue which I don't think has ever been discussed: In section 3.2.1, para 4 states: To encourage a basic level of interoperability, IETF standards typically require one mandatory-to-implement specification, with the capability of adding new mechanisms in the future..... (and then goes on to talk about the implications of this for any given transport model). Does the same thing apply to the SNMP Transport Subsystem as a whole? Is there a mandatory transport model? If so, what? Even if this is simply a conceptual transport model based on the standard UDP transport mapping (i.e. RFC3417), it might be sensible to state this explicitly here. Dave From dave.shield@googlemail.com Fri Feb 6 03:10:51 2009 Return-Path: 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 959E728C1EC for ; Fri, 6 Feb 2009 03:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 G+zlJyUhbFVW for ; Fri, 6 Feb 2009 03:10:50 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id E01B828C1E5 for ; Fri, 6 Feb 2009 03:10:50 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so713274rvf.49 for ; Fri, 06 Feb 2009 03:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=maZKdNtlsnvO4egA2v06o/ZWdqh9gNqXSTTzMaUI06I=; b=lhAjt9WDuE7bDQrL58MNyrwdkDORureqMGu9m//EzDLICj5VyNkCTuhaziw3SOT6MD oXvucHJKM0q7ah/Az9WmEgsyFpVGf4SMl1lFK5ced8//llNFxtxt85brjKBiuWz1sy8k GnIb1jYfZ04Lmiy101/tkjO5e/i/LXRGNsmZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=sSL2HzPUlkn/IUewA93rsixqGBvQIcoCk72+qyEE5NKV8dvVXXf3Pp8UxU6sXBiWo9 PQxsUTQgUEfrnQIqfTOouJidnp4zgE069OFcQDvant0fal37/qSSJ6sPYHCQ0KUiScmY ZnfuLi9e2NjyMBNrWhp275ZK99Ux4SllQAI9Q= MIME-Version: 1.0 Sender: dave.shield@googlemail.com Received: by 10.140.144.1 with SMTP id r1mr608338rvd.209.1233918653258; Fri, 06 Feb 2009 03:10:53 -0800 (PST) Date: Fri, 6 Feb 2009 11:10:53 +0000 X-Google-Sender-Auth: e34071da536a5659 Message-ID: From: Dave Shield To: j.schoenwaelder@jacobs-university.de, David Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: Re: [Isms] secshell-pre14 - transport validation 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: , X-List-Received-Date: Fri, 06 Feb 2009 11:10:51 -0000 2009/1/23 Juergen Schoenwaelder : > On Thu, Jan 22, 2009 at 03:42:22PM -0500, David Harrington wrote: > >> This is an updated draft for secshell. > > Can the WG members please review the changes? I've spotted a few (related) issues in section 5.2: Procedures for sending an Outgoing Message. 1) The ASI sendMessage includes two parameters 'destTransportDomain' and 'destTransportAddress'. The tmStateReference cache entry includes two fields 'tmTransportDomain' and 'tmTransportAddress' The expectation is clearly that these two pairs will have the same value. What should be the behaviour if they do not? 2) If the tmSameSecurity flag is set, then tmSessionID is used to look up the appropriate SSH session. What should be the behaviour if the remote end of this connection does not match the specified tmTransportAddress? Clearly, in a well-behaved environment, neither of these should occur. Is it safe to assume that these situations are impossible, or should the EoP include some form of validation? 3) Steps 1) and 2) check and extract tmTransportDomain, but the value is never used (neither here, nor in 5.3) What should be the behaviour if this value is not 'snmpSSHDomain' ? 4) Step 1) checks for the existence of various fields in the tmStateReference cache, but this list does not include tmSessionID. What should be the behaviour if this entry is missing from the cache? Does it make a difference whether tmSameSession is set or not? Dave From ietfdbh@comcast.net Fri Feb 6 15:20:50 2009 Return-Path: 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 DE00E3A6B3A for ; Fri, 6 Feb 2009 15:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 Iz3WkalULIoX for ; Fri, 6 Feb 2009 15:20:50 -0800 (PST) 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 DAFEB3A6AF5 for ; Fri, 6 Feb 2009 15:20:49 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA01.westchester.pa.mail.comcast.net with comcast id Cb9R1b0040Fqzac51nLJCN; Fri, 06 Feb 2009 23:20:18 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA08.westchester.pa.mail.comcast.net with comcast id CnLU1b00V0UQ6dC3UnLUu1; Fri, 06 Feb 2009 23:20:29 +0000 From: "David Harrington" To: "'Dave Shield'" , References: Date: Fri, 6 Feb 2009 18:20:51 -0500 Message-ID: <072e01c988b1$8d795da0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmIS5FkdFSz0QfeRd+X3J9CNNXWAwAZZRxw Cc: isms@ietf.org Subject: Re: [Isms] tmsm pre-16 - mandatory transport model 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: , X-List-Received-Date: Fri, 06 Feb 2009 23:20:51 -0000 Hi, I think the discussion of the mandatory-to-implement transport mode would distract rather than help make the point that each transport model should specify a mandatory-to-implement security mechanism. That is the reason I did not make the requested change in the last revision. So I more closely focused the sentence: To encourage a basic level of interoperability, any Transport Model SHOULD define one minimum-compliance security mechanism, but should also be able to support additional existing and new mechanisms. dbh > -----Original Message----- > From: dave.shield@googlemail.com > [mailto:dave.shield@googlemail.com] On Behalf Of Dave Shield > Sent: Friday, February 06, 2009 6:11 AM > To: j.schoenwaelder@jacobs-university.de; David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] tmsm pre-16 - mandatory transport model > > 2009/1/23 Juergen Schoenwaelder > : > > On Thu, Jan 22, 2009 at 03:43:13PM -0500, David Harrington wrote: > > > >> I think I have covered all the WGLC comments. > > > > Can the WG members please review the changes? > > One issue which I don't think has ever been discussed: > > In section 3.2.1, para 4 states: > > To encourage a basic level of interoperability, IETF standards > typically require one mandatory-to-implement > specification, with the > capability of adding new mechanisms in the future..... > > (and then goes on to talk about the implications of this for any > given transport model). > > Does the same thing apply to the SNMP Transport Subsystem as > a whole? Is there a mandatory transport model? If so, what? > > Even if this is simply a conceptual transport model based on > the standard UDP transport mapping (i.e. RFC3417), it might > be sensible to state this explicitly here. > > Dave > From ietfdbh@comcast.net Fri Feb 6 16:13:32 2009 Return-Path: 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 145F83A6B70 for ; Fri, 6 Feb 2009 16:13:32 -0800 (PST) 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 f6Dnp0Ca3WM0 for ; Fri, 6 Feb 2009 16:13:31 -0800 (PST) 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 11EF33A6A30 for ; Fri, 6 Feb 2009 16:13:30 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA04.westchester.pa.mail.comcast.net with comcast id CdpX1b01B0Fqzac54oDaNo; Sat, 07 Feb 2009 00:13:34 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA08.westchester.pa.mail.comcast.net with comcast id CoD91b00N0UQ6dC3UoDAtQ; Sat, 07 Feb 2009 00:13:10 +0000 From: "David Harrington" To: "'Dave Shield'" , References: Date: Fri, 6 Feb 2009 19:13:32 -0500 Message-ID: <072f01c988b8$e9b20d90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmISnNKqcnJ59H2SWSHfRp7S6c9lQAbIOvg Cc: isms@ietf.org Subject: Re: [Isms] tsm pre11 - minor 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: , X-List-Received-Date: Sat, 07 Feb 2009 00:13:32 -0000 > -----Original Message----- > From: dave.shield@googlemail.com > [mailto:dave.shield@googlemail.com] On Behalf Of Dave Shield > Sent: Friday, February 06, 2009 6:03 AM > To: j.schoenwaelder@jacobs-university.de; David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] tsm pre11 - minor issues > > 2009/1/23 Juergen Schoenwaelder > : > > On Thu, Jan 22, 2009 at 03:43:47PM -0500, David Harrington wrote: > > > >> I think I have covered all the WGLC comments > > > > Can the WG members please review the changes? > > A few minor nits which seem to be still present: > > Section 4.2 > Step 1) explains the presence of a securityStateReference as > being "(Response or Report message)" > > Step 2) simply states that no securityStateReference is present. > It would probably be worth indicating the context here too. > > s/no securityStateReference/no securityStateReference > (Request message)/ The RFC3411 architecture provides for extensibility, including the types of messages. We should not list all the types of messages because that would implicitly limit the extensibility. It is present in step one at somebody's request to help clarify when a securityStateReference can occur. But to add the list of message types to both sides of the condition is unnecessary and limiting. If you dislike the asymmetry, I can remove the (Response or Report message) from step 1 to make them more symmetrical. > > > Section 4.2, step 2) > Add a comma into the list of assignments to > tmStateReference cache fields. > > s/transportDomain tmTransportAddress/transportDomain, > tmTransportAddress/ > done. > > Section 5.2 > Step 3) includes a (single) substep numbering "a." > The equivalent text in section 4.2 has no such numbering. > > s/a./ / done. > > > Dave > From ietfdbh@comcast.net Fri Feb 6 16:37:20 2009 Return-Path: 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 22A953A6856 for ; Fri, 6 Feb 2009 16:37:20 -0800 (PST) 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 cKSRzEmTia9g for ; Fri, 6 Feb 2009 16:37:19 -0800 (PST) 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 05BA63A6B3F for ; Fri, 6 Feb 2009 16:37:18 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Cau21b00H0QuhwU57odNV1; Sat, 07 Feb 2009 00:37:22 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id CodM1b00F0UQ6dC3NodNZn; Sat, 07 Feb 2009 00:37:22 +0000 From: "David Harrington" To: "'Dave Shield'" , References: Date: Fri, 6 Feb 2009 19:37:20 -0500 Message-ID: <073901c988bc$3ce91ff0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmIS5RfvGOEg3WcTOKewMYk5GtQTQAbiiow Cc: isms@ietf.org Subject: Re: [Isms] secshell-pre14 - transport validation 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: , X-List-Received-Date: Sat, 07 Feb 2009 00:37:20 -0000 > -----Original Message----- > From: dave.shield@googlemail.com > [mailto:dave.shield@googlemail.com] On Behalf Of Dave Shield > Sent: Friday, February 06, 2009 6:11 AM > To: j.schoenwaelder@jacobs-university.de; David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] secshell-pre14 - transport validation > > 2009/1/23 Juergen Schoenwaelder > : > > On Thu, Jan 22, 2009 at 03:42:22PM -0500, David Harrington wrote: > > > >> This is an updated draft for secshell. > > > > Can the WG members please review the changes? > > I've spotted a few (related) issues in section 5.2: > Procedures for sending an Outgoing Message. > > > 1) The ASI sendMessage includes two parameters > 'destTransportDomain' and 'destTransportAddress'. > The tmStateReference cache entry includes two fields > 'tmTransportDomain' and 'tmTransportAddress' > > The expectation is clearly that these two pairs will have the > same value. What should be the behaviour if they do not? > tmsm states in section 6.1 "How the information in the cache is used is transport-model-dependent and implementation-dependent.", so the only place where that would be a consideration is within SSHTM, in which the EOP uses the values of tmXXXX and ignores the values of destXXX. > > 2) If the tmSameSecurity flag is set, then tmSessionID is > used to look up the appropriate SSH session. > > What should be the behaviour if the remote end of this > connection does not match the specified tmTransportAddress? > the developers should debug their implementation ??? > > Clearly, in a well-behaved environment, neither of these should > occur. Is it safe to assume that these situations are impossible, > or should the EoP include some form of validation? The sessionID is implementation-dependent, so we don't have enough information about how to validate it. > > > 3) Steps 1) and 2) check and extract tmTransportDomain, > but the value is never used (neither here, nor in 5.3) > > What should be the behaviour if this value is not > 'snmpSSHDomain' ? > the developers should debug their implementation ??? We should never hit this code if the value of tmTransportDomain is not snmpSSHDomain. The security model directs processing into SSHTM code based on tmTransportDomain=snmpSSHDomain. So this would be a programming error if they do not match. > > 4) Step 1) checks for the existence of various fields in the > tmStateReference cache, but this list does not include > tmSessionID. That is deliberate. > > What should be the behaviour if this entry is missing > from the cache? > Does it make a difference whether tmSameSession > is set or not? Yes. For a non-response, the sessionID may not get generated until the openSession() call in step 4. > > > Dave > From ietfdbh@comcast.net Fri Feb 6 16:46:38 2009 Return-Path: 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 0139C28C105 for ; Fri, 6 Feb 2009 16:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 FXBg7vFsxFIA for ; Fri, 6 Feb 2009 16:46:37 -0800 (PST) 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 0463E28C104 for ; Fri, 6 Feb 2009 16:46:36 -0800 (PST) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA05.westchester.pa.mail.comcast.net with comcast id Cc4S1b00C0ldTLk55omgqS; Sat, 07 Feb 2009 00:46:40 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA04.westchester.pa.mail.comcast.net with comcast id Comg1b0010UQ6dC3QomgUi; Sat, 07 Feb 2009 00:46:40 +0000 From: "David Harrington" To: "'Dave Shield'" , References: Date: Fri, 6 Feb 2009 19:46:38 -0500 Message-ID: <073a01c988bd$89787860$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmISlwLv7FZV2NoRZe4I1O80PsUogAckrug Cc: isms@ietf.org Subject: Re: [Isms] secshell-pre14 - minor 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: , X-List-Received-Date: Sat, 07 Feb 2009 00:46:38 -0000 > -----Original Message----- > From: dave.shield@googlemail.com > [mailto:dave.shield@googlemail.com] On Behalf Of Dave Shield > Sent: Friday, February 06, 2009 6:02 AM > To: j.schoenwaelder@jacobs-university.de; David Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] secshell-pre14 - minor issues > > 2009/1/23 Juergen Schoenwaelder > : > > On Thu, Jan 22, 2009 at 03:42:22PM -0500, David Harrington wrote: > > > >> This is an updated draft for secshell. > > > Can the WG members please review the changes? > > A few minor nits which seem to be still present: > > Section 3.1.1 2. > The references to RFC4253 (para 2) and RFC4252 (para 3) are enclosed > in both round and square brackets. All other references > throughout the > document use square brackets only. > > s/([RFC4252])/[4252]/ > s/([RFC4253])/[4253]/ fixed. > > > Section 5 > Para 3 of the introduction includes > ".... for the returned OID and value contextEngineID would > be set ..." > > Insert a comma after "value". fixed. > > > Section 5.3 > step 3 states > "If the attempt to establish a connection is unsuccessful, or > server authentication fails, then sshtmSessionOpenErrors is > incremented... and openProcessing stops." > This is the only time that sshtmSessionOpenErrors is mentioned. > > > The definition of the sshtmSessionOpenErrors MIB object states > "The number of times an openSession() request > failed to open a session as a SSH client, > for any reason." <====== > > "For any reason" is wrong. > fixed, I hope. > > > > > Dave > From dave.shield@googlemail.com Mon Feb 9 02:54:19 2009 Return-Path: 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 DF40C3A6B6B for ; Mon, 9 Feb 2009 02:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 HcHxCShhDtbW for ; Mon, 9 Feb 2009 02:54:19 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id A74243A6B46 for ; Mon, 9 Feb 2009 02:54:18 -0800 (PST) Received: by bwz5 with SMTP id 5so1109583bwz.13 for ; Mon, 09 Feb 2009 02:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=dwFEjtyo9QQIaNMiD4o+TjibMkkT6Mm9psH7UqrXBgY=; b=wSC26IkCZo+CZB72eKuvwYUhgpzb6vbOsBtrNx+C71z0Iwt//iqAySMvsjsZgsDVyK Q0MLkqgH9o/OuL/Yfcy0/CtxQt9Hy34QCGkayCu3QXbfIVwFvZ3KZePfVvVJj0Mre/9J FvpljWolfvCSxj+zw06qX+6tfu2ZAt0NMTKV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=arlfTnz4oG8ngn8AfefTnCQB2Gu0Psh95QowUoLTHKL3OJU8Q9Sk63JOLtDADwA5uN Z6KVMo/dFXiHz0xDm27jsYUQyI9KLGeLd1xERTtFnjcVXOYUAKpcHVtVxa5RP+3MhoMh M/vSl0fkOLAnh3KgLKZmOBkCyRzTv7jhRi+9o= MIME-Version: 1.0 Sender: dave.shield@googlemail.com Received: by 10.181.198.10 with SMTP id a10mr1779856bkq.120.1234176861765; Mon, 09 Feb 2009 02:54:21 -0800 (PST) In-Reply-To: <072f01c988b8$e9b20d90$0600a8c0@china.huawei.com> References: <072f01c988b8$e9b20d90$0600a8c0@china.huawei.com> Date: Mon, 9 Feb 2009 10:54:21 +0000 X-Google-Sender-Auth: ba4e24637d5dbe21 Message-ID: From: Dave Shield To: David Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: Re: [Isms] tsm pre11 - minor 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: , X-List-Received-Date: Mon, 09 Feb 2009 10:54:19 -0000 2009/2/7 David Harrington : >> Section 4.2 >> Step 1) explains the presence of a securityStateReference as >> being "(Response or Report message)" >> >> Step 2) simply states that no securityStateReference is present. >> It would probably be worth indicating the context here too. >> >> s/no securityStateReference/no securityStateReference >> (Request message)/ > > The RFC3411 architecture provides for extensibility, including the > types of messages. We should not list all the types of messages > because that would implicitly limit the extensibility. I wasn't really thinking of "(Request message)" as being prescriptive of what types of message each of these steps should be applied to. That's clearly handled by the presence or absence of the securityStateReference parameter. I just though it might be useful to give some context as to when this was likely to occur - just as had been done in the first case. If you suspect that this might be misinterpreted as being prescriptive, then fine - leave it out. (Unless you can think of another form of words which might be less open to misinterpretation - e.g "Request-style message", or even "e.g. Request-style message") > If you > dislike the asymmetry, I can remove the (Response or Report message) > from step 1 to make them more symmetrical. No - this is useful clarifying information. It would be a pity to remove it. Dave From wjhns1@hardakers.net Mon Feb 9 16:18:11 2009 Return-Path: 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 B400A3A6D38 for ; Mon, 9 Feb 2009 16:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.267, 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 M5d1Q4wdQkz2 for ; Mon, 9 Feb 2009 16:18:08 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 06AD23A68C5 for ; Mon, 9 Feb 2009 16:18:07 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 61AC22C3376; Mon, 9 Feb 2009 16:18:09 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <0b9501c97be4$024201d0$0600a8c0@china.huawei.com> <20090122194722.GB7322@elstar.local> <200901222132.n0MLW7pl021445@grapenut.srv.cs.cmu.edu> <1A950075E59BF1D8C1987832@atlantis.pc.cs.cmu.edu> Date: Mon, 09 Feb 2009 16:18:09 -0800 In-Reply-To: <1A950075E59BF1D8C1987832@atlantis.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Thu, 22 Jan 2009 21:41:41 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] ssh authn 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: , X-List-Received-Date: Tue, 10 Feb 2009 00:18:11 -0000 >>>>> On Thu, 22 Jan 2009 21:41:41 -0500, Jeffrey Hutzelman said: >> sentence 1 talks about server authn, which I assume means RFC4253. >> sentences 2-4 talk about user authn, which I assume means RFC4252 >> sentence 5 talks about server authn, which I assume means RFC4253. JH> The distinction between the different SSH documents is largely opaque JH> to SNMP, which operates at a higher layer. I agree... The text that is present currently is merely documenting how to pass information to the SSH layer that in needs. It's up to the SSH layer to decide how to use that information when communicating with the remote (SSH server) side, which depends on system configuration. We've deliberately not discussed how to do certain types of authentication with the remote side and are depending on system-specific config for authentication configuration (and other SSH configuration too). JH> I think it's quite clear and meaningful the way it is. I agree, I think the current text is fine. That being said, I think Juergen's new text is just fine too since it says pretty much the same thing. -- Wes Hardaker Sparta, Inc. From wjhns1@hardakers.net Mon Feb 9 16:40:13 2009 Return-Path: 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 224EC28C2A8 for ; Mon, 9 Feb 2009 16:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.249, 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 97qyhrtczcSW for ; Mon, 9 Feb 2009 16:40:12 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 342D128C2AF for ; Mon, 9 Feb 2009 16:40:12 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 010CD2C3376; Mon, 9 Feb 2009 16:40:14 -0800 (PST) From: Wes Hardaker To: Jeffrey Hutzelman Organization: Sparta References: <20090127083933.GC12355@elstar.local> <200901282258.n0SMw53g024330@toasties.srv.cs.cmu.edu> <4BB6D8A8E1F91F93B85A62F7@atlantis.pc.cs.cmu.edu> <200901282344.n0SNiunA000877@grapenut.srv.cs.cmu.edu> <200901290108.n0T18S7R014276@raisinbran.srv.cs.cmu.edu> <8026D632B9CA159AAC2154FA@atlantis.pc.cs.cmu.edu> Date: Mon, 09 Feb 2009 16:40:14 -0800 In-Reply-To: <8026D632B9CA159AAC2154FA@atlantis.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 28 Jan 2009 22:08:24 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David B Harrington , isms@ietf.org Subject: Re: [Isms] TBD secshell 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: , X-List-Received-Date: Tue, 10 Feb 2009 00:40:13 -0000 DH> tmSecurityName is set to "alice" by TSM. SSHTM is the place where the DH> requested tmSecurityName "alice" is overridden, and ahopkins is chosen DH> as the user name. [...] JH> You're making this all too complicated, I think. I agree! Your (David H's) original message on the subject stated: DH> I think the EOP needs to be modified to make sure the message DH> processing model can match the outgoing transportaddress for a DH> request and the incoming transportaddress from the response, which DH> is how the MPM determines which application is waiting for a DH> response. If the request was sent using a user@foo.com address, DH> then SSHTM uses parses the address into a foo.com address and uses DH> foo instead of the tmsecurityname specified by the security DH> model. When we get a response from user at foo.com, we need to make DH> the TM pass the MPM a transport address of the user@foo.com format, DH> and set the tmsecurityname to match what was requested by the DH> security model. There is only two cases to consider when talking about the SSHTM: 1) The SSHTM is acting as an SSH server. IE, it was invoked from afar and in this case the securityName used within the SNMP system will match exactly the SSH user name. Nothing confusing to behold. When the SSHTM creates a transportAddress for the connection in order to pass it upward through the SNMPv3 stack it doesn't need to be anything more complex than the remote host address, ':' and port number. The prepended SSH user name and '@' is not needed because it's equal to the securityName. 2) The SSHTM is acting as a client. IE, it is initialized from the upper SNMPv3 stack and is handed a transportAddress to talk to. It either will contain a "user@" type string or it won't. a) If it does not, again there is nothing much to consider as complex because the SSH user name will be identical to the securityName. b) If it does contain a "user@" type prefix, it should use that within the SSH protocol for identifying itself SSH-user-name-wise. This is where your problem comes in, and this is the only case that you think is confusing (right?), in particular when a response comes back. So, when a response comes back across the SSH connection, the SSHTM has to hand the message upward with a transportAddress. Your statement above indicates that you think the transportAddress passed upward should be prepended with "user@" also. That's fine by me, but I'm not sure why you think it's complex to get the right address created. The easiest solution is to cache the transportAddress that created the session and always use it when passing messages upward to through the SNMPv3 stack. done. It also assures that the upper SNMPv3 stack (specifically, your concerns with decisions in the MPM) aren't affected by reverse name lookups not matching the outgoing name, or IP addresses not matching DNS names, or whatever. DH> I don't think it will be terribly difficult to update the EOP, but I DH> am not sure where the TM stores the request-state (tmsecurityname) DH> that it must restore when it gets the response. In the same place it caches all the other information it needs to about a given SSH connection. -- Wes Hardaker Sparta, Inc. From ietfdbh@comcast.net Mon Feb 9 19:58:29 2009 Return-Path: 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 A286F3A6903 for ; Mon, 9 Feb 2009 19:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_12=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 PHYv0Kftc-pO for ; Mon, 9 Feb 2009 19:58:24 -0800 (PST) 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 A7EBF3A686D for ; Mon, 9 Feb 2009 19:58:23 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA09.westchester.pa.mail.comcast.net with comcast id DnEZ1b0030cZkys593yTyR; Tue, 10 Feb 2009 03:58:27 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id E3yQ1b00D0UQ6dC3W3yQp1; Tue, 10 Feb 2009 03:58:27 +0000 From: "David Harrington" To: Date: Mon, 9 Feb 2009 22:58:23 -0500 Message-ID: <093d01c98b33$d2d99e80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_093E_01C98B09.EA039680" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmLM9G0HxzS/QGjS3eoODbmcIO5GA== Subject: [Isms] draft-ietf-isms-tmsm-pre16a.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: , X-List-Received-Date: Tue, 10 Feb 2009 03:58:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_093E_01C98B09.EA039680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_093E_01C98B09.EA039680 Content-Type: text/plain; name="draft-ietf-isms-tmsm-pre16a.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-tmsm-pre16a.txt" Network Working Group D. Harrington Internet-Draft Huawei Technologies (USA) Updates: 3411,3412,3414,3417 J. Schoenwaelder (if approved) Jacobs University Bremen Intended status: Standards Track February 7, 2009 Expires: August 11, 2009 Transport Subsystem for the Simple Network Management Protocol (SNMP) draft-ietf-isms-tmsm-16 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 11, 2009. Abstract This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transports to include secure transports such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. Harrington & Schoenwaelder Expires August 11, 2009 [Page 1] =0C Internet-Draft SNMP Transport Subsystem February 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. The Internet-Standard Management Framework . . . . . . . . 4 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Where this Extension Fits . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements of a Transport Model . . . . . . . . . . . . . . 8 3.1. Message Security Requirements . . . . . . . . . . . . . . 8 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 8 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Architectural Modularity Requirements . . . . . . . . 9 3.2.2. Access Control Requirements . . . . . . . . . . . . . 12 3.2.3. Security Parameter Passing Requirements . . . . . . . 13 3.2.4. Separation of Authentication and Authorization . . . . 13 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 14 3.3.1. No SNMP Sessions . . . . . . . . . . . . . . . . . . . 14 3.3.2. Session Establishment Requirements . . . . . . . . . . 15 3.3.3. Session Maintenance Requirements . . . . . . . . . . . 16 3.3.4. Message security versus session security . . . . . . . 16 4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17 5. Cached Information and References . . . . . . . . . . . . . . 17 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18 5.2.1. Transport information . . . . . . . . . . . . . . . . 19 5.2.2. securityName . . . . . . . . . . . . . . . . . . . . . 19 5.2.3. securityLevel . . . . . . . . . . . . . . . . . . . . 20 5.2.4. Session Information . . . . . . . . . . . . . . . . . 21 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 21 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 22 6.2. Changes to RFC3411 Outgoing ASIs . . . . . . . . . . . . . 22 6.2.1. Message Processing Subsystem Primitives . . . . . . . 22 6.2.2. Security Subsystem Primitives . . . . . . . . . . . . 24 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 25 6.4. Changes to RFC3411 Incoming ASIs . . . . . . . . . . . . . 26 6.4.1. Message Processing Subsystem Primitive . . . . . . . . 26 6.4.2. Security Subsystem Primitive . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7.1. Coexistence, Security Parameters, and Access Control . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 34 A.1. Define an Abstract Service Interface . . . . . . . . . . . 34 A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 34 A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 35 Harrington & Schoenwaelder Expires August 11, 2009 [Page 2] =0C Internet-Draft SNMP Transport Subsystem February 2009 A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 35 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Harrington & Schoenwaelder Expires August 11, 2009 [Page 3] =0C Internet-Draft SNMP Transport Subsystem February 2009 1. Introduction This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in [RFC3411]. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. 1.1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. 1.2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Non uppercased versions of the keywords should be read as in normal English. They will usually, but not always, be used in a context relating to compatibility with the RFC3411 architecture or the subsystem defined here, but which might have no impact on on-the-wire compatibility. These terms are used as guidance for designers of proposed IETF models to make the designs compatible with RFC3411 subsystems and Abstract Service Interfaces (ASIs) (see section 3.2). Implementers are free to implement differently. Some usages of these lowercase terms are simply normal English usage. For consistency with SNMP-related specifications, this document favors terminology as defined in STD62 rather than favoring terminology that is consistent with non-SNMP specifications that use different variations of the same terminology. This is consistent with the IESG decision to not require the SNMPv3 terminology be modified to match the usage of other non-SNMP specifications when SNMPv3 was advanced to Full Standard. 1.3. Where this Extension Fits It is expected that readers of this document will have read RFC3410 and RFC3411, and have a general understanding of the functionality defined in RFCs 3412-3418. The "Transport Subsystem" is an additional component for the SNMP Engine depicted in RFC3411, section 3.1. Harrington & Schoenwaelder Expires August 11, 2009 [Page 4] =0C Internet-Draft SNMP Transport Subsystem February 2009 The following diagram depicts its place in the RFC3411 architecture.: +-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +------------+ | | | | | Transport | | | | | | Subsystem | | | | | +------------+ | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Proxy | | | | | | Generator | | Receiver | | Forwarder | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Other | | | | | | Responder | | Originator | | | | | | | +-------------+ +--------------+ +--------------+ | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+ The transport mappings defined in RFC3417 do not provide lower-layer security functionality, and thus do not provide transport-specific security parameters. This document updates RFC3411 and RFC3417 by defining an architectural extension and modifying the ASIs that transport mappings (hereafter called transport models) can use to pass transport-specific security parameters to other subsystems, including transport-specific security parameters that are translated into the transport-independent securityName and securityLevel parameters The Transport Security Model [I-D.ietf-isms-transport-security-model] Harrington & Schoenwaelder Expires August 11, 2009 [Page 5] =0C Internet-Draft SNMP Transport Subsystem February 2009 and the Secure Shell Transport Model [I-D.ietf-isms-secshell] utilize the Transport Subsystem. The Transport Security Model is an alternative to the existing SNMPv1 Security Model [RFC3584], the SNMPv2c Security Model [RFC3584], and the User-based Security Model [RFC3414]. The Secure Shell Transport Model is an alternative to existing transport mappings as described in [RFC3417]. 2. Motivation Just as there are multiple ways to secure one's home or business, in a continuum of alternatives, there are multiple ways to secure a network management protocol. Let's consider three general approaches. In the first approach, an individual could sit on his front porch waiting for intruders. In the second approach, he could hire an employee , schedule the employee, position the employee to guard what he wants protected, hire a second guard to cover if the first gets sick, and so on. In the third approach, he could hire a security company, tell them what he wants protected, and leave the details to them. Considerations of hiring and training employees, positioning and scheduling the guards, arranging for cover, etc., are the responsibility of the security company. The individual therefore achieves the desired security, with no significant effort on his part other than identifying requirements and verifying the quality of service being provided. The User-based Security Model (USM) as defined in [RFC3414] largely uses the first approach - it provides its own security. It utilizes existing mechanisms (e.g., SHA), but provides all the coordination. USM provides for the authentication of a principal, message encryption, data integrity checking, timeliness checking, etc. USM was designed to be independent of other existing security infrastructures. USM therefore requires a separate principal and key management infrastructure. Operators have reported that deploying another principal and key management infrastructure in order to use SNMPv3 is a deterrent to deploying SNMPv3. It is possible to use external mechanisms to handle the distribution of keys for use by USM. The more important issue is that operators wanted to leverage existing user base infrastructures that were not specific to SNMP. A USM-compliant architecture might combine the authentication mechanism with an external mechanism, such as RADIUS [RFC2865] to provide the authentication service. Similarly it might be possible to utilize an external protocol to encrypt a message, to check timeliness, to check data integrity, etc. However this corresponds to the second approach - requiring the coordination of a number of Harrington & Schoenwaelder Expires August 11, 2009 [Page 6] =0C Internet-Draft SNMP Transport Subsystem February 2009 differently subcontracted services. Building solid security between the various services is difficult, and there is a significant potential for gaps in security. An alternative approach might be to utilize one or more lower-layer security mechanisms to provide the message-oriented security services required. These would include authentication of the sender, encryption, timeliness checking, and data integrity checking. This corresponds to the third approach described above. There are a number of IETF standards available or in development to address these problems through security layers at the transport layer or application layer, among them TLS [RFC5246], SASL [RFC4422], and SSH [RFC4251] From an operational perspective, it is highly desirable to use security mechanisms that can unify the administrative security management for SNMPv3, command line interfaces (CLIs) and other management interfaces. The use of security services provided by lower layers is the approach commonly used for the CLI, and is also the approach being proposed for other network management protocols, such as syslog [I-D.ietf-syslog-protocol] and NETCONF [RFC4741]. This document defines a Transport Subsystem extension to the RFC3411 architecture based on the third approach. This extension specifies how other lower layer protocols with common security infrastructures can be used underneath the SNMP protocol and the desired goal of unified administrative security can be met. This extension allows security to be provided by an external protocol connected to the SNMP engine through an SNMP Transport Model [RFC3417]. Such a Transport Model would then enable the use of existing security mechanisms such as (TLS) [RFC5246] or SSH [RFC4251] within the RFC3411 architecture. There are a number of Internet security protocols and mechanisms that are in wide spread use. Many of them try to provide a generic infrastructure to be used by many different application layer protocols. The motivation behind the Transport Subsystem is to leverage these protocols where it seems useful. There are a number of challenges to be addressed to map the security provided by a secure transport into the SNMP architecture so that SNMP continues to provide interoperability with existing implementations. These challenges are described in detail in this document. For some key issues, design choices are described that might be made to provide a workable solution that meets operational requirements and fits into the SNMP architecture defined in [RFC3411]. Harrington & Schoenwaelder Expires August 11, 2009 [Page 7] =0C Internet-Draft SNMP Transport Subsystem February 2009 3. Requirements of a Transport Model 3.1. Message Security Requirements Transport security protocols SHOULD provide protection against the following message-oriented threats: 1. modification of information 2. masquerade 3. message stream modification 4. disclosure These threats are described in section 1.4 of [RFC3411]. It is not required to protect against denial of service or traffic analysis, but it should not make those threats significantly worse. 3.1.1. Security Protocol Requirements There are a number of standard protocols that could be proposed as possible solutions within the Transport Subsystem. Some factors should be considered when selecting a protocol. Using a protocol in a manner for which it was not designed has numerous problems. The advertised security characteristics of a protocol might depend on it being used as designed; when used in other ways, it might not deliver the expected security characteristics. It is recommended that any proposed model include a description of the applicability of the Transport Model. A Transport Model SHOULD NOT require modifications to the underlying protocol. Modifying the protocol might change its security characteristics in ways that could impact other existing usages. If a change is necessary, the change SHOULD be an extension that has no impact on the existing usages. Any Transport Model SHOULD include a description of potential impact on other usages of the protocol. Since multiple transport models can exist simultaneously within the transport subsystem, transport models MUST be able to coexist with each other. 3.2. SNMP Requirements Harrington & Schoenwaelder Expires August 11, 2009 [Page 8] =0C Internet-Draft SNMP Transport Subsystem February 2009 3.2.1. Architectural Modularity Requirements SNMP version 3 (SNMPv3) is based on a modular architecture (defined in [RFC3411] section 3) to allow the evolution of the SNMP protocol standards over time, and to minimize side effects between subsystems when changes are made. The RFC3411 architecture includes a Message Processing Subsystem permitting different message versions to be handled by a single engine, a Security Subsystem for enabling different methods of providing security services, Applications(s) to support different types of application processors, and an Access Control Subsystem for allowing multiple approaches to access control. The RFC3411 architecture does not include a subsystem for Transport Models, despite the fact there are multiple transport mappings already defined for SNMP. This document describes a Transport Subsystem that is compatible with the RFC3411 architecture. As work is being done to use secure transports such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. The design of this Transport Subsystem accepts the goals of the RFC3411 architecture defined in section 1.5 of [RFC3411]. This Transport Subsystem uses a modular design that permits Transport Models (which may or may not be security-aware) to be "plugged into" the RFC3411 architecture . Such Transport Models would be independent of other modular SNMP components as much as possible. This design also permits Transport Models to be advanced through the standards process independently of other Transport Models. To encourage a basic level of interoperability, any Transport Model SHOULD define one mandatory-to-implement security mechanism, but = should also be able to support additional existing and new mechanisms. The following diagram depicts the SNMPv3 architecture including the new Transport Subsystem defined in this document, and a new Transport Security Model defined in [I-D.ietf-isms-transport-security-model]. Harrington & Schoenwaelder Expires August 11, 2009 [Page 9] =0C Internet-Draft SNMP Transport Subsystem February 2009 +------------------------------+ | Network | +------------------------------+ ^ ^ ^ | | | v v v +-------------------------------------------------------------------+ | +--------------------------------------------------+ | | | Transport Subsystem | | | | +-----+ +-----+ +-----+ +-----+ +-------+ | | | | | UDP | | TCP | | SSH | | TLS | . . . | other | | | | | +-----+ +-----+ +-----+ +-----+ +-------+ | | | +--------------------------------------------------+ | | ^ | | | | | Dispatcher v | | +-------------------+ +---------------------+ +----------------+ | | | Transport | | Message Processing | | Security | | | | Dispatch | | Subsystem | | Subsystem | | | | | | +------------+ | | +------------+ | | | | | | +->| v1MP |<--->| | USM | | | | | | | | +------------+ | | +------------+ | | | | | | | +------------+ | | +------------+ | | | | | | +->| v2cMP |<--->| | Transport | | | | | Message | | | +------------+ | | | Security | | | | | Dispatch <--------->| +------------+ | | | Model | | | | | | | +->| v3MP |<--->| +------------+ | | | | | | | +------------+ | | +------------+ | | | | PDU Dispatch | | | +------------+ | | | Other | | | | +-------------------+ | +->| otherMP |<--->| | Model(s) | | | | ^ | +------------+ | | +------------+ | | | | +---------------------+ +----------------+ | | v | | +-------+-------------------------+---------------+ | | ^ ^ ^ | | | | | | | v v v | | +-------------+ +---------+ +--------------+ +-------------+ | | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | | | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | | | application | | | | applications | | application | | | +-------------+ +---------+ +--------------+ +-------------+ | | ^ ^ | | | | | | v v | | +----------------------------------------------+ | | | MIB instrumentation | SNMP entity | +-------------------------------------------------------------------+ Harrington & Schoenwaelder Expires August 11, 2009 [Page 10] =0C Internet-Draft SNMP Transport Subsystem February 2009 3.2.1.1. Changes to the RFC3411 Architecture The RFC3411 architecture and the Security Subsystem assume that a Security Model is called by a Message Processing Model and will perform multiple security functions within the Security Subsystem. A Transport Model that supports a secure transport protocol might perform similar security functions within the Transport Subsystem, including the translation of transport security parameters to/from security-model-independent parameters. To accommodate this, an implementation-specific cache of transport- specific information will be described (not shown), and the data flows on this path will be extended to pass security-model- independent values. This document amends some of the ASIs defined in RFC 3411, and these changes are covered in section 6. New Security Models may be defined that understand how to work with these modified ASIs and the transport-information cache. One such Security Model, the Transport Security Model, is defined in [I-D.ietf-isms-transport-security-model]. 3.2.1.2. Changes to RFC3411 processing The introduction of secure transports affects the responsibilities and order of processing within the RFC3411 architecture. While the steps are the same, they may occur in a different order, and may be done by different subsystems. With the existing RFC3411 architecture, security processing starts when the Message Processing Model decodes portions of the encoded message to extract parameters that identify which Security Model should handle the security-related tasks. A secure transport performs those security functions on the message, before the message is decoded. Some of these functions might then be repeated by the selected Security Model. 3.2.1.3. Passing Information between SNMP Engines A secure Transport Model will establish an authenticated and possibly encrypted tunnel between the Transport Models of two SNMP engines. After a transport layer tunnel is established, then SNMP messages can be sent through the tunnel from one SNMP engine to the other. Transport Models MAY support sending multiple SNMP messages through the same tunnel. Harrington & Schoenwaelder Expires August 11, 2009 [Page 11] =0C Internet-Draft SNMP Transport Subsystem February 2009 3.2.2. Access Control Requirements RFC3411 made some design decisions related to the support of an Access Control Subsystem. These include establishing and passing in a model-independent manner the securityModel, securityName and securityLevel parameters, and separating message authentication from data access authorization. 3.2.2.1. securityName and securityLevel Mapping SNMP data access controls are expected to work on the basis of who can perform what operations on which subsets of data, and based on the security services that will be provided to secure the data in transit. The securityModel and securityLevel parameters establish the protections for transit - whether authentication and privacy services will be or have been applied to the message. The securityName is a model-independent identifier of the security "principal". A Security Model plays a role in security that goes beyond protecting the message - it provides a mapping between the security-model- specific principal for an incoming message to a security-model independent securityName which can be used for subsequent processing, such as for access control. The securityName is mapped from a mechanism-specific identity, and this mapping must be done for incoming messages by the Security Model before it passes securityName to the Message Processing Model via the processIncoming ASI. A Security Model is also responsible to specify, via the securityLevel parameter, whether incoming messages have been authenticated and encrypted, and to ensure that outgoing messages are authenticated and encrypted based on the value of securityLevel. A Transport Model MAY provide suggested values for securityName and securityLevel. A Security Model may have multiple sources for determining the principal and desired security services, and a particular Security Model may or may not utilize the values proposed by a Transport Model when deciding the value of securityName and securityLevel. Documents defining a new transport domain MUST define a prefix that MAY be prepended by the Security Model to all passed securityNames. The prefix MUST include from one to four ASCII characters, not including a ":" (ASCII 0x3a) character. If a prefix is used, a securityName is constructed by concatenating the prefix and a ":" (ASCII 0x3a) character followed by a non-empty identity in an snmpAdminString compatible format. Transport domains and their corresponding prefixes are coordinated via the IANA registry "SNMP Harrington & Schoenwaelder Expires August 11, 2009 [Page 12] =0C Internet-Draft SNMP Transport Subsystem February 2009 Transport Domains". 3.2.3. Security Parameter Passing Requirements A Message Processing Model might unpack SNMP-specific security parameters from an incoming message before calling a specific Security Model to handle the security-related processing of the message. When using a secure Transport Model, some security parameters might be extracted from the transport layer by the Transport Model before the message is passed to the Message Processing Subsystem. This document describes a cache mechanism (see Section 5), into which the Transport Model puts information about the transport and security parameters applied to a transport connection or an incoming message, and a Security Model may extract that information from the cache. A tmStateReference is passed as an extra parameter in the ASIs between the Transport Subsystem, the Message Processing and Security Subsystems, to identify the relevant cache. This approach of passing a model-independent reference is consistent with the securityStateReference cache already being passed around in the RFC3411 ASIs. 3.2.4. Separation of Authentication and Authorization The RFC3411 architecture defines a separation of authentication and the authorization to access and/or modify MIB data. A set of model- independent parameters (securityModel, securityName, and securityLevel) are passed between the Security Subsystem, the applications, and the Access Control Subsystem. This separation was a deliberate decision of the SNMPv3 WG, to allow support for authentication protocols which do not provide data access authorization capabilities, and to support data access authorization schemes, such as VACM, that do not perform their own authentication. A Message Processing Model determines which Security Model is used, either based on the message version, e.g., SNMPv1 and SNMPv2c, or possibly by a value specified in the message, e.g., msgSecurityModel field in SNMPv3. The Security Model makes the decision which securityName and securityLevel values are passed as model-independent parameters to an application, which then passes them via the isAccessAllowed ASI to the Access Control Subsystem. An Access Control Model performs the mapping from the model- independent security parameters to a policy within the Access Control Harrington & Schoenwaelder Expires August 11, 2009 [Page 13] =0C Internet-Draft SNMP Transport Subsystem February 2009 Model that is access-control-model-dependent. A Transport Model does not know which Security Model will be used for an incoming message, so cannot know how the securityName and securityLevel parameters will be determined. It can propose an authenticated identity (via the tmSecurityName field), but there is no guarantee that this value will be used by the Security Model. For example, non-transport-aware Security Models will typically determine the securityName (and securityLevel) based on the contents of the SNMP message itself. Such Security Models will simply not know that the tmStateReference cache exists. Further, even if the Transport Model can influence the choice of securityName, it cannot directly determine the authorization allowed to this identity. If two different Transport Models each authenticate a transport principal, that are then both mapped to the same securityName, then these two identities will typically be afforded exactly the same authorization by the Access Control Model. The only way for the Access Control Model to differentiate between identities based on the underlying Transport Model, would be for such transport-authenticated identities to be mapped to distinct securityNames. How and if this is done is Security-Model-dependent. 3.3. Session Requirements Some secure transports have a notion of sessions, while other secure transports provide channels or other session-like mechanism. Throughout this document, the term session is used in a broad sense to cover transport sessions, transport channels, and other transport- layer session-like mechanisms. Transport-layer sessions that can secure multiple SNMP messages within the lifetime of the session are considered desirable because the cost of authentication can be amortized over potentially many transactions. How a transport session is actually established, opened, closed, or maintained is specific to a particular Transport Model. To reduce redundancy, this document describes aspects that are expected to be common to all Transport Model sessions. 3.3.1. No SNMP Sessions The architecture defined in [RFC3411] and the Transport Subsystem defined in this document do not support SNMP sessions or include a session selector in the Abstract Service Interfaces. The Transport Subsystem may support transport sessions. However, the transport subsystem does not have access to the pduType, so cannot Harrington & Schoenwaelder Expires August 11, 2009 [Page 14] =0C Internet-Draft SNMP Transport Subsystem February 2009 select a given transport session for particular types of traffic. Certain parameters of these ASIs might be used to guide the selection of an appropriate transport session to use for a given request by an application. The transportDomain and transportAddress identify the transport connection to a remote network node. Elements of the transport address (such as the port number) might be used by an application to send a particular PDU type to a particular transport address. The securityName identifies which security principal to communicate with at that address (e.g., different NMS applications), and the securityLevel might permit selection of different sets of security properties for different purposes (e.g., encrypted SETs vs. non- encrypted GETs). However, because the handling of transport sessions is specific to each transport model, some transport models MAY restrict selecting a particular transport session. An application might use a unique combination of transportDomain, transportAddress, securityModel, securityName, and securityLevel to try to force the selection of a given transport session. This usage is NOT RECOMMENDED because it is not guaranteed to be interoperable across implementatioins and across models. Implementations SHOULD be able to maintain some reasonable number of concurrent transport sessions, and MAY provide non-standard internal mechanisms to select transport sessions. 3.3.2. Session Establishment Requirements SNMP applications provide the transportDomain, transportAddress, securityName, and securityLevel to be used to create a new session. If the Transport Model cannot provide at least the requested level of security, the Transport Model SHOULD discard the message and SHOULD notify the dispatcher that establishing a session and sending the message failed. Similarly, if the session cannot be established, then the message SHOULD be discarded and the dispatcher notified. Transport session establishment might require provisioning authentication credentials at an engine, either statically or dynamically. How this is done is dependent on the transport model and the implementation. Harrington & Schoenwaelder Expires August 11, 2009 [Page 15] =0C Internet-Draft SNMP Transport Subsystem February 2009 3.3.3. Session Maintenance Requirements A Transport Model can tear down sessions as needed. It might be necessary for some implementations to tear down sessions as the result of resource constraints, for example. The decision to tear down a session is implementation-dependent. How an implementation determines that an operation has completed is implementation-dependent. While it is possible to tear down each transport session after processing for each message has completed, this is not recommended for performance reasons. The elements of procedure describe when cached information can be discarded, and the timing of cache cleanup might have security implications, but cache memory management is an implementation issue. If a Transport Model defines MIB module objects to maintain session state information, then the Transport Model MUST define what SHOULD happen to the objects when a related session is torn down, since this will impact interoperability of the MIB module. 3.3.4. Message security versus session security A Transport Model session is associated with state information that is maintained for its lifetime. This state information allows for the application of various security services to multiple messages. Cryptographic keys associated with the transport session SHOULD be used to provide authentication, integrity checking, and encryption services, as needed, for data that is communicated during the session. The cryptographic protocols used to establish keys for a Transport Model session SHOULD ensure that fresh new session keys are generated for each session. This would ensure that a cross-session replay attack would be unsuccessful; that is, an attacker could not take a message observed on one session, and successfully replay this on another session. A good security protocol would also protect against replay attacks within a session; that is, an attacker could not take a message observed on a session, and successfully replay this later in the same session. One approach would be to use sequence information within the protocol, allowing the participants to detect if messages were replayed or reordered within a session. If a secure transport session is closed between the time a request message is received, and the corresponding response message is sent, then the response message SHOULD be discarded, even if a new session has been established. The SNMPv3 WG decided that this should be a SHOULD architecturally, and it is a security-model-specific decision Harrington & Schoenwaelder Expires August 11, 2009 [Page 16] =0C Internet-Draft SNMP Transport Subsystem February 2009 whether to REQUIRE this. SNMPv3 was designed to support multiple levels of security, selectable on a per-message basis by an SNMP application, because, for example, there is not much value in using encryption for a Commander Generator to poll for potentially non-sensitive performance data on thousands of interfaces every ten minutes; the encryption might add significant overhead to processing of the messages. Some Transport Models might support only specific authentication and encryption services, such as requiring all messages to be carried using both authentication and encryption, regardless of the security level requested by an SNMP application. A Transport Model MAY upgrade the security level requested by a transport-aware security model, i.e. noAuthNoPriv and authNoPriv might be sent over an authenticated and encrypted session. A Transport Model MUST NOT downgrade the security level requested by a transport-aware security model, and SHOULD discard any message where this would occur. 4. Scenario Diagrams and the Transport Subsystem RFC3411 section 4.6.1 and 4.6.2 provide scenario diagrams to illustrate how an outgoing message is created, and how an incoming message is processed. RFC3411 does not define ASIs for the "Send SNMP Request Message to Network", "Receive SNMP Response Message from Network", "Receive SNMP Message from Network" and "Send SNMP message to Network" arrows in these diagrams. This document defines two ASIs corresponding to these arrows: a sendMessage ASI to send SNMP messages to the network, and a receiveMessage ASI to receive SNMP messages from the network. These ASIs are used for all SNMP messages, regardless of pduType. 5. Cached Information and References When performing SNMP processing, there are two levels of state information that may need to be retained: the immediate state linking a request-response pair, and potentially longer-term state relating to transport and security. The RFC3411 architecture uses caches to maintain the short-term message state, and uses references in the ASIs to pass this information between subsystems. This document defines the requirements for a cache to handle additional short-term message state and longer-term transport state information, using a tmStateReference parameter to pass this information between subsystems. Harrington & Schoenwaelder Expires August 11, 2009 [Page 17] =0C Internet-Draft SNMP Transport Subsystem February 2009 To simplify the elements of procedure, the release of state information is not always explicitly specified. As a general rule, if state information is available when a message being processed gets discarded, the state related to that message SHOULD also be discarded. If state information is available when a relationship between engines is severed, such as the closing of a transport session, the state information for that relationship SHOULD also be discarded. Since the contents of a cache are meaningful only within an implementation, and not on-the-wire, the format of the cache is implementation-specific. 5.1. securityStateReference The securityStateReference parameter is defined in RFC3411. Its primary purpose is to provide a mapping between a request and the corresponding response. This cache is not accessible to Transport Models, and an entry is typically only retained for the lifetime of a request-response pair of messages. 5.2. tmStateReference For each transport session, information about the transport security is stored in a tmState cache or datastore, that is referenced by a tmStateReference. The tmStateReference parameter is used to pass model-specific and mechanism-specific parameters between the Transport subsystem and transport-aware Security Models. In general, when necessary, the tmState is populated by the security model for outgoing messages and by the transport model for incoming messages. However, in both cases, the model populating the tmState may have incomplete information, and the missing information might be populated by the other model when the information becomes available. The tmState might contain both long-term and short-term information. The session information typically remains valid for the duration of the transport session, might be used for several messages, and might be stored in a local configuration datastore. Some information has a shorter lifespan, such as tmSameSecurity and tmRequestedSecurityLevel which are associated with a specific message. Since this cache is only used within an implementation, and not on- the-wire, the precise contents and format of the cache are implementation-dependent. For architectural modularity between Transport Models and transport-aware Security Models, a fully-defined tmState MUST conceptually include at least the following fields: Harrington & Schoenwaelder Expires August 11, 2009 [Page 18] =0C Internet-Draft SNMP Transport Subsystem February 2009 tmTransportDomain tmTransportAddress tmSecurityName tmRequestedSecurityLevel tmTransportSecurityLevel tmSameSecurity tmSessionID The details of these fields are described in the following subsections. 5.2.1. Transport information Information about the source of an incoming SNMP message is passed up from the Transport subsystem as far as the Message Processing subsystem. However these parameters are not included in the processIncomingMsg ASI defined in RFC3411, and hence this information is not directly available to the Security Model. A transport-aware Security Model might wish to take account of the transport protocol and originating address when authenticating the request, and setting up the authorization parameters. It is therefore necessary for the Transport Model to include this information in the tmStateReference cache, so that it is accessible to the Security Model. o tmTransportDomain: the transport protocol (and hence the Transport Model) used to receive the incoming message o tmTransportAddress: the source of the incoming message. The ASIs used for processing an outgoing message all include explicit transportDomain and transportAddress parameters. The values within the securityStateReference cache might override these parameters for outgoing messages. 5.2.2. securityName There are actually three distinct "identities" that can be identified during the processing of an SNMP request over a secure transport: Harrington & Schoenwaelder Expires August 11, 2009 [Page 19] =0C Internet-Draft SNMP Transport Subsystem February 2009 o transport principal: the transport-authenticated identity, on whose behalf the secure transport connection was (or should be) established. This value is transport-, mechanism- and implementation- specific, and is only used within a given Transport Model. o tmSecurityName: a human-readable name (in snmpAdminString format) representing this transport identity. This value is transport- and implementation-specific, and is only used (directly) by the Transport and Security Models. o securityName: a human-readable name (in snmpAdminString format) representing the SNMP principal in a model-independent manner. This value is used directly by SNMP Applications, the access control subsystem, the message processing subsystem, and the security subsystem. The transport principal may or may not be the same as the tmSecurityName. Similarly, the tmSecurityName may or may not be the same as the securityName as seen by the Application and Access Control subsystems. In particular, a non-transport-aware Security Model will ignore tmSecurityName completely when determining the SNMP securityName. However it is important that the mapping between the transport principal and the SNMP securityName (for transport-aware Security Models) is consistent and predictable, to allow configuration of suitable access control and the establishment of transport connections. 5.2.3. securityLevel There are two distinct issues relating to security level as applied to secure transports. For clarity, these are handled by separate fields in the tmStateReference cache: o tmTransportSecurityLevel: an indication from the Transport Model of the level of security offered by this session. The Security Model can use this to ensure that incoming messages were suitably protected before acting on them. o tmRequestedSecurityLevel: an indication from the Security Model of the level of security required to be provided by the transport protocol. The Transport Model can use this to ensure that outgoing messages will not be sent over an insufficiently secure session. Harrington & Schoenwaelder Expires August 11, 2009 [Page 20] =0C Internet-Draft SNMP Transport Subsystem February 2009 5.2.4. Session Information For security reasons, if a secure transport session is closed between the time a request message is received and the corresponding response message is sent, then the response message SHOULD be discarded, even if a new session has been established. The SNMPv3 WG decided that this should be a SHOULD architecturally, and it is a security-model- specific decision whether to REQUIRE this. o tmSameSecurity: this flag is used by a transport-aware Security Model to indicate whether the Transport Model MUST enforce this restriction. o tmSessionID: in order to verify whether the session has changed, the Transport Model must be able to compare the session used to receive the original request with the one to be used to send the response. This typically requires some form of session identifier. This value is only ever used by the Transport Model, so the format and interpretation of this field are model-specific and implementation-dependent. When processing an outgoing message, if tmSameSecurity is true, then the tmSessionID MUST match the current transport session, otherwise the message MUST be discarded, and the dispatcher notified that sending the message failed. 6. Abstract Service Interfaces Abstract service interfaces have been defined by RFC 3411 to describe the conceptual data flows between the various subsystems within an SNMP entity, and to help keep the subsystems independent of each other except for the common parameters. This document introduces a couple of new ASIs to define the interface between the Transport and Dispatcher Subsystems, and extends some of the ASIs defined in RFC3411 to include transport-related information. This document follows the example of RFC3411 regarding the release of state information, and regarding error indications. 1) The release of state information is not always explicitly specified in a transport model. As a general rule, if state information is available when a message gets discarded, the message- state information should also be released, and if state information is available when a session is closed, the session state information should also be released. Keeping sensitive security information longer than necessary might introduce potential vulnerabilities to an implementation. Harrington & Schoenwaelder Expires August 11, 2009 [Page 21] =0C Internet-Draft SNMP Transport Subsystem February 2009 2)An error indication in statusInformation will typically include the OID and value for an incremented error counter. This may be accompanied by values for contextEngineID and contextName for this counter, a value for securityLevel, and the appropriate state reference if the information is available at the point where the error is detected. 6.1. sendMessage ASI The sendMessage ASI is used to pass a message from the Dispatcher to the appropriate Transport Model for sending. In the diagram in section 4.6.1 of RFC 3411, the sendMessage ASI defined in this document replaces the text "Send SNMP Request Message to Network". In section 4.6.2, the sendMessage ASI replaces the text "Send SNMP Message to Network" If present and valid, the tmStateReference refers to a cache containing transport-model-specific parameters for the transport and transport security. How a tmStateReference is determined to be present and valid is implementation-dependent. How the information in the cache is used is transport-model-dependent and implementation- dependent. This may sound underspecified, but a transport model might be something like SNMP over UDP over IPv6, where no security is provided, so it might have no mechanisms for utilizing a tmStateReference cache. statusInformation =3D sendMessage( IN destTransportDomain -- transport domain to be used IN destTransportAddress -- transport address to be used IN outgoingMessage -- the message to send IN outgoingMessageLength -- its length IN tmStateReference -- reference to transport state ) 6.2. Changes to RFC3411 Outgoing ASIs Additional parameters have been added to the ASIs defined in RFC3411, concerned with communication between the Dispatcher and Message Processing subsystems, and between the Message Processing and Security Subsystems. 6.2.1. Message Processing Subsystem Primitives A tmStateReference parameter has been added as an OUT parameter to the prepareOutgoingMessage and prepareResponseMessage ASIs. This is Harrington & Schoenwaelder Expires August 11, 2009 [Page 22] =0C Internet-Draft SNMP Transport Subsystem February 2009 passed from Message Processing Subsystem to the dispatcher, and from there to the Transport Subsystem. How or if the Message Processing Subsystem modifies or utilizes the contents of the cache is message-processing-model specific. statusInformation =3D -- success or errorIndication prepareOutgoingMessage( IN transportDomain -- transport domain to be used IN transportAddress -- transport address to be used IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN expectResponse -- TRUE or FALSE IN sendPduHandle -- the handle for matching incoming responses OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length OUT tmStateReference -- (NEW) reference to transport state ) statusInformation =3D -- success or errorIndication prepareResponseMessage( IN messageProcessingModel -- typically, SNMP version IN securityModel -- Security Model to use IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN contextEngineID -- data from/at this entity IN contextName -- data from/in this context IN pduVersion -- the version of the PDU IN PDU -- SNMP Protocol Data Unit IN maxSizeResponseScopedPDU -- maximum size able to accept IN stateReference -- reference to state information -- as presented with the request IN statusInformation -- success or errorIndication -- error counter OID/value if error OUT destTransportDomain -- destination transport domain OUT destTransportAddress -- destination transport address OUT outgoingMessage -- the message to send OUT outgoingMessageLength -- its length OUT tmStateReference -- (NEW) reference to transport state Harrington & Schoenwaelder Expires August 11, 2009 [Page 23] =0C Internet-Draft SNMP Transport Subsystem February 2009 ) 6.2.2. Security Subsystem Primitives transportDomain and transportAddress parameters have been added as IN parameters to the generateRequestMsg and generateResponseMsg ASIs, and a tmStateReference parameter has been added as an OUT parameter. The transportDomain and transportAddress parameters will have been passed into the Message Processing Subsystem from the dispatcher, and are passed on to the Security Subsystem. The tmStateReference parameter will be passed from the Security Subsystem back to the Message Processing Subsystem, and on to the dispatcher and Transport subsystems. If a cache exists for a session identifiable from the tmTransportDomain, tmTransportAddress, tmSecurityName and requested securityLevel, then a transport-aware Security Model might create a tmStateReference parameter to this cache, and pass that as an OUT parameter. statusInformation =3D generateRequestMsg( IN transportDomain -- (NEW) destination transport domain IN transportAddress -- (NEW) destination transport address IN messageProcessingModel -- typically, SNMP version IN globalData -- message header, admin data IN maxMessageSize -- of the sending SNMP entity IN securityModel -- for the outgoing message IN securityEngineID -- authoritative SNMP entity IN securityName -- on behalf of this principal IN securityLevel -- Level of Security requested IN scopedPDU -- message (plaintext) payload OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message OUT tmStateReference -- (NEW) reference to transport state ) Harrington & Schoenwaelder Expires August 11, 2009 [Page 24] =0C Internet-Draft SNMP Transport Subsystem February 2009 statusInformation =3D generateResponseMsg( IN transportDomain -- (NEW) destination transport domain IN transportAddress -- (NEW) destination transport address IN messageProcessingModel -- Message Processing Model IN globalData -- msgGlobalData IN maxMessageSize -- from msgMaxSize IN securityModel -- as determined by MPM IN securityEngineID -- the value of snmpEngineID IN securityName -- on behalf of this principal IN securityLevel -- for the outgoing message IN scopedPDU -- as provided by MPM IN securityStateReference -- as provided by MPM OUT securityParameters -- filled in by Security Module OUT wholeMsg -- complete generated message OUT wholeMsgLength -- length of generated message OUT tmStateReference -- (NEW) reference to transport state ) 6.3. The receiveMessage ASI The receiveMessage ASI is used to pass a message from the Transport Subsystem to the Dispatcher. In the diagram in section 4.6.1 of RFC 3411, the receiveMessage ASI replaces the text "Receive SNMP Response Message from Network". In section 4.6.2, the receiveMessage ASI replaces the text "Receive SNMP Message from Network". When a message is received on a given transport session, if a cache does not already exist for that session, the Transport Model might create one, referenced by tmStateReference. The contents of this cache are discussed in section 5. How this information is determined is implementation- and transport-model-specific. "Might create one" may sound underspecified, but a transport model might be something like SNMP over UDP over IPv6, where transport security is not provided, so it might not create a cache. The Transport Model does not know the securityModel for an incoming message; this will be determined by the Message Processing Model in a message-processing-model-dependent manner. Harrington & Schoenwaelder Expires August 11, 2009 [Page 25] =0C Internet-Draft SNMP Transport Subsystem February 2009 statusInformation =3D receiveMessage( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN incomingMessage -- the message received IN incomingMessageLength -- its length IN tmStateReference -- reference to transport state ) 6.4. Changes to RFC3411 Incoming ASIs The tmStateReference parameter has also been added to some of the incoming ASIs defined in RFC3411. How or if a Message Processing Model or Security Model uses tmStateReference is message-processing- and security-model-specific. This may sound underspecified, but a message processing model might have access to all the information from the cache and from the message. The Message Processing Model might determine that the USM Security Model is specified in an SNMPv3 message header; the USM Security Model has no need of values in the tmStateReference cache to authenticate and secure the SNMP message, but an application might have specified to use a secure transport such as that provided by the SSH Transport Model to send the message to its destination. 6.4.1. Message Processing Subsystem Primitive The tmStateReference parameter of prepareDataElements is passed from the dispatcher to the Message Processing Subsystem. How or if the Message Processing Subsystem modifies or utilizes the contents of the cache is message-processing-model-specific. Harrington & Schoenwaelder Expires August 11, 2009 [Page 26] =0C Internet-Draft SNMP Transport Subsystem February 2009 result =3D -- SUCCESS or errorIndication prepareDataElements( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN wholeMsg -- as received from the network IN wholeMsgLength -- as received from the network IN tmStateReference -- (NEW) from the Transport Model OUT messageProcessingModel -- typically, SNMP version OUT securityModel -- Security Model to use OUT securityName -- on behalf of this principal OUT securityLevel -- Level of Security requested OUT contextEngineID -- data from/at this entity OUT contextName -- data from/in this context OUT pduVersion -- the version of the PDU OUT PDU -- SNMP Protocol Data Unit OUT pduType -- SNMP PDU type OUT sendPduHandle -- handle for matched request OUT maxSizeResponseScopedPDU -- maximum size sender can accept OUT statusInformation -- success or errorIndication -- error counter OID/value if error OUT stateReference -- reference to state information -- to be used for possible Response ) 6.4.2. Security Subsystem Primitive The processIncomingMessage ASI passes tmStateReference from the Message Processing Subsystem to the Security Subsystem. If tmStateReference is present and valid, an appropriate Security Model might utilize the information in the cache. How or if the Security Subsystem utilizes the information in the cache is security- model-specific. Harrington & Schoenwaelder Expires August 11, 2009 [Page 27] =0C Internet-Draft SNMP Transport Subsystem February 2009 statusInformation =3D -- errorIndication or success -- error counter OID/value if error processIncomingMsg( IN messageProcessingModel -- typically, SNMP version IN maxMessageSize -- of the sending SNMP entity IN securityParameters -- for the received message IN securityModel -- for the received message IN securityLevel -- Level of Security IN wholeMsg -- as received on the wire IN wholeMsgLength -- length as received on the wire IN tmStateReference -- (NEW) from the Transport Model OUT securityEngineID -- authoritative SNMP entity OUT securityName -- identification of the principal OUT scopedPDU, -- message (plaintext) payload OUT maxSizeResponseScopedPDU -- maximum size sender can handle OUT securityStateReference -- reference to security state ) -- information, needed for response 7. Security Considerations This document defines an architectural approach that permits SNMP to utilize transport layer security services. Each proposed Transport Model should discuss the security considerations of that Transport Model. It is considered desirable by some industry segments that SNMP Transport Models should utilize transport layer security that addresses perfect forward secrecy at least for encryption keys. Perfect forward secrecy guarantees that compromise of long term secret keys does not result in disclosure of past session keys. Each proposed Transport Model should include a discussion in its security considerations of whether perfect forward security is appropriate for that Transport Model. The Denial of Service characteristics of various transport models and security protocols will vary and should be evaluated when determining the applicability of a transport model to a particular deployment situation. Since the cache will contain security-related parameters, implementers should store this information (in memory or in persistent storage) in a manner to protect it from unauthorized disclosure and/or modification. Care must be taken to ensure that a SNMP engine is sending packets out over a transport using credentials that are legal for that engine to use on behalf of that user. Otherwise an engine that has multiple transports open might be "tricked" into sending a message through the Harrington & Schoenwaelder Expires August 11, 2009 [Page 28] =0C Internet-Draft SNMP Transport Subsystem February 2009 wrong transport. A Security Model may have multiple sources from which to define the securityName and securityLevel. The use of a secure Transport Model does not imply that the securityName and securityLevel chosen by the Security Model represent the transport-authenticated identity or the transport-provided security services. The securityModel, securityName, and securityLevel parameters are a related set, and an administrator should understand how the specified securityModel selects the corresponding securityName and securityLevel. 7.1. Coexistence, Security Parameters, and Access Control In the RFC3411 architecture, the Message Processing Model makes the decision about which Security Model to use. The architectural change described by this document does not alter that. The architecture change described by this document does however, allow SNMP to support two different approaches to security - message- driven security and transport-driven security. With message-driven security, SNMP provides its own security, and passes security parameters within the SNMP message; with transport-driven security, SNMP depends on an external entity to provide security during transport by "wrapping" the SNMP message. In times of network stress, the security protocol and its underlying security mechanisms SHOULD NOT depend upon the ready availability of other network services (e.g., Network Time Protocol (NTP) or Authentication, Authorization, and Accounting (AAA) protocols or certificate authorities). The User-based Security Model was explicitly designed to not depend upon external network services, and provides its own security services. It is RECOMMENDED that operators provision authPriv USM to supplement any security model or transport model that has external dependencies, so that secure SNMP communications can continue when the external network service is not available. Using a non-transport-aware security model with a secure transport model is NOT RECOMMENDED, for the following reasons. Security models defined before the Transport Security Model (i.e., SNMPv1, SNMPv2c, and USM) do not support transport-based security, and only have access to the security parameters contained within the SNMP message. They do not know about the security parameters associated with a secure transport. As a result, the Access Control Subsystem bases its decisions on the security parameters extracted from the SNMP message, not on transport-based security parameters. Harrington & Schoenwaelder Expires August 11, 2009 [Page 29] =0C Internet-Draft SNMP Transport Subsystem February 2009 Implications of combining older security models with secure transport models are known. The securityName used for access control decisions is based on the message-driven identity, which might be unauthenticated, not the transport-driven authenticated identity: o An SNMPv1 message will always be paired with an SNMPv1 Security Model (per RFC3584), regardless of the transport mapping or transport model used, and access controls will be based on the unauthenticated community name. o An SNMPv2c message will always be paired with an SNMPv2c Security Model (per RFC3584), regardless of the transport mapping or transport model used, and access controls will be based on the unauthenticated community name. o An SNMPv3 message will always be paired with the securityModel specified in the msgSecurityParameters field of the message (per RFC3412), regardless of the transport mapping or transport model used. If the SNMPv3 message specifies the User-based Security Model (USM), with noAuthNoPriv, then the access controls will be based on the unauthenticated USM user. o For outgoing messages, if a secure transport model is selected in combination with a security model that does not populate a tmStateReference, the secure transport model SHOULD detect the lack of a valid tmStateReference and fail. 8. IANA Considerations IANA is requested to create a new registry in the Simple Network Management Protocol (SNMP) Number Spaces. The new registry should be called "SNMP Transport Domains". This registry will contain ASCII strings of one to four characters to identify prefixes for corresponding SNMP transport domains. Each transport domain requires an OID assignment under snmpDomains [RFC2578] . Values are to be assigned via [RFC5226] "Specification Required". The registry should be populated with the following initial entries: Harrington & Schoenwaelder Expires August 11, 2009 [Page 30] =0C Internet-Draft SNMP Transport Subsystem February 2009 Registry Name: SNMP Transport Domains Reference: [RFC2578] [RFC3417] [XXXX] Registration Procedures: Specification Required Each domain is assigned a MIB-defined OID under snmpDomains Prefix snmpDomains Reference ------- ----------------------------- --------- udp snmpUDPDomain RFC3417 clns snmpCLNSDomain RFC3417 cons snmpCONSDomain RFC3417 ddp snmpDDPDomain RFC3417 ipx snmpIPXDomain RFC3417 prxy rfc1157Domain RFC3417 -- NOTE to RFC editor: replace XXXX with actual RFC number -- for this document and remove this note 9. Acknowledgments The Integrated Security for SNMP WG would like to thank the following people for their contributions to the process: The authors of submitted Security Model proposals: Chris Elliot, Wes Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David Perkins, Joseph Salowey, and Juergen Schoenwaelder. The members of the Protocol Evaluation Team: Uri Blumenthal, Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla. WG members who performed detailed reviews: Jeffrey Hutzelman, Bert Wijnen, Tom Petch, Wes Hardaker, and Dave Shield. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, Harrington & Schoenwaelder Expires August 11, 2009 [Page 31] =0C Internet-Draft SNMP Transport Subsystem February 2009 April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. 10.2. Informative References [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Harrington & Schoenwaelder Expires August 11, 2009 [Page 32] =0C Internet-Draft SNMP Transport Subsystem February 2009 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [I-D.ietf-isms-transport-security-model] Harrington, D. and W. Hardaker, "Transport Security Model for SNMP", d raft-ietf-isms-transport- security-model-10 (work in progress), October 2008. [I-D.ietf-isms-secshell] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Harrington & Schoenwaelder Expires August 11, 2009 [Page 33] =0C Internet-Draft SNMP Transport Subsystem February 2009 Model for SNMP", draft-ietf-isms-secshell-13 (work in progress), November 2008. [I-D.ietf-syslog-protocol] Gerhards, R., "The syslog Protocol", draft-ietf- syslog-protocol-23 (work in progress), September 2007. Appendix A. Why tmStateReference? This appendix considers why a cache-based approach was selected for passing parameters. There are four approaches that could be used for passing information between the Transport Model and a Security Model. 1. one could define an ASI to supplement the existing ASIs, or 2. one could add a header to encapsulate the SNMP message, 3. one could utilize fields already defined in the existing SNMPv3 message, or 4. one could pass the information in an implementation-specific cache or via a MIB module. A.1. Define an Abstract Service Interface Abstract Service Interfaces (ASIs) are defined by a set of primitives that specify the services provided and the abstract data elements that are to be passed when the services are invoked. Defining additional ASIs to pass the security and transport information from the Transport Subsystem to Security Subsystem has the advantage of being consistent with existing RFC3411/3412 practice, and helps to ensure that any Transport Model proposals pass the necessary data, and do not cause side effects by creating model-specific dependencies between itself and other models or other subsystems other than those that are clearly defined by an ASI. A.2. Using an Encapsulating Header A header could encapsulate the SNMP message to pass necessary information from the Transport Model to the dispatcher and then to a Message Processing Model. The message header would be included in the wholeMessage ASI parameter, and would be removed by a corresponding Message Processing Model. This would imply the (one Harrington & Schoenwaelder Expires August 11, 2009 [Page 34] =0C Internet-Draft SNMP Transport Subsystem February 2009 and only) messaging dispatcher would need to be modified to determine which SNMP message version was involved, and a new Message Processing Model would need to be developed that knew how to extract the header from the message and pass it to the Security Model. A.3. Modifying Existing Fields in an SNMP Message [RFC3412] defines the SNMPv3 message, which contains fields to pass security related parameters. The Transport Subsystem could use these fields in an SNMPv3 message, or comparable fields in other message formats to pass information between Transport Models in different SNMP engines, and to pass information between a Transport Model and a corresponding Message Processing Model. If the fields in an incoming SNMPv3 message are changed by the Transport Model before passing it to the Security Model, then the Transport Model will need to decode the ASN.1 message, modify the fields, and re-encode the message in ASN.1 before passing the message on to the message dispatcher or to the transport layer. This would require an intimate knowledge of the message format and message versions so the Transport Model knew which fields could be modified. This would seriously violate the modularity of the architecture. A.4. Using a Cache This document describes a cache, into which the Transport Model puts information about the security applied to an incoming message, and a Security Model can extract that information from the cache. Given that there might be multiple TM-security caches, a tmStateReference is passed as an extra parameter in the ASIs between the Transport Subsystem and the Security Subsystem, so the Security Model knows which cache of information to consult. This approach does create dependencies between a specific Transport Model and a corresponding specific Security Model. However, the approach of passing a model-independent reference to a model- dependent cache is consistent with the securityStateReference already being passed around in the RFC3411 ASIs. Appendix B. Open Issues NOTE to RFC editor: If this section is empty, then please remove this open issues section before publishing this document as an RFC. (If it is not empty, please send it back to the editor to resolve. o Harrington & Schoenwaelder Expires August 11, 2009 [Page 35] =0C Internet-Draft SNMP Transport Subsystem February 2009 Appendix C. Change Log NOTE to RFC editor: Please remove this change log before publishing this document as an RFC. Changes from -15- to -16- o editorial changes o clarified long-term vs short-term nature of tmState o removed any references to LCD Changes from -14- to -15- o editorial changes and reorganization Changes from -13- to -14- o Changes from -12- to -13- o moved conventions after Internet Standard framework, for consistency with related documents. o editorial changes and reorganization Changes from -10- to -12- o clarified relation to other documents. o clarified relation to older security models. o moved comparison of TSM and USM to TSM document Changes from -09- to -10- o Pointed to companion documents o Wordsmithed extensively o Modified the note about SNMPv3-consistent terminology o Modified the note about RFC2119 terminology. o Modified discussion of cryptographic key generation. Harrington & Schoenwaelder Expires August 11, 2009 [Page 36] =0C Internet-Draft SNMP Transport Subsystem February 2009 o Added security considerations about coexistence with older security models o Expanded discussion of same session functionality o Described how sendMessage and receiveMessage fit into RFC3411 diagrams o Modified prepareResponseMessage ASI Changes from -08- to -09- o A question was raised that notifications would not work properly, but we could never find the circumstances where this was true. o removed appendix with parameter matrix o Added a note about terminology, for consistency with SNMPv3 rather than with RFC2828. Changes from -07- to -08- o Identified new parameters in ASIs. o Added discussion about well-known ports. Changes from -06- to -07- o Removed discussion of double authentication o Removed all direct and indirect references to pduType by Transport Subsystem o Added warning regarding keeping sensitive security information available longer than needed. o Removed knowledge of securityStateReference from Transport Subsystem. o Changed transport session identifier to not include securityModel, since this is not known for incoming messages until the message processing model. Changes from revision -05- to -06- mostly editorial changes Harrington & Schoenwaelder Expires August 11, 2009 [Page 37] =0C Internet-Draft SNMP Transport Subsystem February 2009 removed some paragraphs considered unnecessary added Updates to header modified some text to get the security details right modified text re: ASIs so they are not API-like cleaned up some diagrams cleaned up RFC2119 language added section numbers to citations to RFC3411 removed gun for political correctness Changes from revision -04- to -05- removed all objects from the MIB module. changed document status to "Standard" rather than the xml2rfc default of informational. changed mention of MD5 to SHA moved addressing style to TDomain and TAddress modified the diagrams as requested removed the "layered stack" diagrams that compared USM and a Transport Model processing removed discussion of speculative features that might exist in future Transport Models removed openSession and closeSession ASIs, since those are model- dependent removed the MIB module removed the MIB boilerplate intro (this memo defines a SMIv2 MIB ) removed IANA considerations related to the now-gone MIB module removed security considerations related to the MIB module Harrington & Schoenwaelder Expires August 11, 2009 [Page 38] =0C Internet-Draft SNMP Transport Subsystem February 2009 removed references needed for the MIB module changed receiveMessage ASI to use origin transport domain/address updated Parameter CSV appendix Changes from revision -03- to -04- changed title from Transport Mapping Security Model Architectural Extension to Transport Subsystem modified the abstract and introduction changed TMSM to TMS changed MPSP to simply Security Model changed SMSP to simply Security Model changed TMSP to Transport Model removed MPSP and TMSP and SMSP from Acronyms section modified diagrams removed most references to dispatcher functionality worked to remove dependencies between transport and security models. defined snmpTransportModel enumeration similar to snmpSecurityModel, etc. eliminated all reference to SNMPv3 msgXXXX fields changed tmSessionReference back to tmStateReference Changes from revision -02- to -03- o removed session table from MIB module o removed sessionID from ASIs o reorganized to put ASI discussions in EOP section, as was done in SSHSM o changed user auth to client auth Harrington & Schoenwaelder Expires August 11, 2009 [Page 39] =0C Internet-Draft SNMP Transport Subsystem February 2009 o changed tmStateReference to tmSessionReference o modified document to meet consensus positions published by JS * authoritative is model-specific * msgSecurityParameters usage is model-specific * msgFlags vs. securityLevel is model/implementation-specific * notifications must be able to cause creation of a session * security considerations must be model-specific * TDomain and TAddress are model-specific * MPSP changed to SMSP (Security Model security processing) Changes from revision -01- to -02- o wrote text for session establishment requirements section. o wrote text for session maintenance requirements section. o removed section on relation to SNMPv2-MIB o updated MIB module to pass smilint o Added Structure of the MIB module, and other expected MIB-related sections. o updated author address o corrected spelling o removed msgFlags appendix o Removed section on implementation considerations. o started modifying the security boilerplate to address TMS and MIB security issues o reorganized slightly to better separate requirements from proposed solution. This probably needs additional work. o removed section with sample protocols and sample tmSessionReference. Harrington & Schoenwaelder Expires August 11, 2009 [Page 40] =0C Internet-Draft SNMP Transport Subsystem February 2009 o Added section for acronyms o moved section comparing parameter passing techniques to appendix. o Removed section on notification requirements. Changes from revision -00- o changed SSH references from I-Ds to RFCs o removed parameters from tmSessionReference for DTLS that revealed lower layer info. o Added TMS-MIB module o Added Internet-Standard Management Framework boilerplate o Added Structure of the MIB Module o Added MIB security considerations boilerplate (to be completed) o Added IANA Considerations o Added ASI Parameter table o Added discussion of Sessions o Added Open issues and Change Log o Rearranged sections Authors' Addresses David Harrington Huawei Technologies (USA) 1700 Alma Dr. Suite 100 Plano, TX 75075 USA Phone: +1 603 436 8634 EMail: dharrington@huawei.com Harrington & Schoenwaelder Expires August 11, 2009 [Page 41] =0C Internet-Draft SNMP Transport Subsystem February 2009 Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 EMail: j.schoenwaelder@iu-bremen.de Harrington & Schoenwaelder Expires August 11, 2009 [Page 42] =0C Internet-Draft SNMP Transport Subsystem February 2009 Full Copyright Statement Copyright (C) The IETF Trust (2009). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Harrington & Schoenwaelder Expires August 11, 2009 [Page 43] =0C ------=_NextPart_000_093E_01C98B09.EA039680-- From ietfdbh@comcast.net Mon Feb 9 19:59:09 2009 Return-Path: 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 405363A686D for ; Mon, 9 Feb 2009 19:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[AWL=-1.712, BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, J_CHICKENPOX_57=0.6, MANGLED_TOOL=2.3] 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 dhY1Dj+BgJTf for ; Mon, 9 Feb 2009 19:59:04 -0800 (PST) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id E399B3A6A74 for ; Mon, 9 Feb 2009 19:59:03 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA10.westchester.pa.mail.comcast.net with comcast id Dw271b0240QuhwU5A3z7be; Tue, 10 Feb 2009 03:59:07 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id E3z61b0090UQ6dC3N3z6up; Tue, 10 Feb 2009 03:59:07 +0000 From: "David Harrington" To: Date: Mon, 9 Feb 2009 22:59:05 -0500 Message-ID: <094101c98b33$eaf68ff0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0942_01C98B0A.022087F0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmLM+qxOMPxdZmaR9ar7oENPW6RIA== Subject: [Isms] draft-ietf-isms-transport-security-model-pre11a.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: , X-List-Received-Date: Tue, 10 Feb 2009 03:59:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0942_01C98B0A.022087F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0942_01C98B0A.022087F0 Content-Type: text/plain; name="draft-ietf-isms-transport-security-model-pre11a.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-transport-security-model-pre11a.txt" =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Intended status: Standards Track W. Hardaker=0A= Expires: August 13, 2009 Sparta, Inc.=0A= February 9, 2009=0A= =0A= =0A= Transport Security Model for SNMP=0A= draft-ietf-isms-transport-security-model-11=0A= =0A= Status of This Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on August 13, 2009.=0A= =0A= Abstract=0A= =0A= This memo describes a Transport Security Model for the Simple Network=0A= Management Protocol.=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for monitoring and managing the Transport Security Model for=0A= SNMP.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 3=0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 1]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 2. How the Transport Security Model Fits in the Architecture . . 5=0A= 2.1. Security Capabilities of this Model . . . . . . . . . . . 6=0A= 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 6=0A= 2.2. Transport Sessions . . . . . . . . . . . . . . . . . . . . 7=0A= 2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 7=0A= 2.3.1. Coexistence with Message Processing Models . . . . . . 7=0A= 2.3.2. Coexistence with Other Security Models . . . . . . . . 7=0A= 2.3.3. Coexistence with Transport Models . . . . . . . . . . 8=0A= 3. Cached Information and References . . . . . . . . . . . . . . 8=0A= 3.1. Transport Security Model Cached Information . . . . . . . 8=0A= 3.1.1. securityStateReference . . . . . . . . . . . . . . . . 8=0A= 3.1.2. tmStateReference . . . . . . . . . . . . . . . . . . . 8=0A= 3.1.3. Prefixes and securityNames . . . . . . . . . . . . . . 9=0A= 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 9=0A= 4.1. Security Processing for an Outgoing Message . . . . . . . 9=0A= 4.2. Elements of Procedure for Outgoing Messages . . . . . . . 10=0A= 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 11=0A= 5.1. Security Processing for an Incoming Message . . . . . . . 12=0A= 5.2. Elements of Procedure for Incoming Messages . . . . . . . 12=0A= 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 13=0A= 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 13=0A= 6.1.1. The snmpTsmStats Subtree . . . . . . . . . . . . . . . 14=0A= 6.1.2. The snmpTsmConfiguration Subtree . . . . . . . . . . . 14=0A= 6.2. Relationship to Other MIB Modules . . . . . . . . . . . . 14=0A= 6.2.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 14=0A= 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 14=0A= 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19=0A= 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 19=0A= 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20=0A= 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21=0A= 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21=0A= 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21=0A= 11.2. Informative References . . . . . . . . . . . . . . . . . . 22=0A= Appendix A. Notification Tables Configuration . . . . . . . . . . 22=0A= A.1. Transport Security Model Processing for Notifications . . 24=0A= Appendix B. Processing Differences between USM and Secure=0A= Transport . . . . . . . . . . . . . . . . . . . . . . 25=0A= B.1. USM and the RFC3411 Architecture . . . . . . . . . . . . . 25=0A= B.2. Transport Subsystem and the RFC3411 Architecture . . . . . 26=0A= Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 26=0A= Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 26=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 2]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= 1. Introduction=0A= =0A= This memo describes a Transport Security Model for the Simple Network=0A= Management Protocol, for use with secure Transport Models in the=0A= Transport Subsystem [I-D.ietf-isms-tmsm].=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for monitoring and managing the Transport Security Model for=0A= SNMP.=0A= =0A= It is important to understand the SNMP architecture and the=0A= terminology of the architecture to understand where the Transport=0A= Security Model described in this memo fits into the architecture and=0A= interacts with other subsystems and models within the architecture.=0A= It is expected that reader will have also read and understood RFC3411=0A= [RFC3411], RFC3412 [RFC3412], RFC3413 [RFC3413], and RFC3418=0A= [RFC3418].=0A= =0A= 1.1. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= Managed objects are accessed via a virtual information store, termed=0A= the Management Information Base or MIB. MIB objects are generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in the=0A= Structure of Management Information (SMI). This memo specifies a MIB=0A= module that is compliant to the SMIv2, which is described in STD 58,=0A= RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580=0A= [RFC2580].=0A= =0A= 1.2. Conventions=0A= =0A= For consistency with SNMP-related specifications, this document=0A= favors terminology as defined in STD62 rather than favoring=0A= terminology that is consistent with non-SNMP specifications that use=0A= different variations of the same terminology. This is consistent=0A= with the IESG decision to not require the SNMPv3 terminology be=0A= modified to match the usage of other non-SNMP specifications when=0A= SNMPv3 was advanced to Full Standard.=0A= =0A= Authentication in this document typically refers to the English=0A= meaning of "serving to prove the authenticity of" the message, not=0A= data source authentication or peer identity authentication.=0A= =0A= The terms "manager" and "agent" are not used in this document,=0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 3]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= because in the RFC 3411 architecture, all SNMP entities have the=0A= capability of acting as either manager or agent or both depending on=0A= the SNMP applications included in the engine. Where distinction is=0A= required, the application names of Command Generator, Command=0A= Responder, Notification Originator, Notification Receiver, and Proxy=0A= Forwarder are used. See "SNMP Applications" [RFC3413] for further=0A= information.=0A= =0A= While security protocols frequently refer to a user, the terminology=0A= used in RFC3411 [RFC3411] and in this memo is "principal". A=0A= principal is the "who" on whose behalf services are provided or=0A= processing takes place. A principal can be, among other things, an=0A= individual acting in a particular role; a set of individuals, with=0A= each acting in a particular role; an application or a set of=0A= applications, or a combination of these within an administrative=0A= domain.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= 1.3. Modularity=0A= =0A= The reader is expected to have read and understood the description of=0A= the SNMP architecture, as defined in [RFC3411], and the architecture=0A= extension specified in "Transport Subsystem for the Simple Network=0A= Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of=0A= external "lower layer transport" protocols to provide message=0A= security, tied into the SNMP architecture through the Transport=0A= Subsystem. The Transport Security Model is designed to work with=0A= such lower-layer secure Transport Models.=0A= =0A= In keeping with the RFC 3411 design decisions to use self-contained=0A= documents, this memo includes the elements of procedure plus=0A= associated MIB objects which are needed for processing the Transport=0A= Security Model for SNMP. These MIB objects SHOULD NOT be referenced=0A= in other documents. This allows the Transport Security Model to be=0A= designed and documented as independent and self-contained, having no=0A= direct impact on other modules, and allowing this module to be=0A= upgraded and supplemented as the need arises, and to move along the=0A= standards track on different time-lines from other modules.=0A= =0A= This modularity of specification is not meant to be interpreted as=0A= imposing any specific requirements on implementation.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 4]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= 1.4. Motivation=0A= =0A= This memo describes a Security Model to make use of Transport Models=0A= that use lower layer secure transports and existing and commonly=0A= deployed security infrastructures. This Security Model is designed=0A= to meet the security and operational needs of network administrators,=0A= maximize usability in operational environments to achieve high=0A= deployment success and at the same time minimize implementation and=0A= deployment costs to minimize the time until deployment is possible.=0A= =0A= 1.5. Constraints=0A= =0A= The design of this SNMP Security Model is also influenced by the=0A= following constraints:=0A= =0A= 1. In times of network stress, the security protocol and its=0A= underlying security mechanisms SHOULD NOT depend solely upon the=0A= ready availability of other network services (e.g., Network Time=0A= Protocol (NTP) or Authentication, Authorization, and Accounting=0A= (AAA) protocols).=0A= =0A= 2. When the network is not under stress, the Security Model and its=0A= underlying security mechanisms MAY depend upon the ready=0A= availability of other network services.=0A= =0A= 3. It may not be possible for the Security Model to determine when=0A= the network is under stress.=0A= =0A= 4. A Security Model should require no changes to the SNMP=0A= architecture.=0A= =0A= 5. A Security Model should require no changes to the underlying=0A= security protocol.=0A= =0A= 2. How the Transport Security Model Fits in the Architecture=0A= =0A= The Transport Security Model is designed to fit into the RFC3411=0A= architecture as a Security Model in the Security Subsystem, and to=0A= utilize the services of a secure Transport Model.=0A= =0A= For incoming messages, a secure Transport Model will pass a=0A= tmStateReference cache, described later. To maintain RFC3411=0A= modularity, the Transport Model will not know which securityModel=0A= will process the incoming message; the Message Processing Model will=0A= determine this. If the Transport Security Model is used with a non-=0A= secure Transport Model, then the cache will not exist or not be=0A= populated with security parameters, which will cause the Transport=0A= Security Model to return an error (see section 5.2)=0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 5]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= The Transport Security Model will create the securityName and=0A= securityLevel to be passed to applications, and verify that the=0A= tmTransportSecurityLevel reported by the Transport Model is at least=0A= as strong as the securityLevel requested by the Message Processing=0A= Model.=0A= =0A= For outgoing messages, the Transport Security Model will create a=0A= tmStateReference cache (or use an existing one), and pass the=0A= tmStateReference to the specified Transport Model.=0A= =0A= 2.1. Security Capabilities of this Model=0A= =0A= 2.1.1. Threats=0A= =0A= The Transport Security Model is compatible with the RFC3411=0A= architecture, and provides protection against the threats identified=0A= by the RFC 3411 architecture. However, the Transport Security Model=0A= does not provide security mechanisms such as authentication and=0A= encryption itself, so it SHOULD always be used with a Transport Model=0A= that provides appropriate security. Which threats are addressed and=0A= how they are mitigated depends on the Transport Model.=0A= =0A= 2.1.2. Security Levels=0A= =0A= The RFC 3411 architecture recognizes three levels of security:=0A= =0A= - without authentication and without privacy (noAuthNoPriv)=0A= =0A= - with authentication but without privacy (authNoPriv)=0A= =0A= - with authentication and with privacy (authPriv)=0A= =0A= The model-independent securityLevel parameter is used to request=0A= specific levels of security for outgoing messages, and to assert that=0A= specific levels of security were applied during the transport and=0A= processing of incoming messages.=0A= =0A= The transport layer algorithms used to provide security SHOULD NOT be=0A= exposed to the Transport Security Model, as the Transport Security=0A= Model has no mechanisms by which it can test whether an assertion=0A= made by a Transport Model is accurate.=0A= =0A= The Transport Security Model trusts that the underlying secure=0A= transport connection has been properly configured to support security=0A= characteristics at least as strong as reported in=0A= tmTransportSecurityLevel.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 6]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= 2.2. Transport Sessions=0A= =0A= The Transport Security Model does not work with transport sessions=0A= directly. Instead the transport-related state is associated with a=0A= unique combination of transportDomain, transportAddress, securityName=0A= and securityLevel, and referenced via the tmStateReference parameter.=0A= How and if this is mapped to a particular transport or channel is the=0A= responsibility of the Transport Subsystem.=0A= =0A= 2.3. Coexistence=0A= =0A= In the RFC3411 architecture, a Message Processing Model determines=0A= which Security Model should be called. As of this writing, IANA has=0A= registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/=0A= SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1,=0A= SNMPv2c, and the User-based Security Model).=0A= =0A= 2.3.1. Coexistence with Message Processing Models=0A= =0A= The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP=0A= 74) [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security=0A= Models. Since there is no mechanism defined in RFC3584 to select an=0A= alternative Security Model, SNMPv1 and SNMPv2c messages cannot use=0A= the Transport Security Model. Such messages can still be conveyed=0A= over a secure transport protocol, but the Transport Security Model=0A= will not be invoked.=0A= =0A= The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact=0A= for which there is no existing IETF specification.=0A= =0A= The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts=0A= the securityModel from the msgSecurityModel field of an incoming=0A= SNMPv3Message. When this value is transportSecurityModel(YY),=0A= security processing is directed to the Transport Security Model. For=0A= an outgoing message to be secured using the Transport Security Model,=0A= the application should specify a securityModel parameter value of=0A= transportSecurityModel(YY) in the sendPdu ASI.=0A= =0A= [-- NOTE to RFC editor: replace YY with actual IANA-assigned number,=0A= and remove this note. ]=0A= =0A= 2.3.2. Coexistence with Other Security Models=0A= =0A= The Transport Security Model uses its own MIB module for processing=0A= to maintain independence from other Security Models. This allows the=0A= Transport Security Model to coexist with other Security Models, such=0A= as the User-based Security Model.=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 7]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= 2.3.3. Coexistence with Transport Models=0A= =0A= The Transport Security Model may work with multiple Transport Models,=0A= but the RFC3411 application service interfaces (ASIs) do not carry a=0A= value for the Transport Model. The MIB module defined in this memo=0A= allows an administrator to configure whether or not TSM prepends a=0A= transport model prefix to the securityName. This will allow SNMP=0A= applications to consider transport model as a factor when making=0A= decisions, such as access control, notification generation, and proxy=0A= forwarding.=0A= =0A= 3. Cached Information and References=0A= =0A= When performing SNMP processing, there are two levels of state=0A= information that may need to be retained: the immediate state linking=0A= a request-response pair, and potentially longer-term state relating=0A= to transport and security. "Transport Subsystem for the Simple=0A= Network Management Protocol" [I-D.ietf-isms-tmsm] defines general=0A= requirements for caches and references.=0A= =0A= This document defines additional cache requirements related to the=0A= Transport Security Model.=0A= =0A= 3.1. Transport Security Model Cached Information=0A= =0A= The Transport Security Model has specific responsibilities regarding=0A= the cached information.=0A= =0A= 3.1.1. securityStateReference=0A= =0A= The Transport Security Model adds the tmStateReference received from=0A= the processIncomingMsg ASI to the securityStateReference. This=0A= tmStateReference can then be retrieved during the generateResponseMsg=0A= ASI, so that it can be passed back to the Transport Model.=0A= =0A= 3.1.2. tmStateReference=0A= =0A= For outgoing messages, the Transport Security Model uses parameters=0A= provided by the SNMP application to lookup or create a=0A= tmStateReference.=0A= =0A= The Transport Security Model REQUIRES that the security parameters=0A= used for a response are the same as those used for the corresponding=0A= request. This security model uses the tmStateReference stored as=0A= part of the securityStateReference when appropriate. For responses=0A= and reports, this security model sets the tmSameSecurity flag to true=0A= in the tmStateReference before passing it to a transport model.=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 8]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= For incoming messages, the Transport Security Model uses parameters=0A= provided in the tmStateReference cache to establish a securityName,=0A= and to verify adequate security levels.=0A= =0A= 3.1.3. Prefixes and securityNames=0A= =0A= The SNMP-VIEW-BASED-ACM-MIB [RFC3415], the SNMP-TARGET-MIB module=0A= [RFC3413], and other MIB modules contain objects to configure=0A= security parameters for use by applications such as access control,=0A= notification generation, and proxy forwarding.=0A= =0A= IANA maintains a registry for transport domains and the corresponding=0A= prefix.=0A= =0A= If snmpTsmConfigurationUsePrefix is set to true then all=0A= securityNames provided by, or provided to, the Transport Security=0A= Model MUST include a valid transport domain prefix.=0A= =0A= If snmpTsmConfigurationUsePrefix is set to false then all=0A= securityNames provided by, or provided to, the Transport Security=0A= Model MUST NOT include a transport domain prefix.=0A= =0A= The tmSecurityName in the tmStateReference stored as part of the=0A= securityStateReference does not contain a prefix.=0A= =0A= 4. Processing an Outgoing Message=0A= =0A= An error indication may return an OID and value for an incremented=0A= counter and a value for securityLevel, and values for contextEngineID=0A= and contextName for the counter, and the securityStateReference if=0A= the information is available at the point where the error is=0A= detected.=0A= =0A= 4.1. Security Processing for an Outgoing Message=0A= =0A= This section describes the procedure followed by the Transport=0A= Security Model.=0A= =0A= The parameters needed for generating a message are supplied to the=0A= Security Model by the Message Processing Model via the=0A= generateRequestMsg() or the generateResponseMsg() ASI. The Transport=0A= Subsystem architectural extension has added the transportDomain,=0A= transportAddress, and tmStateReference parameters to the original=0A= RFC3411 ASIs.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 9]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= statusInformation =3D -- success or errorIndication=0A= generateRequestMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN transportDomain -- (NEW) specified by application=0A= IN transportAddress -- (NEW) specified by application=0A= IN securityModel -- for the outgoing message=0A= IN securityEngineID -- authoritative SNMP entity=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN scopedPDU -- message (plaintext) payload=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- (NEW) transport info=0A= )=0A= =0A= =0A= statusInformation =3D -- success or errorIndication=0A= generateResponseMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN transportDomain -- (NEW) specified by application=0A= IN transportAddress -- (NEW) specified by application=0A= IN securityModel -- for the outgoing message=0A= IN securityEngineID -- authoritative SNMP entity=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN scopedPDU -- message (plaintext) payload=0A= IN securityStateReference -- reference to security state=0A= -- information from original=0A= -- request=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- (NEW) transport info=0A= )=0A= =0A= 4.2. Elements of Procedure for Outgoing Messages=0A= =0A= 1) If there is a securityStateReference (Response or Report message),=0A= then this security model uses the cached information rather than the=0A= information provided by the ASI. Extract the tmStateReference from=0A= the securityStateReference cache. Set the tmRequestedSecurityLevel=0A= to the value of the extracted tmTransportSecurityLevel. Set the=0A= tmSameSecurity parameter in the tmStateReference cache to true. The=0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 10]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= cachedSecurityData for this message can now be discarded.=0A= =0A= 2) If there is no securityStateReference then create a=0A= tmStateReference cache. Set tmTransportDomain to the value of=0A= transportDomain, tmTransportAddress to the value of transportAddress,=0A= and tmRequestedSecurityLevel to the value of securityLevel.=0A= (Implementers might optimize by pointing to saved copies of these=0A= session-specific values.) Set the transaction-specific=0A= tmSameSecurity parameter to false.=0A= =0A= If the snmpTsmConfigurationUsePrefix object is set to false, then set=0A= tmSecurityName to the value of securityName.=0A= =0A= If the snmpTsmConfigurationUsePrefix object is set to true, then use=0A= the transportDomain to look up the corresponding prefix. (Since the=0A= securityStateReference stores the tmStateReference with the=0A= tmSecurityName for the incoming message, and tmSecurityName never has=0A= a prefix, the prefix stripping step only occurs when we are not using=0A= the securityStateReference).=0A= =0A= If the prefix lookup fails for any reason, then the=0A= snmpTsmUnknownPrefixes counter is incremented, an error indication=0A= is returned to the calling module, and message processing stops.=0A= =0A= If the lookup succeeds, but there is no prefix in the=0A= securityName, or the prefix returned does not match the prefix in=0A= the securityName, or the length of the prefix is less than 1 or=0A= greater than four ASCII characters, then the=0A= snmpTsmInvalidPrefixes counter is incremented, an error indication=0A= is returned to the calling module, and message processing stops.=0A= =0A= Strip the transport-specific prefix and trailing ':' character=0A= (ASCII 0x3a) from the securityName. Set tmSecurityName to the=0A= value of securityName.=0A= =0A= 3) Set securityParameters to a zero-length OCTET STRING ('0400').=0A= =0A= 4) Combine the message parts into a wholeMsg and calculate=0A= wholeMsgLength.=0A= =0A= 5) The wholeMsg, wholeMsgLength, securityParameters and=0A= tmStateReference are returned to the calling Message Processing Model=0A= with the statusInformation set to success.=0A= =0A= 5. Processing an Incoming SNMP Message=0A= =0A= An error indication may return an OID and value for an incremented=0A= counter and a value for securityLevel, and values for contextEngineID=0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 11]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= and contextName for the counter, and the securityStateReference if=0A= the information is available at the point where the error is=0A= detected.=0A= =0A= 5.1. Security Processing for an Incoming Message=0A= =0A= This section describes the procedure followed by the Transport=0A= Security Model whenever it receives an incoming message from a=0A= Message Processing Model. The ASI from a Message Processing Model to=0A= the Security Subsystem for a received message is:=0A= =0A= statusInformation =3D -- errorIndication or success=0A= -- error counter OID/value if error=0A= processIncomingMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN maxMessageSize -- from the received message=0A= IN securityParameters -- from the received message=0A= IN securityModel -- from the received message=0A= IN securityLevel -- from the received message=0A= IN wholeMsg -- as received on the wire=0A= IN wholeMsgLength -- length as received on the wire=0A= IN tmStateReference -- (NEW) from the Transport Model=0A= OUT securityEngineID -- authoritative SNMP entity=0A= OUT securityName -- identification of the principal=0A= OUT scopedPDU, -- message (plaintext) payload=0A= OUT maxSizeResponseScopedPDU -- maximum size sender can handle=0A= OUT securityStateReference -- reference to security state=0A= ) -- information, needed for response=0A= =0A= 5.2. Elements of Procedure for Incoming Messages=0A= =0A= 1) Set the securityEngineID to the local snmpEngineID.=0A= =0A= 2) If tmStateReference does not refer to a cache containing values=0A= for tmTransportDomain, tmTransportAddress, tmSecurityName and=0A= tmTransportSecurityLevel, then the snmpTsmInvalidCaches counter is=0A= incremented, an error indication is returned to the calling module,=0A= and Security Model processing stops for this message.=0A= =0A= 3) Copy the tmSecurityName to securityName.=0A= =0A= If the snmpTsmConfigurationUsePrefix object is set to true, then use=0A= the tmTransportDomain to look up the corresponding prefix.=0A= =0A= If the prefix lookup fails for any reason, then the=0A= snmpTsmUnknownPrefixes counter is incremented, an error indication=0A= is returned to the calling module, and message processing stops.=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 12]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= If the lookup succeeds, but the prefix length is less than one or=0A= greater than four octets, then the snmpTsmInvalidPrefixes counter=0A= is incremented, an error indication is returned to the calling=0A= module, and message processing stops.=0A= =0A= Set the securityName to be the concatenation of the prefix, a ':'=0A= character (ASCII 0x3a) and the tmSecurityName.=0A= =0A= 4) Compare the value of tmTransportSecurityLevel in the=0A= tmStateReference cache to the value of the securityLevel parameter=0A= passed in the processIncomingMsg ASI. If securityLevel specifies=0A= privacy (Priv), and tmTransportSecurityLevel specifies no privacy=0A= (noPriv), or securityLevel specifies authentication (auth) and=0A= tmTransportSecurityLevel specifies no authentication (noAuth) was=0A= provided by the Transport Model, then the=0A= snmpTsmInadequateSecurityLevels counter is incremented, an error=0A= indication (unsupportedSecurityLevel) together with the OID and value=0A= of the incremented counter is returned to the calling module, and=0A= Transport Security Model processing stops for this message.=0A= =0A= 5) The tmStateReference is cached as cachedSecurityData, so that a=0A= possible response to this message will use the same security=0A= parameters. Then securityStateReference is set for subsequent=0A= reference to this cached data.=0A= =0A= 6) The scopedPDU component is extracted from the wholeMsg.=0A= =0A= 7) The maxSizeResponseScopedPDU is calculated. This is the maximum=0A= size allowed for a scopedPDU for a possible Response message.=0A= =0A= 8) The statusInformation is set to success and a return is made to=0A= the calling module passing back the OUT parameters as specified in=0A= the processIncomingMsg ASI.=0A= =0A= 6. MIB Module Overview=0A= =0A= This MIB module provides objects for use only by the Transport=0A= Security Model. It defines a configuration scalar and related error=0A= counters.=0A= =0A= 6.1. Structure of the MIB Module=0A= =0A= Objects in this MIB module are arranged into subtrees. Each subtree=0A= is organized as a set of related objects. The overall structure and=0A= assignment of objects to their subtrees, and the intended purpose of=0A= each subtree, is shown below.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 13]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= 6.1.1. The snmpTsmStats Subtree=0A= =0A= This subtree contains error counters specific to the Transport=0A= Security Model.=0A= =0A= 6.1.2. The snmpTsmConfiguration Subtree=0A= =0A= This subtree contains a configuration object that enables=0A= administrators to specify if they want a transport domain prefix=0A= prepended to securityNames for use by applications.=0A= =0A= 6.2. Relationship to Other MIB Modules=0A= =0A= Some management objects defined in other MIB modules are applicable=0A= to an entity implementing the Transport Security Model. In=0A= particular, it is assumed that an entity implementing the Transport=0A= Security Model will implement the SNMP-FRAMEWORK-MIB [RFC3411], the=0A= SNMP-TARGET-MIB [RFC3413], the SNMP-VIEW-BASED-ACM-MIB [RFC3415], and=0A= the SNMPv2-MIB [RFC3418]. These are not needed to implement the=0A= SNMP-TSM-MIB.=0A= =0A= 6.2.1. MIB Modules Required for IMPORTS=0A= =0A= The following MIB module imports items from [RFC2578], [RFC2579], and=0A= [RFC2580].=0A= =0A= 7. MIB module definition=0A= =0A= =0A= SNMP-TSM-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE,=0A= mib-2, Counter32=0A= FROM SNMPv2-SMI=0A= MODULE-COMPLIANCE, OBJECT-GROUP=0A= FROM SNMPv2-CONF=0A= TruthValue=0A= FROM SNMPv2-TC=0A= ;=0A= =0A= snmpTsmMIB MODULE-IDENTITY=0A= LAST-UPDATED "200807100000Z"=0A= ORGANIZATION "ISMS Working Group"=0A= CONTACT-INFO "WG-EMail: isms@lists.ietf.org=0A= Subscribe: isms-request@lists.ietf.org=0A= =0A= Chairs:=0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 14]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= Juergen Quittek=0A= NEC Europe Ltd.=0A= Network Laboratories=0A= Kurfuersten-Anlage 36=0A= 69115 Heidelberg=0A= Germany=0A= +49 6221 90511-15=0A= quittek@netlab.nec.de=0A= =0A= Juergen Schoenwaelder=0A= Jacobs University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= +49 421 200-3587=0A= j.schoenwaelder@iu-bremen.de=0A= =0A= Editor:=0A= David Harrington=0A= Huawei Technologies USA=0A= 1700 Alma Dr.=0A= Plano TX 75075=0A= USA=0A= +1 603-436-8634=0A= ietfdbh@comcast.net=0A= =0A= Wes Hardaker=0A= Sparta, Inc.=0A= P.O. Box 382=0A= Davis, CA 95617=0A= USA=0A= +1 530 792 1913=0A= ietf@hardakers.net=0A= "=0A= DESCRIPTION "The Transport Security Model MIB=0A= =0A= In keeping with the RFC 3411 design decisions=0A= to use self-contained documents, the RFC which=0A= contains the definition of this MIB module also=0A= includes the elements of procedure which are=0A= needed for processing the Transport Security=0A= Model for SNMP. These MIB objects=0A= SHOULD NOT be modified via other subsystems=0A= or models defined in other document..=0A= This allows the Transport Security Model=0A= for SNMP to be designed and documented as=0A= independent and self- contained, having no=0A= direct impact on other modules, and this=0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 15]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= allows this module to be upgraded and=0A= supplemented as the need arises, and to=0A= move along the standards track on different=0A= time-lines from other modules.=0A= =0A= Copyright (C) The IETF Trust (2008). This=0A= version of this MIB module is part of RFC XXXX;=0A= see the RFC itself for full legal notices.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= REVISION "200807100000Z"=0A= DESCRIPTION "The initial version, published in RFC XXXX.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= ::=3D { mib-2 xxxx }=0A= -- RFC Ed.: replace xxxx with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- ---------------------------------------------------------- --=0A= -- subtrees in the SNMP-TSM-MIB=0A= -- ---------------------------------------------------------- --=0A= =0A= snmpTsmNotifications OBJECT IDENTIFIER ::=3D { snmpTsmMIB 0 }=0A= snmpTsmMIBObjects OBJECT IDENTIFIER ::=3D { snmpTsmMIB 1 }=0A= snmpTsmConformance OBJECT IDENTIFIER ::=3D { snmpTsmMIB 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Objects=0A= -- -------------------------------------------------------------=0A= =0A= -- Statistics for the Transport Security Model=0A= =0A= =0A= snmpTsmStats OBJECT IDENTIFIER ::=3D { snmpTsmMIBObjects 1 }=0A= =0A= snmpTsmInvalidCaches OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of incoming messages dropped because the=0A= tmStateReference referred to an invalid cache.=0A= "=0A= ::=3D { snmpTsmStats 1 }=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 16]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= snmpTsmInadequateSecurityLevels OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of incoming messages dropped because=0A= the securityLevel asserted by the transport model was=0A= less than the securityLevel requested by the=0A= application.=0A= "=0A= ::=3D { snmpTsmStats 2 }=0A= =0A= snmpTsmUnknownPrefixes OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of messages dropped because=0A= snmpTsmConfigurationUsePrefix was set to true and=0A= there is no known prefix for the specified transport=0A= domain.=0A= "=0A= ::=3D { snmpTsmStats 3 }=0A= =0A= snmpTsmInvalidPrefixes OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of messages dropped because=0A= the securityName associated with an outgoing message=0A= did not contain a valid transport domain prefix.=0A= "=0A= ::=3D { snmpTsmStats 4 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Configuration=0A= -- -------------------------------------------------------------=0A= =0A= -- Configuration for the Transport Security Model=0A= =0A= =0A= snmpTsmConfiguration OBJECT IDENTIFIER ::=3D { snmpTsmMIBObjects 2 }=0A= =0A= snmpTsmConfigurationUsePrefix OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION "If this object is set to true then securityNames=0A= passing to and from the application are expected to=0A= contain a transport domain specific prefix. If this=0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 17]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= object is set to true then a domain specific prefix=0A= will be added by the TSM to the securityName for=0A= incoming messages and removed from the securityName=0A= when processing outgoing messages. Transport domains=0A= and prefixes are maintained in a registry by IANA.=0A= This object SHOULD persist across system reboots.=0A= "=0A= DEFVAL { false }=0A= ::=3D { snmpTsmConfiguration 1 }=0A= =0A= -- -------------------------------------------------------------=0A= -- snmpTsmMIB - Conformance Information=0A= -- -------------------------------------------------------------=0A= =0A= snmpTsmCompliances OBJECT IDENTIFIER ::=3D { snmpTsmConformance 1 }=0A= =0A= snmpTsmGroups OBJECT IDENTIFIER ::=3D { snmpTsmConformance 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Compliance statements=0A= -- -------------------------------------------------------------=0A= =0A= snmpTsmCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION "The compliance statement for SNMP engines that support=0A= the SNMP-TSM-MIB=0A= "=0A= MODULE=0A= MANDATORY-GROUPS { snmpTsmGroup }=0A= ::=3D { snmpTsmCompliances 1 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Units of conformance=0A= -- -------------------------------------------------------------=0A= snmpTsmGroup OBJECT-GROUP=0A= OBJECTS {=0A= snmpTsmInvalidCaches,=0A= snmpTsmInadequateSecurityLevels,=0A= snmpTsmUnknownPrefixes,=0A= snmpTsmInvalidPrefixes,=0A= snmpTsmConfigurationUsePrefix=0A= }=0A= STATUS current=0A= DESCRIPTION "A collection of objects for maintaining=0A= information of an SNMP engine which implements=0A= the SNMP Transport Security Model.=0A= "=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 18]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= ::=3D { snmpTsmGroups 2 }=0A= =0A= =0A= END=0A= =0A= =0A= 8. Security Considerations=0A= =0A= This document describes a Security Model, compatible with the RFC3411=0A= architecture, that permits SNMP to utilize security services provided=0A= through an SNMP Transport Model. The Transport Security Model relies=0A= on Transport Models for mutual authentication, binding of keys,=0A= confidentiality and integrity.=0A= =0A= The Transport Security Model relies on secure Transport Models to=0A= provide an authenticated principal identifier and an assertion of=0A= whether authentication and privacy are used during transport. This=0A= Security Model SHOULD always be used with Transport Models that=0A= provide adequate security, but "adequate security" is a configuration=0A= and/or run-time decision of the operator or management application.=0A= The security threats and how these threats are mitigated should be=0A= covered in detail in the specifications of the Transport Models and=0A= the underlying secure transports.=0A= =0A= An authenticated principal identifier (securityName) is used in SNMP=0A= applications, for purposes such as access control, notification=0A= generation, and proxy forwarding. This security model supports=0A= multiple transport models. Operators might judge some transports to=0A= be more secure than others, so this security model can be configured=0A= to prepend a prefix to the securityName to indicate the transport=0A= model used to authenticate the principal. Operators can use the=0A= prefixed securityName when making application decisions about levels=0A= of access.=0A= =0A= 8.1. MIB module security=0A= =0A= There are a number of management objects defined in this MIB module=0A= with a MAX-ACCESS clause of read-write and/or read-create. Such=0A= objects may be considered sensitive or vulnerable in some network=0A= environments. The support for SET operations in a non-secure=0A= environment without proper protection can have a negative effect on=0A= network operations. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o The snmpTsmConfigurationUsePrefix object could be modified,=0A= creating a denial of service or authorizing SNMP messages that=0A= would not have previously been authorized by an Access Control=0A= Model (e.g. the VACM).=0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 19]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= Some of the readable objects in this MIB module (i.e., objects with a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET and/or NOTIFY access to these objects and possibly=0A= to even encrypt the values of these objects when sending them over=0A= the network via SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o All the counters in this module refer to configuration errors and=0A= do not expose sensitive information.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using IPsec),=0A= even then, there is no control as to who on the secure network is=0A= allowed to access and GET/SET (read/change/create/delete) the objects=0A= in this MIB module.=0A= =0A= It is RECOMMENDED that implementers consider the security features as=0A= provided by the SNMPv3 framework (see [RFC3410] section 8), including=0A= full support for the USM and Transport Security Model cryptographic=0A= mechanisms (for authentication and privacy).=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=0A= enable cryptographic security. It is then a customer/operator=0A= responsibility to ensure that the SNMP entity giving access to an=0A= instance of this MIB module is properly configured to give access to=0A= the objects only to those principals (users) that have legitimate=0A= rights to indeed GET or SET (change/create/delete) them.=0A= =0A= 9. IANA Considerations=0A= =0A= IANA is requested to assign:=0A= =0A= 1. an SMI number under mib-2, for the MIB module in this document,=0A= =0A= 2. a value, preferably 4, to identify the Transport Security Model,=0A= in the Security Models registry at=0A= http://www.iana.org/assignments/snmp-number-spaces. This should=0A= result in the following table of values:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 20]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= Value Description References=0A= ----- ----------- ----------=0A= 0 reserved for 'any' [RFC3411]=0A= 1 reserved for SNMPv1 [RFC3411]=0A= 2 reserved for SNMPv2c [RFC3411]=0A= 3 User-Based Security Model (USM) [RFC3411]=0A= YY Transport Security Model (TSM) [RFCXXXX]=0A= =0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= -- NOTE to RFC editor: replace YY with actual IANA-assigned number,=0A= throughout this document and remove this note.=0A= =0A= 10. Acknowledgements=0A= =0A= The editors would like to thank Jeffrey Hutzelman for sharing his SSH=0A= insights, and Dave Shield for an outstanding job wordsmithing the=0A= existing document to improve organization and clarity.=0A= =0A= Additionally, helpful document reviews were received from: Juergen=0A= Schoenwaelder.=0A= =0A= 11. References=0A= =0A= 11.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to=0A= Indicate Requirement Levels", BCP 14, RFC 2119,=0A= March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Structure of Management=0A= Information Version 2 (SMIv2)", STD 58,=0A= RFC 2578, April 1999.=0A= =0A= [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed., "Textual Conventions for=0A= SMIv2", STD 58, RFC 2579, April 1999.=0A= =0A= [RFC2580] McCloghrie, K., Perkins, D., and J.=0A= Schoenwaelder, "Conformance Statements for=0A= SMIv2", STD 58, RFC 2580, April 1999.=0A= =0A= [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An=0A= Architecture for Describing Simple Network=0A= Management Protocol (SNMP) Management=0A= Frameworks", STD 62, RFC 3411, December 2002.=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 21]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= [RFC3412] Case, J., Harrington, D., Presuhn, R., and B.=0A= Wijnen, "Message Processing and Dispatching for=0A= the Simple Network Management Protocol (SNMP)",=0A= STD 62, RFC 3412, December 2002.=0A= =0A= [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple=0A= Network Management Protocol (SNMP)=0A= Applications", STD 62, RFC 3413, December 2002.=0A= =0A= [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport=0A= Subsystem for the Simple Network Management=0A= Protocol (SNMP)", draft-ietf-isms-tmsm-15 (work=0A= in progress), October 2008.=0A= =0A= 11.2. Informative References=0A= =0A= [RFC3410] Case, J., Mundy, R., Partain, D., and B.=0A= Stewart, "Introduction and Applicability=0A= Statements for Internet-Standard Management=0A= Framework", RFC 3410, December 2002.=0A= =0A= [RFC3414] Blumenthal, U. and B. Wijnen, "User-based=0A= Security Model (USM) for version 3 of the=0A= Simple Network Management Protocol (SNMPv3)",=0A= STD 62, RFC 3414, December 2002.=0A= =0A= [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie,=0A= "View-based Access Control Model (VACM) for the=0A= Simple Network Management Protocol (SNMP)",=0A= STD 62, RFC 3415, December 2002.=0A= =0A= [RFC3418] Presuhn, R., "Management Information Base (MIB)=0A= for the Simple Network Management Protocol=0A= (SNMP)", STD 62, RFC 3418, December 2002.=0A= =0A= [RFC3584] Frye, R., Levi, D., Routhier, S., and B.=0A= Wijnen, "Coexistence between Version 1, Version=0A= 2, and Version 3 of the Internet-standard=0A= Network Management Framework", BCP 74,=0A= RFC 3584, August 2003.=0A= =0A= Appendix A. Notification Tables Configuration=0A= =0A= The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to=0A= configure notification originators with the destinations to which=0A= notifications should be sent.=0A= =0A= Most of the configuration is security-model-independent and=0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 22]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= transport-model-independent.=0A= =0A= The values we will use in the examples for the five model-independent=0A= security and transport parameters are:=0A= =0A= transportDomain =3D snmpSSHDomain=0A= =0A= transportAddress =3D rtr-nyc4@192.0.2.1:PPP=0A= =0A= securityModel =3D Transport Security Model=0A= =0A= securityName =3D alice=0A= =0A= securityLevel =3D authPriv=0A= =0A= The following example will configure the Notification Originator to=0A= send informs to a Notification Receiver at rtr-nyc4@192.0.2.1:PPP=0A= using the securityName "alice". "alice" is the name for the recipient=0A= from the standpoint of the notification originator, and is used for=0A= processing access controls before sending a notification."rtr-nyc4"=0A= is the name for the recipient from the standpoint of the notification=0A= receiver.=0A= =0A= The columns marked with a "*" are the items that are Security Model=0A= or Transport Model specific.=0A= =0A= The configuration for the "alice" settings in the SNMP-VIEW-BASED-=0A= ACM-MIB objects are not shown here for brevity. First we configure=0A= which type of notification should be sent for this taglist (toCRTag).=0A= In this example, we choose to send an Inform.=0A= snmpNotifyTable row:=0A= snmpNotifyName CRNotif=0A= snmpNotifyTag toCRTag=0A= snmpNotifyType inform=0A= snmpNotifyStorageType nonVolatile=0A= snmpNotifyColumnStatus createAndGo=0A= =0A= Then we configure a transport address to which notifications=0A= associated with this taglist should be sent, and we specify which=0A= snmpTargetParamsEntry should be used (toCR) when sending to this=0A= transport address.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 23]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= snmpTargetAddrTable row:=0A= snmpTargetAddrName toCRAddr=0A= * snmpTargetAddrTDomain snmpSSHDomain=0A= * snmpTargetAddrTAddress rtr-nyc4@192.0.2.1:PPP=0A= snmpTargetAddrTimeout 1500=0A= snmpTargetAddrRetryCount 3=0A= snmpTargetAddrTagList toCRTag=0A= snmpTargetAddrParams toCR (must match below)=0A= snmpTargetAddrStorageType nonVolatile=0A= snmpTargetAddrColumnStatus createAndGo=0A= =0A= =0A= Then we configure which principal at the host should receive the=0A= notifications associated with this taglist. Here we choose "alice",=0A= who uses the Transport Security Model.=0A= snmpTargetParamsTable row:=0A= snmpTargetParamsName toCR=0A= snmpTargetParamsMPModel SNMPv3=0A= * snmpTargetParamsSecurityModel TransportSecurityModel=0A= snmpTargetParamsSecurityName "alice"=0A= snmpTargetParamsSecurityLevel authPriv=0A= snmpTargetParamsStorageType nonVolatile=0A= snmpTargetParamsRowStatus createAndGo=0A= =0A= =0A= A.1. Transport Security Model Processing for Notifications=0A= =0A= The Transport Security Model is called using the generateRequestMsg()=0A= ASI, with the following parameters (* are from the above tables):=0A= =0A= statusInformation =3D -- success or errorIndication=0A= generateRequestMsg(=0A= IN messageProcessingModel -- *snmpTargetParamsMPModel=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN transportDomain -- *snmpTargetAddrTDomain=0A= IN transportAddress -- *snmpTargetAddrTAddress=0A= IN securityModel -- *snmpTargetParamsSecurityModel=0A= IN securityEngineID -- immaterial; TSM will ignore.=0A= IN securityName -- snmpTargetParamsSecurityName=0A= IN securityLevel -- *snmpTargetParamsSecurityLevel=0A= IN scopedPDU -- message (plaintext) payload=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- reference to transport info=0A= )=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 24]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= The Transport Security Model will determine the Transport Model based=0A= on the snmpTargetAddrTDomain. The selected Transport Model will=0A= select the appropriate transport connection using the=0A= tmStateReference cache created from the values of=0A= snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and=0A= snmpTargetParamsSecurityLevel.=0A= =0A= Appendix B. Processing Differences between USM and Secure Transport=0A= =0A= USM and secure transports differ in the processing order and=0A= responsibilities within the RFC3411 architecture. While the steps=0A= are the same, they occur in a different order, and may be done by=0A= different subsystems. The following lists illustrate the difference=0A= in the flow and the responsibility for different processing steps for=0A= incoming messages when using USM and when using a secure transport.=0A= (These lists are simplified for illustrative purposes, and do not=0A= represent all details of processing. Transport Models must provide=0A= the detailed elements of procedure.)=0A= =0A= With USM, SNMPv1, and SNMPv2c Security Models, security processing=0A= starts when the Message Processing Model decodes portions of the=0A= ASN.1 message to extract header fields that are used to determine=0A= which Security Model should process the message to perform=0A= authentication, decryption, timeliness checking, integrity checking,=0A= and translation of parameters to model-independent parameters. By=0A= comparison, a secure transport performs those security functions on=0A= the message, before the ASN.1 is decoded.=0A= =0A= Step 6 cannot occur until after decryption occurs. Step 6 and beyond=0A= are the same for USM and a secure transport.=0A= =0A= B.1. USM and the RFC3411 Architecture=0A= =0A= 1) decode the ASN.1 header (Message Processing Model)=0A= =0A= 2) determine the SNMP Security Model and parameters (Message=0A= Processing Model)=0A= =0A= 3) verify securityLevel. [Security Model]=0A= =0A= 4) translate parameters to model-independent parameters (Security=0A= Model)=0A= =0A= 5) authenticate the principal, check message integrity and=0A= timeliness, and decrypt the message. [Security Model]=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 25]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= 6) determine the pduType in the decrypted portions (Message=0A= Processing Model), and=0A= =0A= 7) pass on the decrypted portions with model-independent parameters.=0A= =0A= B.2. Transport Subsystem and the RFC3411 Architecture=0A= =0A= 1) authenticate the principal, check integrity and timeliness of the=0A= message, and decrypt the message. [Transport Model]=0A= =0A= 2) translate parameters to model-independent parameters (Transport=0A= Model)=0A= =0A= 3) decode the ASN.1 header (Message Processing Model)=0A= =0A= 4) determine the SNMP Security Model and parameters (Message=0A= Processing Model)=0A= =0A= 5) verify securityLevel [Security Model]=0A= =0A= 6) determine the pduType in the decrypted portions (Message=0A= Processing Model), and=0A= =0A= 7) pass on the decrypted portions with model-independent security=0A= parameters=0A= =0A= If a message is secured using a secure transport layer, then the=0A= Transport Model should provide the translation from the authenticated=0A= identity (e.g., an SSH user name) to a human-friendly identifier=0A= (tmSecurityName) in step 2. The security model will provide a=0A= mapping from that identifier to a model-independent securityName.=0A= =0A= Appendix C. Open Issues=0A= =0A= =0A= =0A= Appendix D. Change Log=0A= =0A= From -10- to -11-=0A= =0A= Clairifed short vs long term information in tmState=0A= =0A= Removed duplicated text on Caches and References=0A= =0A= removed any references to LCD=0A= =0A= From -09- to -10-=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 26]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= snmpTsmInvalidPrefix -> snmpTsmInvalidPrefixes=0A= =0A= Improvements to the prefix handling text in the EOP=0A= =0A= Removed transform selection=0A= =0A= Removed translation table=0A= =0A= Removed option to disable transports.=0A= =0A= Removed references to the LCD.=0A= =0A= Removed modifications to the "Cached Information" section to keep=0A= this consistent with other ISMS documents.=0A= =0A= Eliminated most "Relationship to Other MIB modules" text.=0A= =0A= Significant text cleanup=0A= =0A= From -08- to -09-=0A= =0A= Added the transport domain specific prefix adding/removing support=0A= as agreed to within the ISMS WG. The implementation is a bit=0A= different than what was originally discussed and is now housed=0A= entirely within this document and requires only a string=0A= allocation in the TM documents. In the end this form greatly=0A= reduced the documentation and procedure complexity in most=0A= documents.=0A= =0A= Added the snmpTsmConfigurationUsePrefix scalar.=0A= =0A= Removed the snmpTsmLCDTable since it is no longer needed.=0A= =0A= Removed the snmpTsmLCDDomainTable since it is not needed with the=0A= prefix addition replaced the functionality.=0A= =0A= From -07- to -08-=0A= =0A= Added tables to the MIB module to define a Transport Security=0A= Model-specific LCD, and updated the Elements of Procedure. This=0A= was because references to an abstract LCD sort of owned by both=0A= the security model and the transport model were found confusing.=0A= =0A= Realized we referred to the MIB module in text as SNMP-TRANSPORT-=0A= SM-MIB, but SNMP-TSM-MIB in the module. Changed all occurrences=0A= of SNMP-TRANSPORT-SM-MIB to SNMP-TSM-MIB, following RFC4181=0A= guidelines for naming.=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 27]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= Updated Security Considerations to warn about writable objects,=0A= and added the new counter to the readable objects list.=0A= =0A= Changed snmpTsmLCDName to snmpTsmLCDTmSecurityName=0A= =0A= From -05- to -06-=0A= =0A= Fixed a bunch of editorial nits=0A= =0A= Fixed the note about terminology consistent with SNMPv3.=0A= =0A= Updated MIB assignment to by rfc4181 compatible=0A= =0A= Replaced tmSameSession with tmSameSecurity to eliminate session-=0A= matching from the security model.=0A= =0A= Eliminated all reference to the LCD from the Transport Security=0A= Model; the LCD is now TM-specific.=0A= =0A= Added tmTransportSecurityLevel and tmRequestedSecurityLevel to=0A= clarify incoming versus outgoing=0A= =0A= From -04- to -05-=0A= =0A= Removed check for empty securityParameters for incoming messages=0A= =0A= Added a note about terminology, for consistency with SNMPv3 rather=0A= than with RFC2828.=0A= =0A= From -03- to -04-=0A= =0A= Editorial changes requested by Tom Petch, to clarify behavior with=0A= SNMPv1/v2c=0A= =0A= Added early discussion of how TSM fits into the architecture to=0A= clarify behavior when RFC3584 security models are co-resident.=0A= =0A= Editorial changes requested by Bert Wijnen, to eliminate version-=0A= specific discussions.=0A= =0A= Removed sections on version-specific message formats.=0A= =0A= Removed discussion of SNMPv3 in Motivation section.=0A= =0A= Added discussion of request/response session matching.=0A= =0A= From -02- to -03-=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 28]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= Editorial changes suggested by Juergen Schoenwaelder=0A= =0A= Capitalized Transport Models, Security Models, and Message=0A= Processing Models, to be consistent with RFC341x conventions.=0A= =0A= Eliminated some text that duplicated RFC3412, especially in=0A= Elements of Procedure.=0A= =0A= Changed the encoding of msgSecurityParameters=0A= =0A= Marked the (NEW) fields added to existing ASIs=0A= =0A= Modified text intro discussing relationships to other MIB modules.=0A= =0A= From -01- to -02-=0A= =0A= Changed transportSecurityModel(4) to transportSecurityModel(YY),=0A= waiting for assignment=0A= =0A= cleaned up elements of procedure [todo]s=0A= =0A= use the same errorIndication as USM for unsupportedSecurityLevel=0A= =0A= fixed syntax of tsmInadequateSecurity counter=0A= =0A= changed the "can and will use" the same security parameters to=0A= "can use", to allow responses that have different security=0A= parameters than the request.=0A= =0A= removed "Relationship to the SNMP-FRAMEWORK-MIB"=0A= =0A= cleaned up "MIB Modules Required for IMPORTS"=0A= =0A= =0A= =0A= From -00- to -01-=0A= =0A= made the Transport Model not know anything about the Security=0A= Model.=0A= =0A= modified the elements of procedure sections, given the=0A= implications of this change.=0A= =0A= simplified elements of procedure, removing most info specified in=0A= architecture/subsystem definitions.=0A= =0A= rethought the coexistence section=0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 29]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= noted the implications of the Transport Security Model on=0A= isAccessAllowed()=0A= =0A= modified all text related to the LCD.=0A= =0A= removed most of the MIB (now the TSM has no configuration=0A= parameters).=0A= =0A= added counters needed to support elements of procedure=0A= =0A= renamed MIB module, and registered under snmpModules=0A= =0A= updated IANA and Security Considerations=0A= =0A= updated references.=0A= =0A= modified the notification configurations.=0A= =0A= From SSHSM-04- to Transport-security-model-00=0A= =0A= added tsmUserTable=0A= =0A= updated Appendix - Notification Tables Configuration=0A= =0A= remove open/closed issue appendices=0A= =0A= changed tmSessionReference to tmStateReference=0A= =0A= =0A= =0A= Authors' Addresses=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 30]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= Wes Hardaker=0A= Sparta, Inc.=0A= P.O. Box 382=0A= Davis, CA 95617=0A= US=0A= =0A= Phone: +1 530 792 1913=0A= EMail: ietf@hardakers.net=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 31]=0A= =0C=0A= Internet-Draft Transport Security Model for SNMP February 2009=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2009).=0A= =0A= This document is subject to the rights, licenses and restrictions=0A= contained in BCP 78, and except as set forth therein, the authors=0A= retain all their rights.=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Hardaker Expires August 13, 2009 [Page 32]=0A= =0C=0A= =0A= ------=_NextPart_000_0942_01C98B0A.022087F0-- From ietfdbh@comcast.net Mon Feb 9 20:09:05 2009 Return-Path: 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 C77853A6B3F for ; Mon, 9 Feb 2009 20:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-1.669, BAYES_00=-2.599, MANGLED_TOOL=2.3, MIME_QP_LONG_LINE=1.396] 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 zSElgxsGjfBc for ; Mon, 9 Feb 2009 20:09:00 -0800 (PST) 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 0EAB33A6A74 for ; Mon, 9 Feb 2009 20:08:59 -0800 (PST) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA09.westchester.pa.mail.comcast.net with comcast id DqqJ1b0081GhbT859493zL; Tue, 10 Feb 2009 04:09:03 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id E48S1b00L0UQ6dC3T48SPM; Tue, 10 Feb 2009 04:09:03 +0000 From: "David Harrington" To: Date: Mon, 9 Feb 2009 23:08:25 -0500 Message-ID: <095101c98b35$38d17b30$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0952_01C98B0B.4FFB7330" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmLNThvjouGcASbQJGRqmd4gcLYGQ== Subject: [Isms] draft-ietf-isms-secshell-pre14a.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: , X-List-Received-Date: Tue, 10 Feb 2009 04:09:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0952_01C98B0B.4FFB7330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0952_01C98B0B.4FFB7330 Content-Type: text/plain; name="draft-ietf-isms-secshell-pre14a.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-secshell-pre14a.txt" =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Intended status: Standards Track J. Salowey=0A= Expires: August 13, 2009 Cisco Systems=0A= W. Hardaker=0A= Sparta, Inc.=0A= February 9, 2009=0A= =0A= =0A= Secure Shell Transport Model for SNMP=0A= draft-ietf-isms-secshell-14=0A= =0A= Status of This Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on August 13, 2009.=0A= =0A= Abstract=0A= =0A= This memo describes a Transport Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol (SSH).=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Secure Shell Transport Model for SNMP.=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 1]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 3=0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 2. The Secure Shell Protocol . . . . . . . . . . . . . . . . . . 6=0A= 3. How SSHTM Fits into the Transport Subsystem . . . . . . . . . 7=0A= 3.1. Security Capabilities of this Model . . . . . . . . . . . 8=0A= 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 3.1.2. Message Authentication . . . . . . . . . . . . . . . . 9=0A= 3.1.3. Authentication Protocol Support . . . . . . . . . . . 10=0A= 3.1.4. SSH Subsystem . . . . . . . . . . . . . . . . . . . . 10=0A= 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 11=0A= 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 11=0A= 4. Cached Information and References . . . . . . . . . . . . . . 12=0A= 4.1. Secure Shell Transport Model Cached Information . . . . . 12=0A= 4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . . . 12=0A= 4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . . . 13=0A= 4.1.3. Session State . . . . . . . . . . . . . . . . . . . . 13=0A= 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 13=0A= 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 14=0A= 5.2. Procedures for sending an Outgoing Message . . . . . . . . 15=0A= 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 16=0A= 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 18=0A= 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 18=0A= 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 18=0A= 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 18=0A= 6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 18=0A= 6.3.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 19=0A= 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 19=0A= 8. Operational Considerations . . . . . . . . . . . . . . . . . . 25=0A= 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26=0A= 9.1. Skipping Public Key Verification . . . . . . . . . . . . . 27=0A= 9.2. The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 27=0A= 9.3. Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 28=0A= 9.4. MIB Module Security . . . . . . . . . . . . . . . . . . . 28=0A= 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29=0A= 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29=0A= 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29=0A= 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29=0A= 12.2. Informative References . . . . . . . . . . . . . . . . . . 32=0A= Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 33=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 2]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= 1. Introduction=0A= =0A= This memo describes a Transport Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol (SSH) [RFC4251]=0A= within a transport subsystem [I-D.ietf-isms-tmsm]. The transport=0A= model specified in this memo is referred to as the Secure Shell=0A= Transport Model (SSHTM).=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Secure Shell Transport Model for SNMP.=0A= =0A= It is important to understand the SNMP architecture [RFC3411] and the=0A= terminology of the architecture to understand where the Transport=0A= Model described in this memo fits into the architecture and interacts=0A= with other subsystems within the architecture.=0A= =0A= 1.1. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= Managed objects are accessed via a virtual information store, termed=0A= the Management Information Base or MIB. MIB objects are generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in the=0A= Structure of Management Information (SMI). This memo specifies a MIB=0A= module that is compliant to the SMIv2, which is described in STD 58,=0A= RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580=0A= [RFC2580].=0A= =0A= 1.2. Conventions=0A= =0A= For consistency with SNMP-related specifications, this document=0A= favors terminology as defined in STD62 rather than favoring=0A= terminology that is consistent with non-SNMP specifications. This is=0A= consistent with the IESG decision to not require the SNMPv3=0A= terminology be modified to match the usage of other non-SNMP=0A= specifications when SNMPv3 was advanced to Full Standard.=0A= =0A= Authentication in this document typically refers to the English=0A= meaning of "serving to prove the authenticity of" the message, not=0A= data source authentication or peer identity authentication.=0A= =0A= The terms "manager" and "agent" are not used in this document,=0A= because in the RFC 3411 architecture [RFC3411], all SNMP entities=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 3]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= have the capability of acting in either manager or agent or in both=0A= roles depending on the SNMP application types supported in the=0A= implementation. Where distinction is required, the application names=0A= of Command Generator, Command Responder, Notification Originator,=0A= Notification Receiver, and Proxy Forwarder are used. See "SNMP=0A= Applications" [RFC3413] for further information.=0A= =0A= Throughout this document, the terms "client" and "server" are used to=0A= refer to the two ends of the SSH transport connection. The client=0A= actively opens the SSH connection, and the server passively listens=0A= for the incoming SSH connection. Either SNMP entity may act as=0A= client or as server, as discussed further below.=0A= =0A= The User-Based Security Model (USM) [RFC3414] is a mandatory-to-=0A= implement Security Model in STD 62. While SSH and USM frequently=0A= refer to a user, the terminology preferred in RFC3411 [RFC3411] and=0A= in this memo is "principal". A principal is the "who" on whose=0A= behalf services are provided or processing takes place. A principal=0A= can be, among other things, an individual acting in a particular=0A= role; a set of individuals, with each acting in a particular role; an=0A= application or a set of applications, or a combination of these=0A= within an administrative domain.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= Sections requiring further editing are identified by [todo] markers=0A= in the text. Points requiring further WG research and discussion are=0A= identified by [discuss] markers in the text.=0A= =0A= Note to RFC Editor - if the previous paragraph and this note have not=0A= been removed, please send the document back to the editor to remove=0A= this.=0A= =0A= 1.3. Modularity=0A= =0A= The reader is expected to have read and understood the description of=0A= the SNMP architecture, as defined in [RFC3411], and the Transport=0A= Subsystem architecture extension specified in "Transport Subsystem=0A= for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm].=0A= =0A= This memo describes the Secure Shell Transport Model for SNMP, a=0A= specific SNMP transport model to be used within the SNMP transport=0A= subsystem to provide authentication, encryption, and integrity=0A= checking of SNMP messages.=0A= =0A= In keeping with the RFC 3411 design decision to use self-contained=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 4]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= documents, this document defines the elements of procedure and=0A= associated MIB module objects which are needed for processing the=0A= Secure Shell Transport Model for SNMP.=0A= =0A= This modularity of specification is not meant to be interpreted as=0A= imposing any specific requirements on implementation.=0A= =0A= 1.4. Motivation=0A= =0A= Version 3 of the Simple Network Management Protocol (SNMPv3) added=0A= security to the protocol. The User-based Security Model (USM)=0A= [RFC3414] was designed to be independent of other existing security=0A= infrastructures, to ensure it could function when third party=0A= authentication services were not available, such as in a broken=0A= network. As a result, USM utilizes a separate user and key=0A= management infrastructure. Operators have reported that deploying=0A= another user and key management infrastructure in order to use SNMPv3=0A= is a reason for not deploying SNMPv3.=0A= =0A= This memo describes a transport model that will make use of the=0A= existing and commonly deployed Secure Shell security infrastructure.=0A= This transport model is designed to meet the security and operational=0A= needs of network administrators, maximize usability in operational=0A= environments to achieve high deployment success and at the same time=0A= minimize implementation and deployment costs to minimize deployment=0A= time.=0A= =0A= This document addresses the requirement for the SSH client to=0A= authenticate the SSH server, for the SSH server to authenticate the=0A= SSH client, and describes how SNMP can make use of the authenticated=0A= identities in authorization policies for data access, in a manner=0A= that is independent of any specific access control model.=0A= =0A= This document addresses the requirement to utilize client=0A= authentication and key exchange methods which support different=0A= security infrastructures and provide different security properties.=0A= This document describes how to use client authentication as described=0A= in "SSH Authentication Protocol" [RFC4252]. The SSH Transport Model=0A= should work with any of the ssh-userauth methods including the=0A= "publickey", "password", "hostbased", "none", "keyboard-interactive",=0A= "gssapi-with-mic", ."gssapi-keyex", "gssapi", and "external-keyx"=0A= (see http://www.iana.org/assignments/ssh-parameters). The use of the=0A= "none" authentication method is NOT RECOMMENDED, as described in=0A= Security Considerations. Local accounts may be supported through the=0A= use of the publickey, hostbased or password methods. The password=0A= method allows for integration with deployed password infrastructure=0A= such as AAA servers using the RADIUS protocol [RFC2865]. The SSH=0A= Transport Model SHOULD be able to take advantage of future defined=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 5]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= ssh-userauth methods, such as those that might make use of X.509=0A= certificate credentials.=0A= =0A= It is desirable to use mechanisms that could unify the approach for=0A= administrative security for SNMPv3 and Command Line interfaces (CLI)=0A= and other management interfaces. The use of security services=0A= provided by Secure Shell is the approach commonly used for the CLI,=0A= and is the approach being adopted for use with NETCONF [RFC4742].=0A= This memo describes a method for invoking and running the SNMP=0A= protocol within a Secure Shell (SSH) session as an SSH subsystem.=0A= =0A= This memo describes how SNMP can be used within a Secure Shell (SSH)=0A= session, using the SSH connection protocol [RFC4254] over the SSH=0A= transport protocol, using SSH user-auth [RFC4252] for authentication.=0A= =0A= There are a number of challenges to be addressed to map Secure Shell=0A= authentication method parameters into the SNMP architecture so that=0A= SNMP continues to work without any surprises. These are discussed in=0A= detail below.=0A= =0A= 1.5. Constraints=0A= =0A= The design of this SNMP Transport Model is influenced by the=0A= following constraints:=0A= =0A= 1. In times of network stress, the transport protocol and its=0A= underlying security mechanisms SHOULD NOT depend upon the ready=0A= availability of other network services (e.g., Network Time=0A= Protocol (NTP) or AAA protocols).=0A= =0A= 2. When the network is not under stress, the transport model and its=0A= underlying security mechanisms MAY depend upon the ready=0A= availability of other network services.=0A= =0A= 3. It may not be possible for the transport model to determine when=0A= the network is under stress.=0A= =0A= 4. A transport model should require no changes to the SNMP=0A= architecture.=0A= =0A= 5. A transport model should require no changes to the underlying=0A= protocol.=0A= =0A= 2. The Secure Shell Protocol=0A= =0A= SSH is a protocol for secure remote login and other secure network=0A= services over an insecure network. It consists of three major=0A= protocol components, and add-on methods for user authentication:=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 6]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= o The Transport Layer Protocol [RFC4253] provides server=0A= authentication, and message confidentiality and integrity. It may=0A= optionally also provide compression. The transport layer will=0A= typically be run over a TCP/IP connection, but might also be used=0A= on top of any other reliable data stream.=0A= =0A= o The User Authentication Protocol [RFC4252] authenticates the=0A= client-side principal to the server. It runs over the transport=0A= layer protocol.=0A= =0A= o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel=0A= into several logical channels. It runs over the transport after=0A= successfully authenticating the principal.=0A= =0A= o Generic Message Exchange Authentication [RFC4256] is a general=0A= purpose authentication method for the SSH protocol, suitable for=0A= interactive authentications where the authentication data should=0A= be entered via a keyboard=0A= =0A= o Generic Security Service Application Program Interface (GSS-API)=0A= Authentication and Key Exchange for the Secure Shell (SSH)=0A= Protocol [RFC4462] describes methods for using the GSS-API for=0A= authentication and key exchange in SSH. It defines an SSH user=0A= authentication method that uses a specified GSS-API mechanism to=0A= authenticate a user, and a family of SSH key exchange methods that=0A= use GSS-API to authenticate a Diffie-Hellman key exchange.=0A= =0A= The client sends a service request once a secure transport layer=0A= connection has been established. A second service request is sent=0A= after client authentication is complete. This allows new protocols=0A= to be defined and coexist with the protocols listed above.=0A= =0A= The connection protocol provides channels that can be used for a wide=0A= range of purposes. Standard methods are provided for setting up=0A= secure interactive shell sessions and for forwarding ("tunneling")=0A= arbitrary TCP/IP ports and X11 connections.=0A= =0A= 3. How SSHTM Fits into the Transport Subsystem=0A= =0A= A transport model is a component of the Transport Subsystem=0A= [I-D.ietf-isms-tmsm] within the SNMP architecture. The SSH Transport=0A= Model thus fits between the underlying SSH transport layer and the=0A= message dispatcher [RFC3411].=0A= =0A= The SSH Transport Model will establish a channel between itself and=0A= the SSH Transport Model of another SNMP engine. The sending=0A= transport model passes unencrypted messages from the dispatcher to=0A= SSH to be encrypted, and the receiving transport model accepts=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 7]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= decrypted incoming messages from SSH and passes them to the=0A= dispatcher.=0A= =0A= After an SSH Transport model channel is established, then SNMP=0A= messages can conceptually be sent through the channel from one SNMP=0A= message dispatcher to another SNMP message dispatcher. Multiple SNMP=0A= messages MAY be passed through the same channel.=0A= =0A= The SSH Transport Model of an SNMP engine will perform the=0A= translation between SSH-specific security parameters and SNMP-=0A= specific, model-independent parameters.=0A= =0A= 3.1. Security Capabilities of this Model=0A= =0A= 3.1.1. Threats=0A= =0A= The Secure Shell Transport Model provides protection against the=0A= threats identified by the RFC 3411 architecture [RFC3411]:=0A= =0A= 1. Modification of Information - SSH provides for verification that=0A= the contents of each message has not been modified during its=0A= transmission through the network, by digitally signing each SSH=0A= packet.=0A= =0A= 2. Masquerade - SSH provides for verification of the identity of the=0A= SSH server and the identity of the SSH client.=0A= =0A= SSH provides for verification of the identity of the SSH server=0A= through the SSH Transport Protocol server authentication=0A= [RFC4253]. This allows an operator or management station to=0A= ensure the authenticity of the SNMP engine that provides MIB=0A= data.=0A= =0A= SSH provides a number of mechanisms for verification of the=0A= identity of the SSH client-side principal, using the Secure Shell=0A= Authentication Protocol [RFC4252]. These include public key,=0A= password and host-based mechanisms. This allows the SNMP access=0A= control subsystem to ensure that only authorized principals have=0A= access to potentially sensitive data.=0A= =0A= Verification of client's principal identity is important for use=0A= with the SNMP access control subsystem, to ensure that only=0A= authorized principals have access to potentially sensitive data.=0A= The SSH user identity is provided to the transport model, so it=0A= can be used to map to an SNMP model-independent securityName for=0A= use with SNMP access control and notification configuration.=0A= (The identity may undergo various transforms before it maps to=0A= the securityName.)=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 8]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= 3. Message Stream Modification - SSH protects against malicious re-=0A= ordering or replaying of messages within a single SSH session by=0A= using sequence numbers and integrity checks. SSH protects=0A= against replay of messages across SSH sessions by ensuring that=0A= the cryptographic keys used for encryption and integrity checks=0A= are generated afresh for each session.=0A= =0A= 4. Disclosure - SSH provides protection against the disclosure of=0A= information to unauthorized recipients or eavesdroppers by=0A= allowing for encryption of all traffic between SNMP engines.=0A= =0A= 3.1.2. Message Authentication=0A= =0A= The RFC 3411 architecture recognizes three levels of security:=0A= =0A= - without authentication and without privacy (noAuthNoPriv)=0A= =0A= - with authentication but without privacy (authNoPriv)=0A= =0A= - with authentication and with privacy (authPriv)=0A= =0A= The Secure Shell protocol provides support for encryption and data=0A= integrity. While it is technically possible to support no=0A= authentication and no encryption in SSH it is NOT RECOMMENDED by=0A= [RFC4253].=0A= =0A= The SSH Transport Model determines from SSH the identity of the=0A= authenticated principal, and the type and address associated with an=0A= incoming message, and provides this information to SSH for an=0A= outgoing message. The transport layer algorithms used to provide=0A= authentication, data integrity and encryption SHOULD NOT be exposed=0A= to the SSH Transport Model layer. The SNMPv3 WG deliberately avoided=0A= this and settled for an assertion by the security model that the=0A= requirements of securityLevel were met The SSH Transport Model has no=0A= mechanisms by which it can test whether an underlying SSH connection=0A= provides auth or priv, so the SSH Transport Model trusts that the=0A= underlying SSH connection has been properly configured to support=0A= authPriv security characteristics.=0A= =0A= An SSH Transport Model-compliant implementation MUST use an SSH=0A= connection that provides authentication, data integrity and=0A= encryption that meets the highest level of SNMP security (authPriv).=0A= Outgoing messages specified with a securityLevel of noAuthNoPriv or=0A= authNoPriv, are actually sent by the SSH Transport Model with=0A= authPriv-level protection.=0A= =0A= The security protocols used in the Secure Shell Authentication=0A= Protocol [RFC4252] and the Secure Shell Transport Layer Protocol=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 9]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= [RFC4253] are considered acceptably secure at the time of writing.=0A= However, the procedures allow for new authentication and privacy=0A= methods to be specified at a future time if the need arises.=0A= =0A= 3.1.3. Authentication Protocol Support=0A= =0A= The SSH Transport Model should support any server or client=0A= authentication mechanism supported by SSH. This includes the three=0A= authentication methods described in the SSH Authentication Protocol=0A= document [RFC4252] - publickey, password, and host-based - and=0A= keyboard interactive and others.=0A= =0A= The password authentication mechanism allows for integration with=0A= deployed password based infrastructure. It is possible to hand a=0A= password to a service such as RADIUS [RFC2865] or Diameter [RFC3588]=0A= for validation. The validation could be done using the user-name and=0A= user-password attributes. It is also possible to use a different=0A= password validation protocol such as CHAP [RFC1994] or digest=0A= authentication [RFC5090] to integrate with RADIUS or Diameter. At=0A= some point in the processing, these mechanisms require the password=0A= be made available as clear text on the device that is authenticating=0A= the password which might introduce threats to the authentication=0A= infrastructure.=0A= =0A= GSSKeyex [RFC4462] provides a framework for the addition of client=0A= authentication mechanisms which support different security=0A= infrastructures and provide different security properties.=0A= Additional authentication mechanisms, such as one that supports X.509=0A= certificates, may be added to SSH in the future.=0A= =0A= 3.1.4. SSH Subsystem=0A= =0A= This document describes the use of an SSH subsystem for SNMP to make=0A= SNMP usage distinct from other usages.=0A= =0A= An SSH subsystem of type "snmp" is opened by the SSH Transport Model=0A= during the elements of procedure for an outgoing SNMP message. Since=0A= the sender of a message initiates the creation of an SSH session if=0A= needed, the SSH session will already exist for an incoming message or=0A= the incoming message would never reach the SSH Transport Model.=0A= =0A= Implementations MAY choose to instantiate SSH sessions in=0A= anticipation of outgoing messages. This approach might be useful to=0A= ensure that an SSH session to a given target can be established=0A= before it becomes important to send a message over the SSH session.=0A= Of course, there is no guarantee that a pre-established session will=0A= still be valid when needed.=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 10]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= SSH sessions are uniquely identified within the SSH Transport Model=0A= by the combination of tmTransportAddress and tmSecurityName=0A= associated with each session.=0A= =0A= 3.2. Security Parameter Passing=0A= =0A= For incoming messages, SSH-specific security parameters are=0A= translated by the transport model into security parameters=0A= independent of the transport and security models. The transport=0A= model accepts messages from the SSH subsystem, and records the=0A= transport-related and SSH-security-related information, including the=0A= authenticated identity, in a cache referenced by tmStateReference,=0A= and passes the WholeMsg and the tmStateReference to the dispatcher=0A= using the receiveMessage() ASI (Application Service Interface).=0A= =0A= For outgoing messages, the transport model takes input provided by=0A= the dispatcher in the sendMessage() ASI. The SSH Transport Model=0A= converts that information into suitable security parameters for SSH,=0A= establishes sessions as needed, and passes messages to the SSH=0A= subsystem for sending.=0A= =0A= 3.3. Notifications and Proxy=0A= =0A= SSH connections may be initiated by command generators or by=0A= notification originators. Command generators are frequently operated=0A= by a human, but notification originators are usually unmanned=0A= automated processes. As a result, it may be necessary to provision=0A= authentication credentials on the SNMP engine containing the=0A= notification originator, or use a third party key provider such as=0A= Kerberos, so the engine can successfully authenticate to an engine=0A= containing a notification receiver.=0A= =0A= The targets to whom notifications or proxy requests should be sent is=0A= typically determined and configured by a network administrator. The=0A= SNMP-TARGET-MIB module [RFC3413] contains objects for defining=0A= management targets, including transport domains and addresses and=0A= security parameters, for applications such as notification generators=0A= and proxy forwarders.=0A= =0A= For the SSH Transport Model, transport type and address are=0A= configured in the snmpTargetAddrTable, and the securityName, and=0A= securityLevel parameters are configured in the snmpTargetParamsTable.=0A= The default approach is for an administrator to statically=0A= preconfigure this information to identify the targets authorized to=0A= receive notifications or perform proxy.=0A= =0A= These MIB modules may be configured using SNMP or other=0A= implementation-dependent mechanisms, such as CLI scripting or loading=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 11]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= a configuration file. It may be necessary to provide additional=0A= implementation-specific configuration of SSH parameters.=0A= =0A= 4. Cached Information and References=0A= =0A= When performing SNMP processing, there are two levels of state=0A= information that may need to be retained: the immediate state linking=0A= a request-response pair, and potentially longer-term state relating=0A= to transport and security. "Transport Subsystem for the Simple=0A= Network Management Protocol" [I-D.ietf-isms-tmsm] defines general=0A= requirements for caches and references.=0A= =0A= This document defines additional cache requirements related to the=0A= Secure Shell Transport Model.=0A= =0A= 4.1. Secure Shell Transport Model Cached Information=0A= =0A= The Secure Shell Transport Model has specific responsibilities=0A= regarding the cached information. See the Elements of Procedure in=0A= Section 5 for detailed processing instructions on the use of the=0A= tmStateReference fields by the SSH Transport Model.=0A= =0A= 4.1.1. tmSecurityName=0A= =0A= The tmSecurityName MUST be a human-readable name (in snmpAdminString=0A= format) representing the identity that has been set according to the=0A= procedures in Section 5.=0A= =0A= On the SSH server side of a connection:=0A= =0A= The tmSecurityName SHOULD be the value of the user name field of=0A= the SSH_MSG_USERAUTH_REQUEST message for which a=0A= SSH_MSG_USERAUTH_SUCCESS has been sent. How the SSH user name is=0A= extracted from the SSH layer is implementation-dependent.=0A= =0A= The SSH protocol is not always clear on whether the user name=0A= field must be filled in, so for some implementations, such as=0A= those using GSSAPI authentication, it may be necessary to use a=0A= mapping algorithm to transform an SSH identity to a=0A= tmSecurityName, or to transform a tmSecurityName to an SSH=0A= identity.=0A= =0A= In other cases the user name may not be verified by the server, so=0A= for these implementations, it may be necessary to obtain the user=0A= name from other credentials exchanged during the SSH exchange.=0A= =0A= On the SSH client side of a connection:=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 12]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= The tmSecurityName is presented to the SSH Transport Model by the=0A= application (possibly because of configuration specified in the=0A= SNMP-TARGET-MIB).=0A= =0A= The securityName MAY be derived from the tmSecurityName by a security=0A= model, and MAY be used to configure notifications and access=0A= controls. Transport models SHOULD generate a predictable=0A= tmSecurityName.=0A= =0A= 4.1.2. tmSessionID=0A= =0A= The tmSessionID MUST be recorded per message at the time of receipt.=0A= When tmSameSecurity is set, the recorded tmSessionID can be used to=0A= determine whether the SSH session available for sending a=0A= corresponding outgoing message is the same SSH session as was used=0A= when receiving the incoming message (e.g., a response to a request).=0A= =0A= 4.1.3. Session State=0A= =0A= The per-session state that is referenced by tmStateReference may be=0A= saved across multiple messages in a Local Configuration Datastore.=0A= Additional session/connection state information might also be stored=0A= in a Local Configuration Datastore.=0A= =0A= 5. Elements of Procedure=0A= =0A= Abstract service interfaces have been defined by [RFC3411] and=0A= further augmented by [I-D.ietf-isms-tmsm] to describe the conceptual=0A= data flows between the various subsystems within an SNMP entity. The=0A= Secure Shell Transport Model uses some of these conceptual data flows=0A= when communicating between subsystems.=0A= =0A= To simplify the elements of procedure, the release of state=0A= information is not always explicitly specified. As a general rule,=0A= if state information is available when a message gets discarded, the=0A= message-state information should also be released, and if state=0A= information is available when a session is closed, the session state=0A= information should also be released.=0A= =0A= An error indication in statusInformation will typically include the=0A= OID and value for an incremented error counter. This may be=0A= accompanied by the requested securityLevel, and the tmStateReference.=0A= Per-message context information is not accessible to Transport=0A= Models, so for the returned counter OID and value, contextEngine=0A= would be set to the local value of snmpEngineID, and contextName to=0A= the default context for error counters.=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 13]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= 5.1. Procedures for an Incoming Message=0A= =0A= 1. The SSH Transport Model queries the SSH engine, in an=0A= implementation-dependent manner, to determine the=0A= transportAddress, the principal name authenticated by SSH, and a=0A= session identifier.=0A= =0A= By default on the server side of a SSH connection, the principal=0A= name is the value of the user name field of the=0A= SSH_MSG_USERAUTH_REQUEST message for which a=0A= SSH_MSG_USERAUTH_SUCCESS has been sent. How this name is=0A= extracted from the SSH environment is implementation-dependent.=0A= =0A= 2. Create a tmStateReference cache for subsequent reference to the=0A= information.=0A= =0A= tmTransportDomain =3D snmpSSHDomain=0A= =0A= tmTransportAddress =3D the address the message originated from,=0A= determined in an implementation-dependent way=0A= =0A= tmTransportSecurityLevel =3D "authPriv" (authentication and=0A= confidentiality MUST be used to comply with this transport=0A= model.)=0A= =0A= tmSecurityName =3D the ssh principal name received by the SSH=0A= server or sent from a SSH client.=0A= =0A= tmSessionID =3D an implementation-dependent value that can be=0A= used to detect when a session has closed and been replaced by=0A= another session. The value in tmStateReference should=0A= identify the session over which the message was received.=0A= =0A= Prepare the transport parameters for the ASI:=0A= =0A= transportDomain =3D snmpSSHDomain=0A= =0A= transportAddress =3D the address the message originated from,=0A= determined in an implementation-dependent way=0A= =0A= Then the Transport model passes the message to the Dispatcher using=0A= the following ASI:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 14]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= statusInformation =3D=0A= receiveMessage(=0A= IN transportDomain -- snmpSSHDomain=0A= IN transportAddress -- address for the received message=0A= IN wholeMessage -- the whole SNMP message from SSH=0A= IN wholeMessageLength -- the length of the SNMP message=0A= IN tmStateReference -- (NEW) transport info=0A= )=0A= =0A= 5.2. Procedures for sending an Outgoing Message=0A= =0A= The Dispatcher passes the information to the Transport Model using=0A= the ASI defined in the transport subsystem:=0A= =0A= =0A= statusInformation =3D=0A= sendMessage(=0A= IN destTransportDomain -- transport domain to be used=0A= IN destTransportAddress -- transport address to be used=0A= IN outgoingMessage -- the message to send=0A= IN outgoingMessageLength -- its length=0A= IN tmStateReference -- (NEW) transport info=0A= )=0A= =0A= The SSH Transport Model performs the following tasks.=0A= =0A= 1. If tmStateReference does not refer to a cache containing values=0A= for tmTransportDomain, tmTransportAddress, tmSecurityName,=0A= tmRequestedSecurityLevel, and tmSameSecurity, then increment the=0A= sshtmSessionInvalidCaches counter, discard the message and return=0A= the error indication in the statusInformation. Processing of=0A= this message stops.=0A= =0A= 2. Extract the tmTransportDomain, tmTransportAddress,=0A= tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, and=0A= tmSessionID from the tmStateReference.=0A= =0A= 3. If tmSameSecurity is true and there is no existing session with=0A= the same sessionID as tmSessionID, then increment the=0A= sshtmSessionNoAvailableSessions counter, discard the message and=0A= return the error indication in the statusInformation. Processing=0A= of this message stops.=0A= =0A= 4. If there is no existing session corresponding to the=0A= tmTransportAddress and tmSecurityName, then call openSession()=0A= with the tmStateReference as a parameter. If openSession fails,=0A= then discard the message, release tmStateReference and pass the=0A= error indication returned by openSession back to the calling=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 15]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= module. Processing stops for this message.=0A= =0A= 5. Pass the wholeMessage to SSH for encapsulation as data in an SSH=0A= message over the specified SSH session. Any necessary additional=0A= SSH-specific parameters should be provided in an implementation-=0A= dependent manner.=0A= =0A= 5.3. Establishing a Session=0A= =0A= The Secure Shell Transport Model provides the following abstract=0A= service interface (ASI) to describe the data passed between the SSH=0A= Transport Model and the SSH service. It is an implementation=0A= decision how such data is passed.=0A= =0A= statusInformation =3D=0A= openSession(=0A= IN tmStateReference -- transport information to be used=0A= OUT tmStateReference -- transport information to be used=0A= IN maxMessageSize -- of the sending SNMP entity=0A= )=0A= =0A= =0A= The following describes the procedure to follow to establish a=0A= session between a client and server to run SNMP over SSH. This=0A= process is used by any SNMP engine establishing a session for=0A= subsequent use.=0A= =0A= This will be done automatically for an SNMP application that=0A= initiates a transaction, such as a Command Generator or a=0A= Notification Originator or a Proxy Forwarder.=0A= =0A= 1. Increment the sshtmSessionOpens counter.=0A= =0A= 2. Using tmTransportAddress, the client will establish an SSH=0A= transport connection using the SSH transport protocol,=0A= authenticate the server, and exchange keys for message integrity=0A= and encryption.=0A= =0A= 1. To authenticate the server, the client usually stores=0A= (tmTransportAddress, server host public key) pairs in an=0A= implementation-dependent manner.=0A= =0A= 2. The other parameters of the transport connection are provided=0A= in an implementation-dependent manner.=0A= =0A= 3. If the attempt to establish a connection is unsuccessful, or=0A= server authentication fails, then sshtmSessionOpenErrors is=0A= incremented, an openSession error indication is returned, and=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 16]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= openSession processing stops.=0A= =0A= 3. The client will then invoke an SSH authentication service to=0A= authenticate the principal, such as that described in the SSH=0A= authentication protocol [RFC4252].=0A= =0A= 1. If the tmTransportAddress field contains a user-name followed=0A= by an '@' character (ASCII 0x40), that user-name string that=0A= should be presented to the ssh server as the "user name" for=0A= user authentication purposes. If there is no user-name in=0A= the tmTransportAddress then the tmSecurityName should be used=0A= as the user-name.=0A= =0A= 2. The credentials used to authenticate the SSH principal are=0A= determined in an implementation-dependent manner.=0A= =0A= 3. In an implementation-specific manner, invoke the SSH user=0A= authentication service using the calculated user-name.=0A= =0A= 4. If the user authentication is unsuccessful, then the=0A= transport connection is closed, the=0A= sshtmSessionUserAuthFailures counter is incremented, an error=0A= indication is returned to the calling module, and processing=0A= stops for this message.=0A= =0A= 4. The client should invoke the "ssh-connection" service (also known=0A= as the SSH connection protocol [RFC4254]), and request a channel=0A= of type "session". If unsuccessful, the transport connection is=0A= closed, the sshtmSessionChannelOpenFailures counter is=0A= incremented, an error indication is returned to the calling=0A= module, and processing stops for this message.=0A= =0A= 5. The client invokes "snmp" as an SSH subsystem, as indicated in=0A= the "subsystem" parameter. If unsuccessful, the transport=0A= connection is closed, the sshtmSessionUnavailableSubsystems=0A= counter is incremented, an error indication is returned to the=0A= calling module, and processing stops for this message.=0A= =0A= In order to allow SNMP traffic to be easily identified and=0A= filtered by firewalls and other network devices, servers=0A= associated with SNMP entities using the Secure Shell Transport=0A= Model MUST default to providing access to the "snmp" SSH=0A= subsystem if the SSH session is established using the IANA-=0A= assigned TCP ports (YYY and ZZZ). Servers SHOULD be configurable=0A= to allow access to the SNMP SSH subsystem over other ports.=0A= =0A= 6. Set tmSessionID in the tmStateReference cache to an=0A= implementation-dependent value to identify the session.=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 17]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= 5.4. Closing a Session=0A= =0A= The Secure Shell Transport Model provides the following ASI to close=0A= a session:=0A= =0A= statusInformation =3D=0A= closeSession(=0A= IN tmSessionID -- transport address to be used=0A= )=0A= =0A= =0A= =0A= The following describes the procedure to follow to close a session=0A= between a client and server . This process is followed by any SNMP=0A= engine to close an SSH session. It is implementation-dependent when=0A= a session should be closed. The calling code should release the=0A= associated tmStateReference.=0A= =0A= 1. Increment the sshtmSessionCloses counter.=0A= =0A= 2. If there is no session corresponding to tmSessionID, then=0A= closeSession processing is completed.=0A= =0A= 3. Have SSH close the session associated with tmSessionID.=0A= =0A= 6. MIB Module Overview=0A= =0A= This MIB module provides management of the Secure Shell Transport=0A= Model. It defines an OID to identify the SNMP-over-SSH transport=0A= domain, a textual convention for SSH Addresses and several statistics=0A= counters.=0A= =0A= 6.1. Structure of the MIB Module=0A= =0A= Objects in this MIB module are arranged into subtrees. Each subtree=0A= is organized as a set of related objects. The overall structure and=0A= assignment of objects to their subtrees, and the intended purpose of=0A= each subtree, is shown below.=0A= =0A= 6.2. Textual Conventions=0A= =0A= Generic and Common Textual Conventions used in this document can be=0A= found summarized at http://www.ops.ietf.org/mib-common-tcs.html=0A= =0A= 6.3. Relationship to Other MIB Modules=0A= =0A= Some management objects defined in other MIB modules are applicable=0A= to an entity implementing the SSH Transport Model. In particular, it=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 18]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= is assumed that an entity implementing the SSHTM-MIB will implement=0A= the SNMPv2-MIB [RFC3418], and the SNMP-FRAMEWORK-MIB [RFC3411]. It=0A= is expected that an entity implementing this MIB will also support=0A= the Transport Security Model=0A= [I-D.ietf-isms-transport-security-model], and therefore implement the=0A= SNMP-TSM-MIB.=0A= =0A= This MIB module is for monitoring SSH Transport Model information.=0A= =0A= 6.3.1. MIB Modules Required for IMPORTS=0A= =0A= The following MIB module imports items from [RFC2578], [RFC2579],=0A= [RFC2580].=0A= =0A= This MIB module also references [RFC3490] and [RFC3986]=0A= =0A= 7. MIB Module Definition=0A= =0A= =0A= SSHTM-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE,=0A= OBJECT-IDENTITY, mib-2, snmpDomains,=0A= Counter32=0A= FROM SNMPv2-SMI=0A= TEXTUAL-CONVENTION=0A= FROM SNMPv2-TC=0A= MODULE-COMPLIANCE, OBJECT-GROUP=0A= FROM SNMPv2-CONF=0A= ;=0A= =0A= sshtmMIB MODULE-IDENTITY=0A= LAST-UPDATED "200810130000Z"=0A= ORGANIZATION "ISMS Working Group"=0A= CONTACT-INFO "WG-EMail: isms@lists.ietf.org=0A= Subscribe: isms-request@lists.ietf.org=0A= =0A= Chairs:=0A= Juergen Quittek=0A= NEC Europe Ltd.=0A= Network Laboratories=0A= Kurfuersten-Anlage 36=0A= 69115 Heidelberg=0A= Germany=0A= +49 6221 90511-15=0A= quittek@netlab.nec.de=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 19]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Juergen Schoenwaelder=0A= Jacobs University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= +49 421 200-3587=0A= j.schoenwaelder@iu-bremen.de=0A= =0A= Co-editors:=0A= David Harrington=0A= Huawei Technologies USA=0A= 1700 Alma Drive=0A= Plano Texas 75075=0A= USA=0A= +1 603-436-8634=0A= ietfdbh@comcast.net=0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= jsalowey@cisco.com=0A= =0A= Wes Hardaker=0A= Sparta, Inc.=0A= P.O. Box 382=0A= Davis, CA 95617=0A= USA=0A= +1 530 792 1913=0A= ietf@hardakers.net=0A= "=0A= DESCRIPTION "The Secure Shell Transport Model MIB=0A= =0A= Copyright (C) The IETF Trust (2008). This=0A= version of this MIB module is part of RFC XXXX;=0A= see the RFC itself for full legal notices.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= REVISION "200810130000Z"=0A= DESCRIPTION "The initial version, published in RFC XXXX.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= ::=3D { mib-2 xxxx }=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 20]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= -- RFC Ed.: replace xxxx with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- ---------------------------------------------------------- --=0A= -- subtrees in the SNMP-SSH-TM-MIB=0A= -- ---------------------------------------------------------- --=0A= =0A= sshtmNotifications OBJECT IDENTIFIER ::=3D { sshtmMIB 0 }=0A= sshtmObjects OBJECT IDENTIFIER ::=3D { sshtmMIB 1 }=0A= sshtmConformance OBJECT IDENTIFIER ::=3D { sshtmMIB 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Objects=0A= -- -------------------------------------------------------------=0A= =0A= snmpSSHDomain OBJECT-IDENTITY=0A= STATUS current=0A= DESCRIPTION=0A= "The SNMP over SSH transport domain. The corresponding transport=0A= address is of type SnmpSSHAddress.=0A= =0A= When an SNMP entity uses the snmpSSHDomain transport=0A= model, it must be capable of accepting messages up to=0A= and including 8192 octets in size. Implementation of=0A= larger values is encouraged whenever possible.=0A= =0A= The securityName prefix to be associated with the=0A= snmpSSHDomain is 'ssh'. This prefix may be used by security=0A= models or other components to identify what secure transport=0A= infrastructure authenticated a securityName."=0A= ::=3D { snmpDomains yy }=0A= =0A= -- RFC Ed.: Please replace the I-D reference with a proper one once it=0A= -- has been published.=0A= =0A= -- RFC Ed.: replace yy with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- RFC Ed.: replace 'ssh' with the actual IANA assigned prefix string=0A= -- if 'ssh' is not assigned to this document.=0A= =0A= SnmpSSHAddress ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "1a"=0A= STATUS current=0A= DESCRIPTION=0A= "Represents either a hostname or IP address, along with a port=0A= number and an optional username.=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 21]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= The beginning of the address specification may contain a=0A= username followed by an '@' (ASCII character 0x40). This=0A= portion of the address will indicate the user name that should=0A= be used when authenticating to an SSH server. If missing, the=0A= SNMP securityName should be used. After the optional user name=0A= field and '@' character comes the hostname or IP address.=0A= =0A= The hostname must be encoded in ASCII, as specified in=0A= RFC3490 (Internationalizing Domain Names in Applications)=0A= followed by a colon ':' (ASCII character 0x3A) and a=0A= decimal port number in ASCII. The name SHOULD be fully=0A= qualified whenever possible.=0A= =0A= An IPv4 address must be in dotted decimal format followed=0A= by a colon ':' (ASCII character 0x3A) and a decimal port=0A= number in ASCII.=0A= =0A= An IPv6 address must be in colon separated format, surrounded=0A= by square brackets ('[' ASCII character 0x5B and ']' ASCII=0A= character 0x5D), followed by a colon ':' (ASCII character=0A= 0x3A) and a decimal port number in ASCII.=0A= =0A= Values of this textual convention might not be directly useable=0A= as transport-layer addressing information, and may require=0A= runtime resolution. As such, applications that write them=0A= must be prepared for handling errors if such values are=0A= not supported, or cannot be resolved (if resolution occurs=0A= at the time of the management operation).=0A= =0A= The DESCRIPTION clause of TransportAddress objects that may=0A= have snmpSSHAddress values must fully describe how (and=0A= when) such names are to be resolved to IP addresses and vice=0A= versa.=0A= =0A= This textual convention SHOULD NOT be used directly in=0A= object definitions since it restricts addresses to a=0A= specific format. However, if it is used, it MAY be used=0A= either on its own or in conjunction with=0A= TransportAddressType or TransportDomain as a pair.=0A= =0A= When this textual convention is used as a syntax of an=0A= index object, there may be issues with the limit of 128=0A= sub-identifiers specified in SMIv2, STD 58. It is=0A= RECOMMENDED that all MIB documents using this textual=0A= convention make explicit any limitations on index=0A= component lengths that management software must observe.=0A= This may be done either by including SIZE constraints on=0A= the index components or by specifying applicable=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 22]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= constraints in the conceptual row DESCRIPTION clause or=0A= in the surrounding documentation.=0A= "=0A= REFERENCE=0A= "RFC3986, Uniform Resource Identifier (URI): Generic Syntax"=0A= SYNTAX OCTET STRING (SIZE (1..255))=0A= =0A= =0A= -- The sshtmSession Group=0A= =0A= sshtmSession OBJECT IDENTIFIER ::=3D { sshtmObjects 1 }=0A= =0A= sshtmSessionOpens OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request has been=0A= executed as an SSH client, whether it succeeded or=0A= failed.=0A= "=0A= ::=3D { sshtmSession 1 }=0A= =0A= sshtmSessionCloses OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times a closeSession() request has been=0A= executed as an SSH client, whether it succeeded or=0A= failed.=0A= "=0A= ::=3D { sshtmSession 2 }=0A= =0A= sshtmSessionOpenErrors OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a transport connection, or failed to=0A= authenticate the server.=0A= "=0A= ::=3D { sshtmSession 3 }=0A= =0A= sshtmSessionUserAuthFailures OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a session as a SSH client due to user=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 23]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= authentication failures.=0A= "=0A= ::=3D { sshtmSession 4 }=0A= =0A= sshtmSessionChannelOpenFailures OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a session as a SSH client due to=0A= channel open failures.=0A= "=0A= ::=3D { sshtmSession 5 }=0A= =0A= sshtmSessionUnavailableSubsystems OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a session as a SSH client due to=0A= inability to connect to the requested subsystem.=0A= "=0A= ::=3D { sshtmSession 6 }=0A= =0A= sshtmSessionNoAvailableSessions OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an outgoing message=0A= was dropped because the same=0A= session was no longer available.=0A= "=0A= ::=3D { sshtmSession 7 }=0A= =0A= sshtmSessionInvalidCaches OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of outgoing messages dropped because the=0A= tmStateReference referred to an invalid cache.=0A= "=0A= ::=3D { sshtmSession 8 }=0A= =0A= -- ************************************************=0A= -- sshtmMIB - Conformance Information=0A= -- ************************************************=0A= =0A= sshtmCompliances OBJECT IDENTIFIER ::=3D { sshtmConformance 1 }=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 24]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= sshtmGroups OBJECT IDENTIFIER ::=3D { sshtmConformance 2 }=0A= =0A= -- ************************************************=0A= -- Compliance statements=0A= -- ************************************************=0A= =0A= sshtmCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= =0A= DESCRIPTION "The compliance statement for SNMP engines that=0A= support the SNMP-SSH-TM-MIB"=0A= MODULE=0A= MANDATORY-GROUPS { sshtmGroup }=0A= ::=3D { sshtmCompliances 1 }=0A= =0A= -- ************************************************=0A= -- Units of conformance=0A= -- ************************************************=0A= sshtmGroup OBJECT-GROUP=0A= OBJECTS {=0A= sshtmSessionOpens,=0A= sshtmSessionCloses,=0A= sshtmSessionOpenErrors,=0A= sshtmSessionUserAuthFailures,=0A= sshtmSessionChannelOpenFailures,=0A= sshtmSessionUnavailableSubsystems,=0A= sshtmSessionNoAvailableSessions=0A= }=0A= STATUS current=0A= DESCRIPTION "A collection of objects for maintaining=0A= information of an SNMP engine which implements the=0A= SNMP Secure Shell Transport Model.=0A= "=0A= =0A= =0A= ::=3D { sshtmGroups 2 }=0A= =0A= =0A= END=0A= =0A= =0A= 8. Operational Considerations=0A= =0A= The SSH Transport Model will likely not work in conditions where=0A= access to the CLI has stopped working. In situations where SNMP=0A= access has to work when the CLI has stopped working, a UDP transport=0A= model should be considered instead of the SSH Transport Model.=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 25]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= If the SSH Transport Model is configured to utilize AAA services,=0A= operators should consider configuring support for local=0A= authentication mechanisms, such as local passwords, so SNMP can=0A= continue operating during times of network stress.=0A= =0A= The SSH protocol has its own window mechanism, defined in RFC 4254.=0A= The SSH specifications leave it open when window adjustments messages=0A= should be created, and some implementations send these whenever=0A= received data has been passed to the application. There are=0A= noticeable bandwidth and processing overheads to handling such window=0A= adjustment messages, which can be avoided by sending them less=0A= frequently.=0A= =0A= The SSH protocol requires the execution of CPU intensive calculations=0A= to establish a session key during session establishment. This means=0A= that short lived sessions become computationally expensive compared=0A= to USM, which does not have a notion of a session key. Other=0A= transport security protocols such as TLS support a session resumption=0A= feature that allows reusing a cached session key. Such a mechanism=0A= does not exist for SSH and thus SNMP applications should keep SSH=0A= sessions for longer time periods.=0A= =0A= To initiate SSH connections, an entity must be configured with SSH=0A= client credentials plus information to authenticate the server.=0A= While hosts are often configured to be SSH clients, most=0A= internetworking devices are not. To send notifications over SSHTM,=0A= the internetworking device will need to be configured as an SSH=0A= client. How this credential configuration is done is implementation=0A= and deployment specific.=0A= =0A= 9. Security Considerations=0A= =0A= This document describes a transport model that permits SNMP to=0A= utilize SSH security services. The security threats and how the SSH=0A= Transport Model mitigates those threats is covered in detail=0A= throughout this memo.=0A= =0A= The SSH Transport Model relies on SSH mutual authentication, binding=0A= of keys, confidentiality and integrity. Any authentication method=0A= that meets the requirements of the SSH architecture will provide the=0A= properties of mutual authentication and binding of keys.=0A= =0A= SSHv2 provides Perfect Forward Security (PFS) for encryption keys.=0A= PFS is a major design goal of SSH, and any well-designed keyex=0A= algorithm will provide it.=0A= =0A= The security implications of using SSH are covered in [RFC4251].=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 26]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= The SSH Transport Model has no way to verify that server=0A= authentication was performed, to learn the host's public key in=0A= advance, or verify that the correct key is being used. The SSH=0A= Transport Model simply trusts that these are properly configured by=0A= the implementer and deployer.=0A= =0A= SSH provides the "none" userauth method. The SSH Transport Model=0A= MUST NOT be used with an SSH connection with the "none" userauth=0A= method. While SSH does support turning off confidentiality and=0A= integrity, they MUST NOT be turned off when used with the SSH=0A= Transport Model.=0A= =0A= The SSH protocol is not always clear on whether the user name field=0A= must be filled in, so for some implementations, such as those using=0A= GSSAPI authentication, it may be necessary to use a mapping algorithm=0A= to transform an SSH identity to a tmSecurityName, or to transform a=0A= tmSecurityName to an SSH identity.=0A= =0A= In other cases the user name may not be verified by the server, so=0A= for these implementations, it may be necessary to obtain the user=0A= name from other credentials exchanged during the SSH exchange.=0A= =0A= 9.1. Skipping Public Key Verification=0A= =0A= Most key exchange algorithms are able to authenticate the SSH=0A= server's identity to the client. However, for the common case of DH=0A= signed by public keys, this requires the client to know the host's=0A= public key a priori and to verify that the correct key is being used.=0A= If this step is skipped, then authentication of the SSH server to the=0A= SSH client is not done. Data confidentiality and data integrity=0A= protection to the server still exist, but these are of dubious value=0A= when an attacker can insert himself between the client and the real=0A= SSH server. Note that some userauth methods may defend against this=0A= situation, but many of the common ones (including password and=0A= keyboard-interactive) do not, and in fact depend on the fact that the=0A= server's identity has been verified (so passwords are not disclosed=0A= to an attacker).=0A= =0A= SSH MUST NOT be configured to skip public key verification for use=0A= with the SSH Transport Model.=0A= =0A= 9.2. The 'none' MAC Algorithm=0A= =0A= SSH provides the "none" MAC algorithm, which would allow you to turn=0A= off data integrity while maintaining confidentiality. However, if=0A= you do this, then an attacker may be able to modify the data in=0A= flight, which means you effectively have no authentication.=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 27]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= SSH MUST NOT be configured using the "none" MAC algorithm for use=0A= with the SSH Transport Model.=0A= =0A= 9.3. Use with SNMPv1/v2c Messages=0A= =0A= The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP=0A= 74) [RFC3584] always select the SNMPv1 or SNMPv2c Security Models=0A= respectively. Both of these, and the User-based Security Model=0A= typically used with SNMPv3, derive the securityName and securityLevel=0A= from the SNMP message received, even when the message was received=0A= over a secure transport. Access control decisions are therefore made=0A= based on the contents of the SNMP message, rather than using the=0A= authenticated identity and securityLevel provided by the SSH=0A= Transport Model.=0A= =0A= 9.4. MIB Module Security=0A= =0A= There are no management objects defined in this MIB module that have=0A= a MAX-ACCESS clause of read-write and/or read-create. So, if this=0A= MIB module is implemented correctly, then there is no risk that an=0A= intruder can alter or create any management objects of this MIB=0A= module via direct SNMP SET operations.=0A= =0A= Some of the readable objects in this MIB module (i.e., objects with a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET and/or NOTIFY access to these objects and possibly=0A= to even encrypt the values of these objects when sending them over=0A= the network via SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o The readable objects in this MIB module are not sensitive.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using IPSec or=0A= SSH), even then, there is no control as to who on the secure network=0A= is allowed to access and GET/SET (read/change/create/delete) the=0A= objects in this MIB module.=0A= =0A= It is RECOMMENDED that implementers consider the security features as=0A= provided by the SNMPv3 framework (see [RFC3410] section 8), including=0A= full support for the USM and the SSH Transport Model cryptographic=0A= mechanisms (for authentication and privacy).=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=0A= enable cryptographic security. It is then a customer/operator=0A= responsibility to ensure that the SNMP entity giving access to an=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 28]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= instance of this MIB module is properly configured to give access to=0A= the objects only to those principals (users) that have legitimate=0A= rights to indeed GET or SET (change/create/delete) them.=0A= =0A= 10. IANA Considerations=0A= =0A= IANA is requested to assign:=0A= =0A= 1. two TCP registered port numbers in the=0A= http://www.iana.org/assignments/port-numbers registry which will=0A= be the default ports for SNMP over an SSH Transport Model (SSHTM)=0A= as defined in this document, and SNMP over an SSH Transport Model=0A= for notifications (SSHTM-TRAP) as defined in this document. It=0A= would be good if the assigned numbers were x161 and x162.=0A= =0A= 2. an SMI number under mib-2, for the MIB module in this document,=0A= =0A= 3. an SMI number under snmpDomains, for the snmpSSHDomain,=0A= =0A= 4. "ssh" as the corresponding prefix for the snmpSSHDomain in the=0A= SNMP Transport Model registry; defined in [I-D.ietf-isms-tmsm]=0A= =0A= 5. "snmp" as an SSH Subsystem Name in the=0A= http://www.iana.org/assignments/ssh-parameters registry.=0A= =0A= -- note to RFC editor -- Please replace YYY and ZZZ in this document=0A= with the assigned port numbers and remove this note.=0A= =0A= 11. Acknowledgements=0A= =0A= The editors would like to thank Jeffrey Hutzelman for sharing his SSH=0A= insights, and Dave Shield for an outstanding job wordsmithing the=0A= existing document to improve organization and clarity.=0A= =0A= Additionally, helpful document reviews were received from: Juergen=0A= Schoenwaelder.=0A= =0A= 12. References=0A= =0A= 12.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for=0A= use in RFCs to Indicate=0A= Requirement Levels",=0A= BCP 14, RFC 2119,=0A= March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed.,=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 29]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed.,=0A= "Structure of Management=0A= Information Version 2=0A= (SMIv2)", STD 58, RFC 2578,=0A= April 1999.=0A= =0A= [RFC2579] McCloghrie, K., Ed.,=0A= Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed.,=0A= "Textual Conventions for=0A= SMIv2", STD 58, RFC 2579,=0A= April 1999.=0A= =0A= [RFC2580] McCloghrie, K., Perkins,=0A= D., and J. Schoenwaelder,=0A= "Conformance Statements for=0A= SMIv2", STD 58, RFC 2580,=0A= April 1999.=0A= =0A= [RFC2865] Rigney, C., Willens, S.,=0A= Rubens, A., and W. Simpson,=0A= "Remote Authentication Dial=0A= In User Service (RADIUS)",=0A= RFC 2865, June 2000.=0A= =0A= [RFC3411] Harrington, D., Presuhn,=0A= R., and B. Wijnen, "An=0A= Architecture for Describing=0A= Simple Network Management=0A= Protocol (SNMP) Management=0A= Frameworks", STD 62,=0A= RFC 3411, December 2002.=0A= =0A= [RFC3413] Levi, D., Meyer, P., and B.=0A= Stewart, "Simple Network=0A= Management Protocol (SNMP)=0A= Applications", STD 62,=0A= RFC 3413, December 2002.=0A= =0A= [RFC3414] Blumenthal, U. and B.=0A= Wijnen, "User-based=0A= Security Model (USM) for=0A= version 3 of the Simple=0A= Network Management Protocol=0A= (SNMPv3)", STD 62,=0A= RFC 3414, December 2002.=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 30]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= [RFC3418] Presuhn, R., "Management=0A= Information Base (MIB) for=0A= the Simple Network=0A= Management Protocol=0A= (SNMP)", STD 62, RFC 3418,=0A= December 2002.=0A= =0A= [RFC3490] Faltstrom, P., Hoffman, P.,=0A= and A. Costello,=0A= "Internationalizing Domain=0A= Names in Applications=0A= (IDNA)", RFC 3490,=0A= March 2003.=0A= =0A= [RFC3584] Frye, R., Levi, D.,=0A= Routhier, S., and B.=0A= Wijnen, "Coexistence=0A= between Version 1, Version=0A= 2, and Version 3 of the=0A= Internet-standard Network=0A= Management Framework",=0A= BCP 74, RFC 3584,=0A= August 2003.=0A= =0A= [RFC4251] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Protocol Architecture",=0A= RFC 4251, January 2006.=0A= =0A= [RFC4252] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Authentication Protocol",=0A= RFC 4252, January 2006.=0A= =0A= [RFC4253] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Transport Layer Protocol",=0A= RFC 4253, January 2006.=0A= =0A= [RFC4254] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Connection Protocol",=0A= RFC 4254, January 2006.=0A= =0A= [I-D.ietf-isms-tmsm] Harrington, D. and J.=0A= Schoenwaelder, "Transport=0A= Subsystem for the Simple=0A= Network Management Protocol=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 31]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= (SNMP)",=0A= draft-ietf-isms-tmsm-15=0A= (work in progress),=0A= October 2008.=0A= =0A= 12.2. Informative References=0A= =0A= [RFC1994] Simpson, W., "PPP Challenge=0A= Handshake Authentication=0A= Protocol (CHAP)", RFC 1994,=0A= August 1996.=0A= =0A= [RFC3410] Case, J., Mundy, R.,=0A= Partain, D., and B.=0A= Stewart, "Introduction and=0A= Applicability Statements=0A= for Internet-Standard=0A= Management Framework",=0A= RFC 3410, December 2002.=0A= =0A= [RFC3588] Calhoun, P., Loughney, J.,=0A= Guttman, E., Zorn, G., and=0A= J. Arkko, "Diameter Base=0A= Protocol", RFC 3588,=0A= September 2003.=0A= =0A= [RFC3986] Berners-Lee, T., Fielding,=0A= R., and L. Masinter,=0A= "Uniform Resource=0A= Identifier (URI): Generic=0A= Syntax", STD 66, RFC 3986,=0A= January 2005.=0A= =0A= [RFC4256] Cusack, F. and M. Forssen,=0A= "Generic Message Exchange=0A= Authentication for the=0A= Secure Shell Protocol=0A= (SSH)", RFC 4256,=0A= January 2006.=0A= =0A= [RFC4462] Hutzelman, J., Salowey, J.,=0A= Galbraith, J., and V.=0A= Welch, "Generic Security=0A= Service Application Program=0A= Interface (GSS-API)=0A= Authentication and Key=0A= Exchange for the Secure=0A= Shell (SSH) Protocol",=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 32]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= RFC 4462, May 2006.=0A= =0A= [RFC5090] Sterman, B., Sadolevsky,=0A= D., Schwartz, D., Williams,=0A= D., and W. Beck, "RADIUS=0A= Extension for Digest=0A= Authentication", RFC 5090,=0A= February 2008.=0A= =0A= [RFC4742] Wasserman, M. and T.=0A= Goddard, "Using the NETCONF=0A= Configuration Protocol over=0A= Secure SHell (SSH)",=0A= RFC 4742, December 2006.=0A= =0A= [I-D.ietf-isms-transport-security-model] Harrington, D. and W.=0A= Hardaker, "Transport=0A= Security Model for SNMP", d=0A= raft-ietf-isms-transport-=0A= security-model-10 (work in=0A= progress), October 2008.=0A= =0A= Appendix A. Change Log=0A= =0A= From -13 to -14=0A= =0A= Removed duplicated text on Caches and References, and reference=0A= tmsm document=0A= =0A= Simplified securityStateReference=0A= =0A= Simplified EOP to use tmStateReference rather than ASI parameters=0A= =0A= Simplified openSession and closeSession=0A= =0A= Seperated steps in openSession=0A= =0A= Clarified conditions in the openSession error counter descriptions=0A= =0A= Reworded text to clarify short versus long term information=0A= =0A= Added more warnings about the unreliability of SSH user name=0A= =0A= removed any references to LCD=0A= =0A= From -12 to -13=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 33]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Removed redundant sections 3.1.4 and 3.1.5 on privacy and replay/=0A= delay/etc protection.=0A= =0A= From -11- to -12=0A= =0A= Updated "Cached Information and References" to match other ISMS=0A= documents.=0A= =0A= Added separate subsection on Secure Shell Transport Model Cached=0A= Information.=0A= =0A= Added IANA considerations to add snmpSSHDomain and "ssh" to a=0A= registry for domains and corresponding prefixes, defined in TMSM.=0A= =0A= Added support for user@ prefixing in the SSH Transport Address=0A= definition and EOP.=0A= =0A= Added support for the "ssh" prefix to the transport address=0A= definition and IANA considerations section.=0A= =0A= Removed the LCD tables and related configuration since the user@=0A= transport address prefixing and the TSM user prefix changes change=0A= makes it no longer needed.=0A= =0A= From -10- to -11=0A= =0A= Changed LCD to sshtmLCDTable so it would not be confused with the=0A= snmpTsmLCD.=0A= =0A= Removed the text that said the format and content of the LCD is=0A= implementation-specific, since we now have a MIB module to=0A= standardize the format and content.=0A= =0A= Designed sshtmLCDTable to reflect there is only one=0A= transportDomain and one securityLevel supported by this transport=0A= model.=0A= =0A= Used sshtmLCDTmSecurityName to reflect that the values in this=0A= table and the values in the tmStateReference are usually the same=0A= for some fields.=0A= =0A= Added operational considerations about SSH client credential=0A= distribution.=0A= =0A= Modified EOP to use sshtmLCDTable=0A= =0A= Resolved Issue #8: Should we allow transport models to select the=0A= corresponding security model by providing an additional parameter=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 34]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= - the securityModel parameter - to tmStateReference, which would=0A= override the securityModel parameter extracted from a message=0A= header? Doing this would resolve Issue #5, and would allow the=0A= transport security model to be used with all SNMP message=0A= versions. - The consensus is that we will not allow the transport=0A= model to specify the security model.=0A= =0A= From -09- to -10=0A= =0A= Issue #1: Made release of cached session info an implementation=0A= requirement on session close.=0A= =0A= Issue #4: UTF-8 syntax of userauth user name matches syntax of=0A= SnmpAdminString.=0A= =0A= Issue #7: Resolved to not describe how an SSH session is closed.=0A= =0A= From -08- to -09=0A= =0A= Updated MIB assignment to by rfc4181 compatible=0A= =0A= update MIB security considerations with coexistence issues=0A= =0A= update sameSession and tmSessionID support=0A= =0A= Fixed note about terminology, for consistency with SNMPv3.=0A= =0A= From -07- to -08=0A= =0A= Updated MIB=0A= =0A= update MIB security considerations=0A= =0A= develop sameSession and tmSessionID support=0A= =0A= Added a note about terminology, for consistency with SNMPv3 rather=0A= than with RFC2828.=0A= =0A= Removed reference to mappings other than the identity function.=0A= =0A= From -06- to -07=0A= =0A= removed section on SSH to EngineID mappings, since engineIDs are=0A= not exposed to the transport model=0A= =0A= removed references to engineIDs and discovery=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 35]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= removed references to securityModel.=0A= =0A= added security considerations warning about using with SNMPv1/v2c=0A= messages.=0A= =0A= added keyboard interactive discussion=0A= =0A= noted some implementation-dependent points=0A= =0A= removed references to transportModel; we use the transport domain=0A= as a model identifier.=0A= =0A= cleaned up ASIs=0A= =0A= modified MIB to be under snmpModules=0A= =0A= changed transportAddressSSH to snmpSSHDomain style addressing=0A= =0A= From -05- to -06=0A= =0A= replaced transportDomainSSH with RFC3417-style snmpSSHDomain=0A= =0A= replaced transportAddressSSH with RFC3417-style snmpSSHAddress=0A= =0A= Changed recvMessage to receiveMessage, and modified OUT to IN to=0A= match TMSM.=0A= =0A= From -04- to -05=0A= =0A= added sshtmUserTable=0A= =0A= moved session table into the transport model MIB from the=0A= transport subsystem MIB=0A= =0A= added and then removed Appendix A - Notification Tables=0A= Configuration (see Transport Security Model)=0A= =0A= made this document a specification of a transport model, rather=0A= than a security model in two parts. Eliminated TMSP and MPSP and=0A= replaced them with "transport model" and "security model".=0A= =0A= Removed security-model-specific processing from this document.=0A= =0A= Removed discussion of snmpv3/v1/v2c message format co-existence=0A= =0A= changed tmSessionReference back to tmStateReference=0A= =0A= "From -03- to -04-"=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 36]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= changed tmStateReference to tmSessionReference=0A= =0A= =0A= =0A= "From -02- to -03-"=0A= =0A= rewrote almost all sections=0A= =0A= merged ASI section and Elements of Procedure sections=0A= =0A= removed references to the SSH user, in preference to SSH client=0A= =0A= updated references=0A= =0A= created a conventions section to identify common terminology.=0A= =0A= rewrote sections on how SSH addresses threats=0A= =0A= rewrote mapping SSH to engineID=0A= =0A= eliminated discovery section=0A= =0A= detailed the Elements of Procedure=0A= =0A= eliminated sections on msgFlags, transport parameters=0A= =0A= resolved issues of opening notifications=0A= =0A= eliminated sessionID (TMSM needs to be updated to match)=0A= =0A= eliminated use of tmsSessiontable except as an example=0A= =0A= updated Security Considerations=0A= =0A= "From -01- to -02-"=0A= =0A= Added TransportDomainSSH and Address=0A= =0A= Removed implementation considerations=0A= =0A= Changed all "user auth" to "client auth"=0A= =0A= Removed unnecessary MIB module objects=0A= =0A= updated references=0A= =0A= improved consistency of references to TMSM as architectural=0A= extension=0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 37]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= updated conventions=0A= =0A= updated threats to be more consistent with RFC3552=0A= =0A= discussion of specific SSH mechanism configurations moved to=0A= security considerations=0A= =0A= modified session discussions to reference TMSM sessions=0A= =0A= expanded discussion of engineIDs=0A= =0A= wrote text to clarify the roles of MPSP and TMSP=0A= =0A= clarified how snmpv3 message parts are ised by SSHSM=0A= =0A= modified nesting of subsections as needed=0A= =0A= securityLevel used by the SSH Transport Model always equals=0A= authPriv=0A= =0A= removed discussion of using SSHSM with SNMPv1/v2c=0A= =0A= started updating Elements of Procedure, but realized missing info=0A= needs discussion.=0A= =0A= updated MIB module relationship to other MIB modules=0A= =0A= "From -00- to -01-"=0A= =0A= -00- initial draft as ISMS work product:=0A= =0A= updated references to secshell RFCs=0A= =0A= Modified text related to issues# 1, 2, 8, 11, 13, 14, 16, 18, 19,=0A= 20, 29, 30, and 32.=0A= =0A= updated security considerations=0A= =0A= removed Juergen Schoenwaelder from authors, at his request=0A= =0A= ran the mib module through smilint=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 38]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Authors' Addresses=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= =0A= EMail: jsalowey@cisco.com=0A= =0A= =0A= Wes Hardaker=0A= Sparta, Inc.=0A= P.O. Box 382=0A= Davis, CA 95617=0A= US=0A= =0A= Phone: +1 530 792 1913=0A= EMail: ietf@hardakers.net=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 39]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2009).=0A= =0A= This document is subject to the rights, licenses and restrictions=0A= contained in BCP 78, and except as set forth therein, the authors=0A= retain all their rights.=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 13, 2009 [Page 40]=0A= =0C=0A= =0A= ------=_NextPart_000_0952_01C98B0B.4FFB7330-- From dbharrington@comcast.net Mon Feb 9 20:19:25 2009 Return-Path: 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 262CC3A6903 for ; Mon, 9 Feb 2009 20:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 P8uleLhdeQ6V for ; Mon, 9 Feb 2009 20:19:24 -0800 (PST) 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 CC4C43A68F4 for ; Mon, 9 Feb 2009 20:19:23 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA02.westchester.pa.mail.comcast.net with comcast id DoB81b0020EZKEL524KTid; Tue, 10 Feb 2009 04:19:27 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA01.westchester.pa.mail.comcast.net with comcast id E4KS1b00B0UQ6dC3M4KSJx; Tue, 10 Feb 2009 04:19:27 +0000 From: "David B Harrington" To: "'Wes Hardaker'" , "'Jeffrey Hutzelman'" References: <20090127083933.GC12355@elstar.local><200901282258.n0SMw53g024330@toasties.srv.cs.cmu.edu><4BB6D8A8E1F91F93B85A62F7@atlantis.pc.cs.cmu.edu><200901282344.n0SNiunA000877@grapenut.srv.cs.cmu.edu><200901290108.n0T18S7R014276@raisinbran.srv.cs.cmu.edu><8026D632B9CA159AAC2154FA@atlantis.pc.cs.cmu.edu> Date: Mon, 9 Feb 2009 23:19:25 -0500 Message-ID: <095b01c98b36$c25d2970$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcmLGCTSVhgGzeeZQSqEdLymnFxUTAAHJemQ Cc: isms@ietf.org Subject: Re: [Isms] TBD secshell 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: , X-List-Received-Date: Tue, 10 Feb 2009 04:19:25 -0000 Hi, I just sent out updates to all three documents. This problem is not addressed. Can you tell me how to change the text? I am not sure I understand the edits. dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Monday, February 09, 2009 7:40 PM > To: Jeffrey Hutzelman > Cc: David B Harrington; isms@ietf.org > Subject: Re: TBD secshell > > > DH> tmSecurityName is set to "alice" by TSM. SSHTM is the > place where the > DH> requested tmSecurityName "alice" is overridden, and > ahopkins is chosen > DH> as the user name. > [...] > > JH> You're making this all too complicated, I think. > > I agree! > > Your (David H's) original message on the subject stated: > > DH> I think the EOP needs to be modified to make sure the message > DH> processing model can match the outgoing transportaddress for a > DH> request and the incoming transportaddress from the response, which > DH> is how the MPM determines which application is waiting for a > DH> response. If the request was sent using a user@foo.com address, > DH> then SSHTM uses parses the address into a foo.com address and uses > DH> foo instead of the tmsecurityname specified by the security > DH> model. When we get a response from user at foo.com, we > need to make > DH> the TM pass the MPM a transport address of the > user@foo.com format, > DH> and set the tmsecurityname to match what was requested by the > DH> security model. > > > There is only two cases to consider when talking about the SSHTM: > > 1) The SSHTM is acting as an SSH server. IE, it was invoked from afar > and in this case the securityName used within the SNMP system will > match exactly the SSH user name. Nothing confusing to > behold. When > the SSHTM creates a transportAddress for the connection in order to > pass it upward through the SNMPv3 stack it doesn't need to be > anything more complex than the remote host address, ':' and port > number. The prepended SSH user name and '@' is not needed because > it's equal to the securityName. > > 2) The SSHTM is acting as a client. IE, it is initialized from the > upper SNMPv3 stack and is handed a transportAddress to talk to. It > either will contain a "user@" type string or it won't. > > a) If it does not, again there is nothing much to consider > as complex > because the SSH user name will be identical to the securityName. > > b) If it does contain a "user@" type prefix, it should use that > within the SSH protocol for identifying itself > SSH-user-name-wise. This is where your problem comes > in, and this > is the only case that you think is confusing (right?), in > particular when a response comes back. > > So, when a response comes back across the SSH connection, the > SSHTM has to hand the message upward with a transportAddress. > Your statement above indicates that you think the > transportAddress > passed upward should be prepended with "user@" also. > That's fine > by me, but I'm not sure why you think it's complex to get the > right address created. > > The easiest solution is to cache the transportAddress > that created > the session and always use it when passing messages upward to > through the SNMPv3 stack. done. It also assures that the upper > SNMPv3 stack (specifically, your concerns with decisions in the > MPM) aren't affected by reverse name lookups not matching the > outgoing name, or IP addresses not matching DNS names, > or whatever. > > DH> I don't think it will be terribly difficult to update the > EOP, but I > DH> am not sure where the TM stores the request-state (tmsecurityname) > DH> that it must restore when it gets the response. > > In the same place it caches all the other information it > needs to about > a given SSH connection. > -- > Wes Hardaker > Sparta, Inc. > From ietfdbh@comcast.net Mon Feb 9 20:40:30 2009 Return-Path: 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 7A58A3A6B21 for ; Mon, 9 Feb 2009 20:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 j3ecTGThXpjY for ; Mon, 9 Feb 2009 20:40:29 -0800 (PST) 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 5F22A3A68DA for ; Mon, 9 Feb 2009 20:40:29 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA09.westchester.pa.mail.comcast.net with comcast id Dq0y1b00F0EZKEL594gZ8e; Tue, 10 Feb 2009 04:40:33 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA01.westchester.pa.mail.comcast.net with comcast id E4gY1b0010UQ6dC3M4gYtZ; Tue, 10 Feb 2009 04:40:33 +0000 From: "David Harrington" To: , References: <1696498986EFEC4D9153717DA325CB720265001D@vaebe104.NOE.Nokia.com> Date: Mon, 9 Feb 2009 23:40:30 -0500 Message-ID: <096401c98b39$b4cab4f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1696498986EFEC4D9153717DA325CB720265001D@vaebe104.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AclQhz6E3EeYK4jZSYmwNwYWd8X+9g4oT4hA Subject: Re: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 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: , X-List-Received-Date: Tue, 10 Feb 2009 04:40:30 -0000 Hi Pasi, Iam not certain that I have addressed all your issues. Can you please check the latest rev? comments inline. > Comments about draft-ietf-isms-secshell-13, Section 5: > > Overall: I think we're *almost* done -- I think we need to fill in > some minor details, but those shouldn't affect the overall processing. > > - The distinction between tmStateReference cache and LCD is a bit > unclear -- do these actually mean the same thing? For example, Section > 5.3 talks about creating an LCD entry when the SSH client has > established a connection (step 7), and Section 5.2 checks if the LCD > entry exists (step 2). I removed all references to an LCD. > > But there's no text saying that the SSH server ever creates any LCD > entries -- so step 2 of Section 5.2 would always fail when > e.g. sending command responses. That's clearly not the intention. > Section 5.1 does talk about creating a tmStateReference cache -- > perhaps it should talk about creating a LCD cache entry? Or perhaps > Sections 5.2/5.3 should talk about tmStateReference cache? Or perhaps > we need to describe opening a session also from SSH server's point > of view? (Section 5.3 talks only about what the SSH client does, and > says basically nothing about what the server does.) We now have no mechanism for storing any long-term information about a connection from the server's point of view, or lomg-term information about a connection from a ciient's point of view either. All we have is the tmStateReference cache, and I don't know quite how long that lives. > > - Section 5.2 (step 2) says the LCD entry is indexed by > (destTransportAddress,tmSecurityName) but 5.3 (step 7) says it's > (destTransportAddress,tmStateReference). Probably the former is > correct? (but in that case, there's no need to store tmSecurityName > in the entry itself, so step 7 of 5.3 may need some editing) > > - Section 5.3, step 1: it would be *really* useful to add a note > that to authenticate the server, the client usually stores > (destTransportAddress, server host public key) pairs in > implementation-dependent manner. (Otherwise, this text gets difficult > to understand.) I rewrote this section to make it much cleaner. Hopefully, I got all the steps right. > > - Section 5.1: we shouldneed a better description of how > tmSecurityName > works on the SSH client side; IMHO the current behavior isn't quite > right: Suppose a command generator sends a command with > tmSecurityName="alice" and > destTransportAddress="ahopkins@router1.example.net:1234". An SSH > connection is opened and so on. When the command response is received, > the current text in Section 5.1 would lead to having > tmSecurityName="ahopkins" in the response -- a slightly unexpected > response. Would it be better to extract the tmSecurityName from the > "LCD cache entry" (or whatever is the right term) that was created > when the client first established the session? > > - Section 5.1, on related note, on SSH client side, the > tmTransportAddress in incoming messages should probably also be > extracted from the "LCD cache entry", so that it's exactly the same as > was used for the outgoing message (that triggered creating the SSH > connection). It seems that needs to be done or the MPM will not match the response to the outstanding request to determine to which application the PDU must be delivered. > > - Section 5.1, we should say what the tmTransportAddress for incoming > messages looks on the SSH server side: it's "address:port" form (not > user@address:port). under discussion. > > - Typos: > Section 5.3, "tmSecurtityName" > Section 5.4, "sever" > Several sections (including the MIB): > "sshtmSessionUnavaliableSubsystems" > > Best regards, > Pasi > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Tue Feb 10 13:29:40 2009 Return-Path: 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 5EE0F3A6B5A for ; Tue, 10 Feb 2009 13:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.197, 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 wvGtBb5Xqd4t for ; Tue, 10 Feb 2009 13:29:39 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 9786F3A6B8F for ; Tue, 10 Feb 2009 13:29:39 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 2A20539A479; Tue, 10 Feb 2009 13:29:43 -0800 (PST) From: Wes Hardaker To: "David B Harrington" Organization: Sparta References: <20090127083933.GC12355@elstar.local> <200901282258.n0SMw53g024330@toasties.srv.cs.cmu.edu> <4BB6D8A8E1F91F93B85A62F7@atlantis.pc.cs.cmu.edu> <200901282344.n0SNiunA000877@grapenut.srv.cs.cmu.edu> <200901290108.n0T18S7R014276@raisinbran.srv.cs.cmu.edu> <8026D632B9CA159AAC2154FA@atlantis.pc.cs.cmu.edu> <095b01c98b36$c25d2970$0600a8c0@china.huawei.com> Date: Tue, 10 Feb 2009 13:29:43 -0800 In-Reply-To: <095b01c98b36$c25d2970$0600a8c0@china.huawei.com> (David B. Harrington's message of "Mon, 9 Feb 2009 23:19:25 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Jeffrey Hutzelman' , isms@ietf.org Subject: Re: [Isms] TBD secshell 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: , X-List-Received-Date: Tue, 10 Feb 2009 21:29:40 -0000 >>>>> On Mon, 9 Feb 2009 23:19:25 -0500, "David B Harrington" said: DBH> I just sent out updates to all three documents. DBH> This problem is not addressed. DBH> Can you tell me how to change the text? DBH> I am not sure I understand the edits. Sure. The only thing that needs to be added, IMHO, is a note saying the address should be consistent during the life of a session. i.e.: 5.1. Procedures for an Incoming Message 1. The SSH Transport Model queries the SSH engine, in an implementation-dependent manner, to determine the transportAddress, the principal name authenticated by SSH, and a session identifier. {+The transportAddress must be consistent during the life of a SSH session.+} ... jump to text after bullet 2 of 5.1 ... Prepare the transport parameters for the ASI: transportDomain = snmpSSHDomain transportAddress = the address {+of the SSH session that+} the message originated from, determined in an implementation-dependent way ... jump to bullet 2 of section 5.3 ... 2. Using tmTransportAddress, the client will establish an SSH transport connection using the SSH transport protocol, authenticate the server, and exchange keys for message integrity and encryption. {+The transportAddress associated with a session MUST remain constant during the lifetime of the SSH session. Implementations may need to cache the transportAddress passed to the openSession API for later use when performing incoming message processing (see section Section 5.1).+} -- Wes Hardaker Sparta, Inc. From cfinss@dial.pipex.com Wed Feb 11 08:35:18 2009 Return-Path: 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 1DE603A6B87 for ; Wed, 11 Feb 2009 08:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.463, 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 ZwT6YbAXe5IJ for ; Wed, 11 Feb 2009 08:35:17 -0800 (PST) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 02C4F3A6AAC for ; Wed, 11 Feb 2009 08:35:16 -0800 (PST) X-Trace: 75511248/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.112/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.112 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAIuMkkk+vGlw/2dsb2JhbACDRkWKCscYB4QTBoV+ X-IronPort-AV: E=Sophos;i="4.38,193,1233532800"; d="scan'208";a="75511248" X-IP-Direction: IN Received: from 1cust112.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.112]) by smtp.pipex.tiscali.co.uk with SMTP; 11 Feb 2009 16:35:18 +0000 Message-ID: <054d01c98c5e$32bc8580$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "'Dave Shield'" , References: <072f01c988b8$e9b20d90$0600a8c0@china.huawei.com> Date: Wed, 11 Feb 2009 16:23:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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] tsm pre11 - minor issues 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: , X-List-Received-Date: Wed, 11 Feb 2009 16:35:18 -0000 ----- Original Message ----- From: "David Harrington" To: "'Dave Shield'" ; Cc: Sent: Saturday, February 07, 2009 1:13 AM Subject: Re: [Isms] tsm pre11 - minor issues > > -----Original Message----- > > From: dave.shield@googlemail.com > > [mailto:dave.shield@googlemail.com] On Behalf Of Dave Shield > > Sent: Friday, February 06, 2009 6:03 AM > > To: j.schoenwaelder@jacobs-university.de; David Harrington > > Cc: isms@ietf.org > > Subject: Re: [Isms] tsm pre11 - minor issues > > > > 2009/1/23 Juergen Schoenwaelder > > : > > > On Thu, Jan 22, 2009 at 03:43:47PM -0500, David Harrington wrote: > > > > > >> I think I have covered all the WGLC comments > > > > > > Can the WG members please review the changes? > > > > A few minor nits which seem to be still present: > > > > Section 4.2 > > Step 1) explains the presence of a securityStateReference as > > being "(Response or Report message)" > > > > Step 2) simply states that no securityStateReference is present. > > It would probably be worth indicating the context here too. > > > > s/no securityStateReference/no securityStateReference > > (Request message)/ > > The RFC3411 architecture provides for extensibility, including the > types of messages. We should not list all the types of messages > because that would implicitly limit the extensibility. It is present > in step one at somebody's request to help clarify when a > securityStateReference can occur. But to add the list of message types > to both sides of the condition is unnecessary and limiting. If you > dislike the asymmetry, I can remove the (Response or Report message) > from step 1 to make them more symmetrical. > You might consider adding 'e.g. ' in front of 'Response or Report' to reduce any implication of inextensibility. Tom Petch > > > > Section 4.2, step 2) > > Add a comma into the list of assignments to > > tmStateReference cache fields. > > > > s/transportDomain tmTransportAddress/transportDomain, > > tmTransportAddress/ > > > done. > > > > > Section 5.2 > > Step 3) includes a (single) substep numbering "a." > > The equivalent text in section 4.2 has no such numbering. > > > > s/a./ / > > done. > > > > > > > Dave From ietfdbh@comcast.net Wed Feb 11 14:15:30 2009 Return-Path: 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 5C35C28C37F for ; Wed, 11 Feb 2009 14:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.097 X-Spam-Level: * X-Spam-Status: No, score=1.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, MIME_QP_LONG_LINE=1.396] 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 Jy7DhmzfXXHd for ; Wed, 11 Feb 2009 14:15:25 -0800 (PST) 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 79E6928C384 for ; Wed, 11 Feb 2009 14:14:35 -0800 (PST) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA06.westchester.pa.mail.comcast.net with comcast id ElX71b0040SCNGk56mEg6l; Wed, 11 Feb 2009 22:14:41 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA09.westchester.pa.mail.comcast.net with comcast id EmEg1b0010UQ6dC3VmEguy; Wed, 11 Feb 2009 22:14:40 +0000 From: "David Harrington" To: Date: Wed, 11 Feb 2009 17:14:39 -0500 Message-ID: <001801c98c96$220a4050$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0019_01C98C6C.39368240" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmMliF42syO24zkRmmcNESot/z3gA== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Isms] secshell-pre14b 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: , X-List-Received-Date: Wed, 11 Feb 2009 22:15:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C98C6C.39368240 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Here is another update. 1) the two ports have been updated, 2) the client/server EOP has been updated, 3) the user@ issue has been addressed. I have no outstanding issues to resolve, to my knowledge (except the 5378 issue) A few requested changes did not seem to be consensus, or seemed unnecessary, so I didn't make those changes. I think I responded to each of the non-changes on the mailing list. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0019_01C98C6C.39368240 Content-Type: text/plain; name="draft-ietf-isms-secshell-pre14b.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-secshell-pre14b.txt" =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Intended status: Standards Track J. Salowey=0A= Expires: August 15, 2009 Cisco Systems=0A= W. Hardaker=0A= Sparta, Inc.=0A= February 11, 2009=0A= =0A= =0A= Secure Shell Transport Model for SNMP=0A= draft-ietf-isms-secshell-14=0A= =0A= Status of This Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on August 15, 2009.=0A= =0A= Abstract=0A= =0A= This memo describes a Transport Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol (SSH).=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Secure Shell Transport Model for SNMP.=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 1]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 3=0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 2. The Secure Shell Protocol . . . . . . . . . . . . . . . . . . 6=0A= 3. How SSHTM Fits into the Transport Subsystem . . . . . . . . . 7=0A= 3.1. Security Capabilities of this Model . . . . . . . . . . . 8=0A= 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 3.1.2. Message Authentication . . . . . . . . . . . . . . . . 9=0A= 3.1.3. Authentication Protocol Support . . . . . . . . . . . 10=0A= 3.1.4. SSH Subsystem . . . . . . . . . . . . . . . . . . . . 10=0A= 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 11=0A= 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 11=0A= 4. Cached Information and References . . . . . . . . . . . . . . 12=0A= 4.1. Secure Shell Transport Model Cached Information . . . . . 12=0A= 4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . . . 12=0A= 4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . . . 13=0A= 4.1.3. Session State . . . . . . . . . . . . . . . . . . . . 13=0A= 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 13=0A= 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 14=0A= 5.2. Procedures for sending an Outgoing Message . . . . . . . . 15=0A= 5.3. Establishing a Session . . . . . . . . . . . . . . . . . . 16=0A= 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 18=0A= 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 19=0A= 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 19=0A= 6.2. Textual Conventions . . . . . . . . . . . . . . . . . . . 19=0A= 6.3. Relationship to Other MIB Modules . . . . . . . . . . . . 19=0A= 6.3.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 19=0A= 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 19=0A= 8. Operational Considerations . . . . . . . . . . . . . . . . . . 26=0A= 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27=0A= 9.1. Skipping Public Key Verification . . . . . . . . . . . . . 28=0A= 9.2. The 'none' MAC Algorithm . . . . . . . . . . . . . . . . . 28=0A= 9.3. Use with SNMPv1/v2c Messages . . . . . . . . . . . . . . . 28=0A= 9.4. MIB Module Security . . . . . . . . . . . . . . . . . . . 28=0A= 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29=0A= 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30=0A= 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30=0A= 12.1. Normative References . . . . . . . . . . . . . . . . . . . 30=0A= 12.2. Informative References . . . . . . . . . . . . . . . . . . 32=0A= Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 34=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 2]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= 1. Introduction=0A= =0A= This memo describes a Transport Model for the Simple Network=0A= Management Protocol, using the Secure Shell protocol (SSH) [RFC4251]=0A= within a transport subsystem [I-D.ietf-isms-tmsm]. The transport=0A= model specified in this memo is referred to as the Secure Shell=0A= Transport Model (SSHTM).=0A= =0A= This memo also defines a portion of the Management Information Base=0A= (MIB) for use with network management protocols in TCP/IP based=0A= internets. In particular it defines objects for monitoring and=0A= managing the Secure Shell Transport Model for SNMP.=0A= =0A= It is important to understand the SNMP architecture [RFC3411] and the=0A= terminology of the architecture to understand where the Transport=0A= Model described in this memo fits into the architecture and interacts=0A= with other subsystems within the architecture.=0A= =0A= 1.1. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= Managed objects are accessed via a virtual information store, termed=0A= the Management Information Base or MIB. MIB objects are generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in the=0A= Structure of Management Information (SMI). This memo specifies a MIB=0A= module that is compliant to the SMIv2, which is described in STD 58,=0A= RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580=0A= [RFC2580].=0A= =0A= 1.2. Conventions=0A= =0A= For consistency with SNMP-related specifications, this document=0A= favors terminology as defined in STD62 rather than favoring=0A= terminology that is consistent with non-SNMP specifications. This is=0A= consistent with the IESG decision to not require the SNMPv3=0A= terminology be modified to match the usage of other non-SNMP=0A= specifications when SNMPv3 was advanced to Full Standard.=0A= =0A= Authentication in this document typically refers to the English=0A= meaning of "serving to prove the authenticity of" the message, not=0A= data source authentication or peer identity authentication.=0A= =0A= The terms "manager" and "agent" are not used in this document,=0A= because in the RFC 3411 architecture [RFC3411], all SNMP entities=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 3]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= have the capability of acting in either manager or agent or in both=0A= roles depending on the SNMP application types supported in the=0A= implementation. Where distinction is required, the application names=0A= of Command Generator, Command Responder, Notification Originator,=0A= Notification Receiver, and Proxy Forwarder are used. See "SNMP=0A= Applications" [RFC3413] for further information.=0A= =0A= Throughout this document, the terms "client" and "server" are used to=0A= refer to the two ends of the SSH transport connection. The client=0A= actively opens the SSH connection, and the server passively listens=0A= for the incoming SSH connection. Either SNMP entity may act as=0A= client or as server, as discussed further below.=0A= =0A= The User-Based Security Model (USM) [RFC3414] is a mandatory-to-=0A= implement Security Model in STD 62. While SSH and USM frequently=0A= refer to a user, the terminology preferred in RFC3411 [RFC3411] and=0A= in this memo is "principal". A principal is the "who" on whose=0A= behalf services are provided or processing takes place. A principal=0A= can be, among other things, an individual acting in a particular=0A= role; a set of individuals, with each acting in a particular role; an=0A= application or a set of applications, or a combination of these=0A= within an administrative domain.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= Sections requiring further editing are identified by [todo] markers=0A= in the text. Points requiring further WG research and discussion are=0A= identified by [discuss] markers in the text.=0A= =0A= Note to RFC Editor - if the previous paragraph and this note have not=0A= been removed, please send the document back to the editor to remove=0A= this.=0A= =0A= 1.3. Modularity=0A= =0A= The reader is expected to have read and understood the description of=0A= the SNMP architecture, as defined in [RFC3411], and the Transport=0A= Subsystem architecture extension specified in "Transport Subsystem=0A= for the Simple Network Management Protocol" [I-D.ietf-isms-tmsm].=0A= =0A= This memo describes the Secure Shell Transport Model for SNMP, a=0A= specific SNMP transport model to be used within the SNMP transport=0A= subsystem to provide authentication, encryption, and integrity=0A= checking of SNMP messages.=0A= =0A= In keeping with the RFC 3411 design decision to use self-contained=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 4]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= documents, this document defines the elements of procedure and=0A= associated MIB module objects which are needed for processing the=0A= Secure Shell Transport Model for SNMP.=0A= =0A= This modularity of specification is not meant to be interpreted as=0A= imposing any specific requirements on implementation.=0A= =0A= 1.4. Motivation=0A= =0A= Version 3 of the Simple Network Management Protocol (SNMPv3) added=0A= security to the protocol. The User-based Security Model (USM)=0A= [RFC3414] was designed to be independent of other existing security=0A= infrastructures, to ensure it could function when third party=0A= authentication services were not available, such as in a broken=0A= network. As a result, USM utilizes a separate user and key=0A= management infrastructure. Operators have reported that deploying=0A= another user and key management infrastructure in order to use SNMPv3=0A= is a reason for not deploying SNMPv3.=0A= =0A= This memo describes a transport model that will make use of the=0A= existing and commonly deployed Secure Shell security infrastructure.=0A= This transport model is designed to meet the security and operational=0A= needs of network administrators, maximize usability in operational=0A= environments to achieve high deployment success and at the same time=0A= minimize implementation and deployment costs to minimize deployment=0A= time.=0A= =0A= This document addresses the requirement for the SSH client to=0A= authenticate the SSH server, for the SSH server to authenticate the=0A= SSH client, and describes how SNMP can make use of the authenticated=0A= identities in authorization policies for data access, in a manner=0A= that is independent of any specific access control model.=0A= =0A= This document addresses the requirement to utilize client=0A= authentication and key exchange methods which support different=0A= security infrastructures and provide different security properties.=0A= This document describes how to use client authentication as described=0A= in "SSH Authentication Protocol" [RFC4252]. The SSH Transport Model=0A= should work with any of the ssh-userauth methods including the=0A= "publickey", "password", "hostbased", "none", "keyboard-interactive",=0A= "gssapi-with-mic", ."gssapi-keyex", "gssapi", and "external-keyx"=0A= (see http://www.iana.org/assignments/ssh-parameters). The use of the=0A= "none" authentication method is NOT RECOMMENDED, as described in=0A= Security Considerations. Local accounts may be supported through the=0A= use of the publickey, hostbased or password methods. The password=0A= method allows for integration with deployed password infrastructure=0A= such as AAA servers using the RADIUS protocol [RFC2865]. The SSH=0A= Transport Model SHOULD be able to take advantage of future defined=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 5]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= ssh-userauth methods, such as those that might make use of X.509=0A= certificate credentials.=0A= =0A= It is desirable to use mechanisms that could unify the approach for=0A= administrative security for SNMPv3 and Command Line interfaces (CLI)=0A= and other management interfaces. The use of security services=0A= provided by Secure Shell is the approach commonly used for the CLI,=0A= and is the approach being adopted for use with NETCONF [RFC4742].=0A= This memo describes a method for invoking and running the SNMP=0A= protocol within a Secure Shell (SSH) session as an SSH subsystem.=0A= =0A= This memo describes how SNMP can be used within a Secure Shell (SSH)=0A= session, using the SSH connection protocol [RFC4254] over the SSH=0A= transport protocol, using SSH user-auth [RFC4252] for authentication.=0A= =0A= There are a number of challenges to be addressed to map Secure Shell=0A= authentication method parameters into the SNMP architecture so that=0A= SNMP continues to work without any surprises. These are discussed in=0A= detail below.=0A= =0A= 1.5. Constraints=0A= =0A= The design of this SNMP Transport Model is influenced by the=0A= following constraints:=0A= =0A= 1. In times of network stress, the transport protocol and its=0A= underlying security mechanisms SHOULD NOT depend upon the ready=0A= availability of other network services (e.g., Network Time=0A= Protocol (NTP) or AAA protocols).=0A= =0A= 2. When the network is not under stress, the transport model and its=0A= underlying security mechanisms MAY depend upon the ready=0A= availability of other network services.=0A= =0A= 3. It may not be possible for the transport model to determine when=0A= the network is under stress.=0A= =0A= 4. A transport model should require no changes to the SNMP=0A= architecture.=0A= =0A= 5. A transport model should require no changes to the underlying=0A= protocol.=0A= =0A= 2. The Secure Shell Protocol=0A= =0A= SSH is a protocol for secure remote login and other secure network=0A= services over an insecure network. It consists of three major=0A= protocol components, and add-on methods for user authentication:=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 6]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= o The Transport Layer Protocol [RFC4253] provides server=0A= authentication, and message confidentiality and integrity. It may=0A= optionally also provide compression. The transport layer will=0A= typically be run over a TCP/IP connection, but might also be used=0A= on top of any other reliable data stream.=0A= =0A= o The User Authentication Protocol [RFC4252] authenticates the=0A= client-side principal to the server. It runs over the transport=0A= layer protocol.=0A= =0A= o The Connection Protocol [RFC4254] multiplexes the encrypted tunnel=0A= into several logical channels. It runs over the transport after=0A= successfully authenticating the principal.=0A= =0A= o Generic Message Exchange Authentication [RFC4256] is a general=0A= purpose authentication method for the SSH protocol, suitable for=0A= interactive authentications where the authentication data should=0A= be entered via a keyboard=0A= =0A= o Generic Security Service Application Program Interface (GSS-API)=0A= Authentication and Key Exchange for the Secure Shell (SSH)=0A= Protocol [RFC4462] describes methods for using the GSS-API for=0A= authentication and key exchange in SSH. It defines an SSH user=0A= authentication method that uses a specified GSS-API mechanism to=0A= authenticate a user, and a family of SSH key exchange methods that=0A= use GSS-API to authenticate a Diffie-Hellman key exchange.=0A= =0A= The client sends a service request once a secure transport layer=0A= connection has been established. A second service request is sent=0A= after client authentication is complete. This allows new protocols=0A= to be defined and coexist with the protocols listed above.=0A= =0A= The connection protocol provides channels that can be used for a wide=0A= range of purposes. Standard methods are provided for setting up=0A= secure interactive shell sessions and for forwarding ("tunneling")=0A= arbitrary TCP/IP ports and X11 connections.=0A= =0A= 3. How SSHTM Fits into the Transport Subsystem=0A= =0A= A transport model is a component of the Transport Subsystem=0A= [I-D.ietf-isms-tmsm] within the SNMP architecture. The SSH Transport=0A= Model thus fits between the underlying SSH transport layer and the=0A= message dispatcher [RFC3411].=0A= =0A= The SSH Transport Model will establish a channel between itself and=0A= the SSH Transport Model of another SNMP engine. The sending=0A= transport model passes unencrypted messages from the dispatcher to=0A= SSH to be encrypted, and the receiving transport model accepts=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 7]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= decrypted incoming messages from SSH and passes them to the=0A= dispatcher.=0A= =0A= After an SSH Transport model channel is established, then SNMP=0A= messages can conceptually be sent through the channel from one SNMP=0A= message dispatcher to another SNMP message dispatcher. Multiple SNMP=0A= messages MAY be passed through the same channel.=0A= =0A= The SSH Transport Model of an SNMP engine will perform the=0A= translation between SSH-specific security parameters and SNMP-=0A= specific, model-independent parameters.=0A= =0A= 3.1. Security Capabilities of this Model=0A= =0A= 3.1.1. Threats=0A= =0A= The Secure Shell Transport Model provides protection against the=0A= threats identified by the RFC 3411 architecture [RFC3411]:=0A= =0A= 1. Modification of Information - SSH provides for verification that=0A= the contents of each message has not been modified during its=0A= transmission through the network, by digitally signing each SSH=0A= packet.=0A= =0A= 2. Masquerade - SSH provides for verification of the identity of the=0A= SSH server and the identity of the SSH client.=0A= =0A= SSH provides for verification of the identity of the SSH server=0A= through the SSH Transport Protocol server authentication=0A= [RFC4253]. This allows an operator or management station to=0A= ensure the authenticity of the SNMP engine that provides MIB=0A= data.=0A= =0A= SSH provides a number of mechanisms for verification of the=0A= identity of the SSH client-side principal, using the Secure Shell=0A= Authentication Protocol [RFC4252]. These include public key,=0A= password and host-based mechanisms. This allows the SNMP access=0A= control subsystem to ensure that only authorized principals have=0A= access to potentially sensitive data.=0A= =0A= Verification of client's principal identity is important for use=0A= with the SNMP access control subsystem, to ensure that only=0A= authorized principals have access to potentially sensitive data.=0A= The SSH user identity is provided to the transport model, so it=0A= can be used to map to an SNMP model-independent securityName for=0A= use with SNMP access control and notification configuration.=0A= (The identity may undergo various transforms before it maps to=0A= the securityName.)=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 8]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= 3. Message Stream Modification - SSH protects against malicious re-=0A= ordering or replaying of messages within a single SSH session by=0A= using sequence numbers and integrity checks. SSH protects=0A= against replay of messages across SSH sessions by ensuring that=0A= the cryptographic keys used for encryption and integrity checks=0A= are generated afresh for each session.=0A= =0A= 4. Disclosure - SSH provides protection against the disclosure of=0A= information to unauthorized recipients or eavesdroppers by=0A= allowing for encryption of all traffic between SNMP engines.=0A= =0A= 3.1.2. Message Authentication=0A= =0A= The RFC 3411 architecture recognizes three levels of security:=0A= =0A= - without authentication and without privacy (noAuthNoPriv)=0A= =0A= - with authentication but without privacy (authNoPriv)=0A= =0A= - with authentication and with privacy (authPriv)=0A= =0A= The Secure Shell protocol provides support for encryption and data=0A= integrity. While it is technically possible to support no=0A= authentication and no encryption in SSH it is NOT RECOMMENDED by=0A= [RFC4253].=0A= =0A= The SSH Transport Model determines from SSH the identity of the=0A= authenticated principal, and the type and address associated with an=0A= incoming message, and provides this information to SSH for an=0A= outgoing message. The transport layer algorithms used to provide=0A= authentication, data integrity and encryption SHOULD NOT be exposed=0A= to the SSH Transport Model layer. The SNMPv3 WG deliberately avoided=0A= this and settled for an assertion by the security model that the=0A= requirements of securityLevel were met The SSH Transport Model has no=0A= mechanisms by which it can test whether an underlying SSH connection=0A= provides auth or priv, so the SSH Transport Model trusts that the=0A= underlying SSH connection has been properly configured to support=0A= authPriv security characteristics.=0A= =0A= An SSH Transport Model-compliant implementation MUST use an SSH=0A= connection that provides authentication, data integrity and=0A= encryption that meets the highest level of SNMP security (authPriv).=0A= Outgoing messages specified with a securityLevel of noAuthNoPriv or=0A= authNoPriv, are actually sent by the SSH Transport Model with=0A= authPriv-level protection.=0A= =0A= The security protocols used in the Secure Shell Authentication=0A= Protocol [RFC4252] and the Secure Shell Transport Layer Protocol=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 9]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= [RFC4253] are considered acceptably secure at the time of writing.=0A= However, the procedures allow for new authentication and privacy=0A= methods to be specified at a future time if the need arises.=0A= =0A= 3.1.3. Authentication Protocol Support=0A= =0A= The SSH Transport Model should support any server or client=0A= authentication mechanism supported by SSH. This includes the three=0A= authentication methods described in the SSH Authentication Protocol=0A= document [RFC4252] - publickey, password, and host-based - and=0A= keyboard interactive and others.=0A= =0A= The password authentication mechanism allows for integration with=0A= deployed password based infrastructure. It is possible to hand a=0A= password to a service such as RADIUS [RFC2865] or Diameter [RFC3588]=0A= for validation. The validation could be done using the user-name and=0A= user-password attributes. It is also possible to use a different=0A= password validation protocol such as CHAP [RFC1994] or digest=0A= authentication [RFC5090] to integrate with RADIUS or Diameter. At=0A= some point in the processing, these mechanisms require the password=0A= be made available as clear text on the device that is authenticating=0A= the password which might introduce threats to the authentication=0A= infrastructure.=0A= =0A= GSSKeyex [RFC4462] provides a framework for the addition of client=0A= authentication mechanisms which support different security=0A= infrastructures and provide different security properties.=0A= Additional authentication mechanisms, such as one that supports X.509=0A= certificates, may be added to SSH in the future.=0A= =0A= 3.1.4. SSH Subsystem=0A= =0A= This document describes the use of an SSH subsystem for SNMP to make=0A= SNMP usage distinct from other usages.=0A= =0A= An SSH subsystem of type "snmp" is opened by the SSH Transport Model=0A= during the elements of procedure for an outgoing SNMP message. Since=0A= the sender of a message initiates the creation of an SSH session if=0A= needed, the SSH session will already exist for an incoming message or=0A= the incoming message would never reach the SSH Transport Model.=0A= =0A= Implementations MAY choose to instantiate SSH sessions in=0A= anticipation of outgoing messages. This approach might be useful to=0A= ensure that an SSH session to a given target can be established=0A= before it becomes important to send a message over the SSH session.=0A= Of course, there is no guarantee that a pre-established session will=0A= still be valid when needed.=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 10]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= SSH sessions are uniquely identified within the SSH Transport Model=0A= by the combination of tmTransportAddress and tmSecurityName=0A= associated with each session.=0A= =0A= 3.2. Security Parameter Passing=0A= =0A= For incoming messages, SSH-specific security parameters are=0A= translated by the transport model into security parameters=0A= independent of the transport and security models. The transport=0A= model accepts messages from the SSH subsystem, and records the=0A= transport-related and SSH-security-related information, including the=0A= authenticated identity, in a cache referenced by tmStateReference,=0A= and passes the WholeMsg and the tmStateReference to the dispatcher=0A= using the receiveMessage() ASI (Application Service Interface).=0A= =0A= For outgoing messages, the transport model takes input provided by=0A= the dispatcher in the sendMessage() ASI. The SSH Transport Model=0A= converts that information into suitable security parameters for SSH,=0A= establishes sessions as needed, and passes messages to the SSH=0A= subsystem for sending.=0A= =0A= 3.3. Notifications and Proxy=0A= =0A= SSH connections may be initiated by command generators or by=0A= notification originators. Command generators are frequently operated=0A= by a human, but notification originators are usually unmanned=0A= automated processes. As a result, it may be necessary to provision=0A= authentication credentials on the SNMP engine containing the=0A= notification originator, or use a third party key provider such as=0A= Kerberos, so the engine can successfully authenticate to an engine=0A= containing a notification receiver.=0A= =0A= The targets to whom notifications or proxy requests should be sent is=0A= typically determined and configured by a network administrator. The=0A= SNMP-TARGET-MIB module [RFC3413] contains objects for defining=0A= management targets, including transport domains and addresses and=0A= security parameters, for applications such as notification generators=0A= and proxy forwarders.=0A= =0A= For the SSH Transport Model, transport type and address are=0A= configured in the snmpTargetAddrTable, and the securityName, and=0A= securityLevel parameters are configured in the snmpTargetParamsTable.=0A= The default approach is for an administrator to statically=0A= preconfigure this information to identify the targets authorized to=0A= receive notifications or perform proxy.=0A= =0A= These MIB modules may be configured using SNMP or other=0A= implementation-dependent mechanisms, such as CLI scripting or loading=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 11]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= a configuration file. It may be necessary to provide additional=0A= implementation-specific configuration of SSH parameters.=0A= =0A= 4. Cached Information and References=0A= =0A= When performing SNMP processing, there are two levels of state=0A= information that may need to be retained: the immediate state linking=0A= a request-response pair, and potentially longer-term state relating=0A= to transport and security. "Transport Subsystem for the Simple=0A= Network Management Protocol" [I-D.ietf-isms-tmsm] defines general=0A= requirements for caches and references.=0A= =0A= This document defines additional cache requirements related to the=0A= Secure Shell Transport Model.=0A= =0A= 4.1. Secure Shell Transport Model Cached Information=0A= =0A= The Secure Shell Transport Model has specific responsibilities=0A= regarding the cached information. See the Elements of Procedure in=0A= Section 5 for detailed processing instructions on the use of the=0A= tmStateReference fields by the SSH Transport Model.=0A= =0A= 4.1.1. tmSecurityName=0A= =0A= The tmSecurityName MUST be a human-readable name (in snmpAdminString=0A= format) representing the identity that has been set according to the=0A= procedures in Section 5.=0A= =0A= On the SSH server side of a connection:=0A= =0A= The tmSecurityName SHOULD be the value of the user name field of=0A= the SSH_MSG_USERAUTH_REQUEST message for which a=0A= SSH_MSG_USERAUTH_SUCCESS has been sent. How the SSH user name is=0A= extracted from the SSH layer is implementation-dependent.=0A= =0A= The SSH protocol is not always clear on whether the user name=0A= field must be filled in, so for some implementations, such as=0A= those using GSSAPI authentication, it may be necessary to use a=0A= mapping algorithm to transform an SSH identity to a=0A= tmSecurityName, or to transform a tmSecurityName to an SSH=0A= identity.=0A= =0A= In other cases the user name may not be verified by the server, so=0A= for these implementations, it may be necessary to obtain the user=0A= name from other credentials exchanged during the SSH exchange.=0A= =0A= On the SSH client side of a connection:=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 12]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= The tmSecurityName is presented to the SSH Transport Model by the=0A= application (possibly because of configuration specified in the=0A= SNMP-TARGET-MIB).=0A= =0A= The securityName MAY be derived from the tmSecurityName by a security=0A= model, and MAY be used to configure notifications and access=0A= controls. Transport models SHOULD generate a predictable=0A= tmSecurityName.=0A= =0A= 4.1.2. tmSessionID=0A= =0A= The tmSessionID MUST be recorded per message at the time of receipt.=0A= When tmSameSecurity is set, the recorded tmSessionID can be used to=0A= determine whether the SSH session available for sending a=0A= corresponding outgoing message is the same SSH session as was used=0A= when receiving the incoming message (e.g., a response to a request).=0A= =0A= 4.1.3. Session State=0A= =0A= The per-session state that is referenced by tmStateReference may be=0A= saved across multiple messages in a Local Configuration Datastore.=0A= Additional session/connection state information might also be stored=0A= in a Local Configuration Datastore.=0A= =0A= 5. Elements of Procedure=0A= =0A= Abstract service interfaces have been defined by [RFC3411] and=0A= further augmented by [I-D.ietf-isms-tmsm] to describe the conceptual=0A= data flows between the various subsystems within an SNMP entity. The=0A= Secure Shell Transport Model uses some of these conceptual data flows=0A= when communicating between subsystems.=0A= =0A= To simplify the elements of procedure, the release of state=0A= information is not always explicitly specified. As a general rule,=0A= if state information is available when a message gets discarded, the=0A= message-state information should also be released, and if state=0A= information is available when a session is closed, the session state=0A= information should also be released.=0A= =0A= An error indication in statusInformation will typically include the=0A= OID and value for an incremented error counter. This may be=0A= accompanied by the requested securityLevel, and the tmStateReference.=0A= Per-message context information is not accessible to Transport=0A= Models, so for the returned counter OID and value, contextEngine=0A= would be set to the local value of snmpEngineID, and contextName to=0A= the default context for error counters.=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 13]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= 5.1. Procedures for an Incoming Message=0A= =0A= 1. The SSH Transport Model queries the SSH engine, in an=0A= implementation-dependent manner, to determine the=0A= transportAddress, the principal name authenticated by SSH, and a=0A= session identifier. The transportAddress must be consistent=0A= during the life of a SSH session.=0A= =0A= By default on the server side of a SSH connection, the principal=0A= name is the value of the user name field of the=0A= SSH_MSG_USERAUTH_REQUEST message for which a=0A= SSH_MSG_USERAUTH_SUCCESS has been sent. How this name is=0A= extracted from the SSH environment is implementation-dependent.=0A= =0A= 2. Create a tmStateReference cache for subsequent reference to the=0A= information.=0A= =0A= tmTransportDomain =3D snmpSSHDomain=0A= =0A= tmTransportAddress =3D the address the message originated from,=0A= determined in an implementation-dependent way from SSH.=0A= =0A= tmTransportSecurityLevel =3D "authPriv" (authentication and=0A= confidentiality MUST be used to comply with this transport=0A= model.)=0A= =0A= tmSecurityName =3D the ssh principal name received by the SSH=0A= server or sent from a SSH client.=0A= =0A= tmSessionID =3D an implementation-dependent value that can be=0A= used to detect when a session has closed and been replaced by=0A= another session. The value in tmStateReference should=0A= identify the session over which the message was received.=0A= =0A= Prepare the transport parameters for the ASI:=0A= =0A= transportDomain =3D snmpSSHDomain=0A= =0A= transportAddress =3D the address used to open the SSH session that=0A= the message originated from, determined in an implementation-=0A= dependent manner.=0A= =0A= (If the session was not opened locally with a user@foo.com=0A= formatted tmTransportAddress, then the tmTransportAddress and=0A= transportAddress for the incoming message will always match. If=0A= the session is a client session, and openSession used a=0A= tmTransportAddress of the "user@foo.com" format, the=0A= transportAddress passed in the receiveMessage ASI MUST match the=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 14]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= "user@foo.com" tmTransportAddress used to open the session; this=0A= will be different than the "foo.com" formatted address reported by=0A= SSH for the incoming message.)=0A= =0A= Then the Transport model passes the message to the Dispatcher using=0A= the following ASI:=0A= =0A= statusInformation =3D=0A= receiveMessage(=0A= IN transportDomain -- snmpSSHDomain=0A= IN transportAddress -- address for the received message=0A= IN wholeMessage -- the whole SNMP message from SSH=0A= IN wholeMessageLength -- the length of the SNMP message=0A= IN tmStateReference -- (NEW) transport info=0A= )=0A= =0A= 5.2. Procedures for sending an Outgoing Message=0A= =0A= The Dispatcher passes the information to the Transport Model using=0A= the ASI defined in the transport subsystem:=0A= =0A= =0A= statusInformation =3D=0A= sendMessage(=0A= IN destTransportDomain -- transport domain to be used=0A= IN destTransportAddress -- transport address to be used=0A= IN outgoingMessage -- the message to send=0A= IN outgoingMessageLength -- its length=0A= IN tmStateReference -- (NEW) transport info=0A= )=0A= =0A= The SSH Transport Model performs the following tasks.=0A= =0A= 1. If tmStateReference does not refer to a cache containing values=0A= for tmTransportDomain, tmTransportAddress, tmSecurityName,=0A= tmRequestedSecurityLevel, and tmSameSecurity, then increment the=0A= sshtmSessionInvalidCaches counter, discard the message and return=0A= the error indication in the statusInformation. Processing of=0A= this message stops.=0A= =0A= 2. Extract the tmTransportDomain, tmTransportAddress,=0A= tmSecurityName, tmRequestedSecurityLevel, tmSameSecurity, and=0A= tmSessionID from the tmStateReference.=0A= =0A= 3. If tmSameSecurity is true and there is no existing session with=0A= the same sessionID as tmSessionID, then increment the=0A= sshtmSessionNoAvailableSessions counter, discard the message and=0A= return the error indication in the statusInformation. Processing=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 15]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= of this message stops.=0A= =0A= 4. If there is no existing session corresponding to the=0A= tmTransportAddress and tmSecurityName, then call openSession()=0A= with the tmStateReference as a parameter.=0A= =0A= 1. If openSession fails, then discard the message, release=0A= tmStateReference and pass the error indication returned by=0A= openSession back to the calling module. Processing stops for=0A= this message.=0A= =0A= 2. If openSession succeeds, then record the destTransportDomain=0A= and destTransportAddress and tmSessionID, in an=0A= implementation-dependent manner. This may be needed when=0A= processing an incoming message.=0A= =0A= 5. Pass the wholeMessage to SSH for encapsulation as data in an SSH=0A= message over the specified SSH session. Any necessary additional=0A= SSH-specific parameters should be provided in an implementation-=0A= dependent manner.=0A= =0A= 5.3. Establishing a Session=0A= =0A= The Secure Shell Transport Model provides the following abstract=0A= service interface (ASI) to describe the data passed between the SSH=0A= Transport Model and the SSH service. It is an implementation=0A= decision how such data is passed.=0A= =0A= statusInformation =3D=0A= openSession(=0A= IN tmStateReference -- transport information to be used=0A= OUT tmStateReference -- transport information to be used=0A= IN maxMessageSize -- of the sending SNMP entity=0A= )=0A= =0A= =0A= The following describes the procedure to follow to establish a=0A= session between a client and server to run SNMP over SSH. This=0A= process is used by any SNMP engine establishing a session for=0A= subsequent use.=0A= =0A= This will be done automatically for an SNMP application that=0A= initiates a transaction, such as a Command Generator or a=0A= Notification Originator or a Proxy Forwarder.=0A= =0A= 1. Increment the sshtmSessionOpens counter.=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 16]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= 2. Using tmTransportAddress, the client will establish an SSH=0A= transport connection using the SSH transport protocol,=0A= authenticate the server, and exchange keys for message integrity=0A= and encryption. The transportAddress associated with a session=0A= MUST remain constant during the lifetime of the SSH session.=0A= Implementations may need to cache the transportAddress passed to=0A= the openSession API for later use when performing incoming=0A= message processing (see section Section 5.1).=0A= =0A= 1. To authenticate the server, the client usually stores=0A= (tmTransportAddress, server host public key) pairs in an=0A= implementation-dependent manner.=0A= =0A= 2. The other parameters of the transport connection are provided=0A= in an implementation-dependent manner.=0A= =0A= 3. If the attempt to establish a connection is unsuccessful, or=0A= server authentication fails, then sshtmSessionOpenErrors is=0A= incremented, an openSession error indication is returned, and=0A= openSession processing stops.=0A= =0A= 3. The client will then invoke an SSH authentication service to=0A= authenticate the principal, such as that described in the SSH=0A= authentication protocol [RFC4252].=0A= =0A= 1. If the tmTransportAddress field contains a user-name followed=0A= by an '@' character (ASCII 0x40), that user-name string that=0A= should be presented to the ssh server as the "user name" for=0A= user authentication purposes. If there is no user-name in=0A= the tmTransportAddress then the tmSecurityName should be used=0A= as the user-name.=0A= =0A= 2. The credentials used to authenticate the SSH principal are=0A= determined in an implementation-dependent manner.=0A= =0A= 3. In an implementation-specific manner, invoke the SSH user=0A= authentication service using the calculated user-name.=0A= =0A= 4. If the user authentication is unsuccessful, then the=0A= transport connection is closed, the=0A= sshtmSessionUserAuthFailures counter is incremented, an error=0A= indication is returned to the calling module, and processing=0A= stops for this message.=0A= =0A= 4. The client should invoke the "ssh-connection" service (also known=0A= as the SSH connection protocol [RFC4254]), and request a channel=0A= of type "session". If unsuccessful, the transport connection is=0A= closed, the sshtmSessionChannelOpenFailures counter is=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 17]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= incremented, an error indication is returned to the calling=0A= module, and processing stops for this message.=0A= =0A= 5. The client invokes "snmp" as an SSH subsystem, as indicated in=0A= the "subsystem" parameter. If unsuccessful, the transport=0A= connection is closed, the sshtmSessionUnavailableSubsystems=0A= counter is incremented, an error indication is returned to the=0A= calling module, and processing stops for this message.=0A= =0A= In order to allow SNMP traffic to be easily identified and=0A= filtered by firewalls and other network devices, servers=0A= associated with SNMP entities using the Secure Shell Transport=0A= Model MUST default to providing access to the "snmp" SSH=0A= subsystem if the SSH session is established using the IANA-=0A= assigned TCP ports (YYY and ZZZ). Servers SHOULD be configurable=0A= to allow access to the SNMP SSH subsystem over other ports.=0A= =0A= 6. Set tmSessionID in the tmStateReference cache to an=0A= implementation-dependent value to identify the session.=0A= =0A= 5.4. Closing a Session=0A= =0A= The Secure Shell Transport Model provides the following ASI to close=0A= a session:=0A= =0A= statusInformation =3D=0A= closeSession(=0A= IN tmSessionID -- transport address to be used=0A= )=0A= =0A= =0A= =0A= The following describes the procedure to follow to close a session=0A= between a client and server . This process is followed by any SNMP=0A= engine to close an SSH session. It is implementation-dependent when=0A= a session should be closed. The calling code should release the=0A= associated tmStateReference.=0A= =0A= 1. Increment the sshtmSessionCloses counter.=0A= =0A= 2. If there is no session corresponding to tmSessionID, then=0A= closeSession processing is completed.=0A= =0A= 3. Have SSH close the session associated with tmSessionID.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 18]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= 6. MIB Module Overview=0A= =0A= This MIB module provides management of the Secure Shell Transport=0A= Model. It defines an OID to identify the SNMP-over-SSH transport=0A= domain, a textual convention for SSH Addresses and several statistics=0A= counters.=0A= =0A= 6.1. Structure of the MIB Module=0A= =0A= Objects in this MIB module are arranged into subtrees. Each subtree=0A= is organized as a set of related objects. The overall structure and=0A= assignment of objects to their subtrees, and the intended purpose of=0A= each subtree, is shown below.=0A= =0A= 6.2. Textual Conventions=0A= =0A= Generic and Common Textual Conventions used in this document can be=0A= found summarized at http://www.ops.ietf.org/mib-common-tcs.html=0A= =0A= 6.3. Relationship to Other MIB Modules=0A= =0A= Some management objects defined in other MIB modules are applicable=0A= to an entity implementing the SSH Transport Model. In particular, it=0A= is assumed that an entity implementing the SSHTM-MIB will implement=0A= the SNMPv2-MIB [RFC3418], and the SNMP-FRAMEWORK-MIB [RFC3411]. It=0A= is expected that an entity implementing this MIB will also support=0A= the Transport Security Model=0A= [I-D.ietf-isms-transport-security-model], and therefore implement the=0A= SNMP-TSM-MIB.=0A= =0A= This MIB module is for monitoring SSH Transport Model information.=0A= =0A= 6.3.1. MIB Modules Required for IMPORTS=0A= =0A= The following MIB module imports items from [RFC2578], [RFC2579],=0A= [RFC2580].=0A= =0A= This MIB module also references [RFC3490] and [RFC3986]=0A= =0A= 7. MIB Module Definition=0A= =0A= =0A= SSHTM-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY, OBJECT-TYPE,=0A= OBJECT-IDENTITY, mib-2, snmpDomains,=0A= Counter32=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 19]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= FROM SNMPv2-SMI=0A= TEXTUAL-CONVENTION=0A= FROM SNMPv2-TC=0A= MODULE-COMPLIANCE, OBJECT-GROUP=0A= FROM SNMPv2-CONF=0A= ;=0A= =0A= sshtmMIB MODULE-IDENTITY=0A= LAST-UPDATED "200810130000Z"=0A= ORGANIZATION "ISMS Working Group"=0A= CONTACT-INFO "WG-EMail: isms@lists.ietf.org=0A= Subscribe: isms-request@lists.ietf.org=0A= =0A= Chairs:=0A= Juergen Quittek=0A= NEC Europe Ltd.=0A= Network Laboratories=0A= Kurfuersten-Anlage 36=0A= 69115 Heidelberg=0A= Germany=0A= +49 6221 90511-15=0A= quittek@netlab.nec.de=0A= =0A= Juergen Schoenwaelder=0A= Jacobs University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= +49 421 200-3587=0A= j.schoenwaelder@iu-bremen.de=0A= =0A= Co-editors:=0A= David Harrington=0A= Huawei Technologies USA=0A= 1700 Alma Drive=0A= Plano Texas 75075=0A= USA=0A= +1 603-436-8634=0A= ietfdbh@comcast.net=0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= jsalowey@cisco.com=0A= =0A= Wes Hardaker=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 20]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Sparta, Inc.=0A= P.O. Box 382=0A= Davis, CA 95617=0A= USA=0A= +1 530 792 1913=0A= ietf@hardakers.net=0A= "=0A= DESCRIPTION "The Secure Shell Transport Model MIB=0A= =0A= Copyright (C) The IETF Trust (2008). This=0A= version of this MIB module is part of RFC XXXX;=0A= see the RFC itself for full legal notices.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= REVISION "200810130000Z"=0A= DESCRIPTION "The initial version, published in RFC XXXX.=0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= "=0A= =0A= ::=3D { mib-2 xxxx }=0A= -- RFC Ed.: replace xxxx with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- ---------------------------------------------------------- --=0A= -- subtrees in the SNMP-SSH-TM-MIB=0A= -- ---------------------------------------------------------- --=0A= =0A= sshtmNotifications OBJECT IDENTIFIER ::=3D { sshtmMIB 0 }=0A= sshtmObjects OBJECT IDENTIFIER ::=3D { sshtmMIB 1 }=0A= sshtmConformance OBJECT IDENTIFIER ::=3D { sshtmMIB 2 }=0A= =0A= -- -------------------------------------------------------------=0A= -- Objects=0A= -- -------------------------------------------------------------=0A= =0A= snmpSSHDomain OBJECT-IDENTITY=0A= STATUS current=0A= DESCRIPTION=0A= "The SNMP over SSH transport domain. The corresponding transport=0A= address is of type SnmpSSHAddress.=0A= =0A= When an SNMP entity uses the snmpSSHDomain transport=0A= model, it must be capable of accepting messages up to=0A= and including 8192 octets in size. Implementation of=0A= larger values is encouraged whenever possible.=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 21]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= The securityName prefix to be associated with the=0A= snmpSSHDomain is 'ssh'. This prefix may be used by security=0A= models or other components to identify what secure transport=0A= infrastructure authenticated a securityName."=0A= ::=3D { snmpDomains yy }=0A= =0A= -- RFC Ed.: Please replace the I-D reference with a proper one once it=0A= -- has been published.=0A= =0A= -- RFC Ed.: replace yy with IANA-assigned number and=0A= -- remove this note=0A= =0A= -- RFC Ed.: replace 'ssh' with the actual IANA assigned prefix string=0A= -- if 'ssh' is not assigned to this document.=0A= =0A= SnmpSSHAddress ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "1a"=0A= STATUS current=0A= DESCRIPTION=0A= "Represents either a hostname or IP address, along with a port=0A= number and an optional username.=0A= =0A= The beginning of the address specification may contain a=0A= username followed by an '@' (ASCII character 0x40). This=0A= portion of the address will indicate the user name that should=0A= be used when authenticating to an SSH server. If missing, the=0A= SNMP securityName should be used. After the optional user name=0A= field and '@' character comes the hostname or IP address.=0A= =0A= The hostname must be encoded in ASCII, as specified in=0A= RFC3490 (Internationalizing Domain Names in Applications)=0A= followed by a colon ':' (ASCII character 0x3A) and a=0A= decimal port number in ASCII. The name SHOULD be fully=0A= qualified whenever possible.=0A= =0A= An IPv4 address must be in dotted decimal format followed=0A= by a colon ':' (ASCII character 0x3A) and a decimal port=0A= number in ASCII.=0A= =0A= An IPv6 address must be in colon separated format, surrounded=0A= by square brackets ('[' ASCII character 0x5B and ']' ASCII=0A= character 0x5D), followed by a colon ':' (ASCII character=0A= 0x3A) and a decimal port number in ASCII.=0A= =0A= Values of this textual convention might not be directly useable=0A= as transport-layer addressing information, and may require=0A= runtime resolution. As such, applications that write them=0A= must be prepared for handling errors if such values are=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 22]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= not supported, or cannot be resolved (if resolution occurs=0A= at the time of the management operation).=0A= =0A= The DESCRIPTION clause of TransportAddress objects that may=0A= have snmpSSHAddress values must fully describe how (and=0A= when) such names are to be resolved to IP addresses and vice=0A= versa.=0A= =0A= This textual convention SHOULD NOT be used directly in=0A= object definitions since it restricts addresses to a=0A= specific format. However, if it is used, it MAY be used=0A= either on its own or in conjunction with=0A= TransportAddressType or TransportDomain as a pair.=0A= =0A= When this textual convention is used as a syntax of an=0A= index object, there may be issues with the limit of 128=0A= sub-identifiers specified in SMIv2, STD 58. It is=0A= RECOMMENDED that all MIB documents using this textual=0A= convention make explicit any limitations on index=0A= component lengths that management software must observe.=0A= This may be done either by including SIZE constraints on=0A= the index components or by specifying applicable=0A= constraints in the conceptual row DESCRIPTION clause or=0A= in the surrounding documentation.=0A= "=0A= REFERENCE=0A= "RFC3986, Uniform Resource Identifier (URI): Generic Syntax"=0A= SYNTAX OCTET STRING (SIZE (1..255))=0A= =0A= =0A= -- The sshtmSession Group=0A= =0A= sshtmSession OBJECT IDENTIFIER ::=3D { sshtmObjects 1 }=0A= =0A= sshtmSessionOpens OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request has been=0A= executed as an SSH client, whether it succeeded or=0A= failed.=0A= "=0A= ::=3D { sshtmSession 1 }=0A= =0A= sshtmSessionCloses OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 23]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= DESCRIPTION "The number of times a closeSession() request has been=0A= executed as an SSH client, whether it succeeded or=0A= failed.=0A= "=0A= ::=3D { sshtmSession 2 }=0A= =0A= sshtmSessionOpenErrors OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a transport connection, or failed to=0A= authenticate the server.=0A= "=0A= ::=3D { sshtmSession 3 }=0A= =0A= sshtmSessionUserAuthFailures OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a session as a SSH client due to user=0A= authentication failures.=0A= "=0A= ::=3D { sshtmSession 4 }=0A= =0A= sshtmSessionChannelOpenFailures OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a session as a SSH client due to=0A= channel open failures.=0A= "=0A= ::=3D { sshtmSession 5 }=0A= =0A= sshtmSessionUnavailableSubsystems OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an openSession() request=0A= failed to open a session as a SSH client due to=0A= inability to connect to the requested subsystem.=0A= "=0A= ::=3D { sshtmSession 6 }=0A= =0A= sshtmSessionNoAvailableSessions OBJECT-TYPE=0A= SYNTAX Counter32=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 24]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of times an outgoing message=0A= was dropped because the same=0A= session was no longer available.=0A= "=0A= ::=3D { sshtmSession 7 }=0A= =0A= sshtmSessionInvalidCaches OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of outgoing messages dropped because the=0A= tmStateReference referred to an invalid cache.=0A= "=0A= ::=3D { sshtmSession 8 }=0A= =0A= -- ************************************************=0A= -- sshtmMIB - Conformance Information=0A= -- ************************************************=0A= =0A= sshtmCompliances OBJECT IDENTIFIER ::=3D { sshtmConformance 1 }=0A= =0A= sshtmGroups OBJECT IDENTIFIER ::=3D { sshtmConformance 2 }=0A= =0A= -- ************************************************=0A= -- Compliance statements=0A= -- ************************************************=0A= =0A= sshtmCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= =0A= DESCRIPTION "The compliance statement for SNMP engines that=0A= support the SNMP-SSH-TM-MIB"=0A= MODULE=0A= MANDATORY-GROUPS { sshtmGroup }=0A= ::=3D { sshtmCompliances 1 }=0A= =0A= -- ************************************************=0A= -- Units of conformance=0A= -- ************************************************=0A= sshtmGroup OBJECT-GROUP=0A= OBJECTS {=0A= sshtmSessionOpens,=0A= sshtmSessionCloses,=0A= sshtmSessionOpenErrors,=0A= sshtmSessionUserAuthFailures,=0A= sshtmSessionChannelOpenFailures,=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 25]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= sshtmSessionUnavailableSubsystems,=0A= sshtmSessionNoAvailableSessions=0A= }=0A= STATUS current=0A= DESCRIPTION "A collection of objects for maintaining=0A= information of an SNMP engine which implements the=0A= SNMP Secure Shell Transport Model.=0A= "=0A= =0A= =0A= ::=3D { sshtmGroups 2 }=0A= =0A= =0A= END=0A= =0A= =0A= 8. Operational Considerations=0A= =0A= The SSH Transport Model will likely not work in conditions where=0A= access to the CLI has stopped working. In situations where SNMP=0A= access has to work when the CLI has stopped working, a UDP transport=0A= model should be considered instead of the SSH Transport Model.=0A= =0A= If the SSH Transport Model is configured to utilize AAA services,=0A= operators should consider configuring support for local=0A= authentication mechanisms, such as local passwords, so SNMP can=0A= continue operating during times of network stress.=0A= =0A= The SSH protocol has its own window mechanism, defined in RFC 4254.=0A= The SSH specifications leave it open when window adjustments messages=0A= should be created, and some implementations send these whenever=0A= received data has been passed to the application. There are=0A= noticeable bandwidth and processing overheads to handling such window=0A= adjustment messages, which can be avoided by sending them less=0A= frequently.=0A= =0A= The SSH protocol requires the execution of CPU intensive calculations=0A= to establish a session key during session establishment. This means=0A= that short lived sessions become computationally expensive compared=0A= to USM, which does not have a notion of a session key. Other=0A= transport security protocols such as TLS support a session resumption=0A= feature that allows reusing a cached session key. Such a mechanism=0A= does not exist for SSH and thus SNMP applications should keep SSH=0A= sessions for longer time periods.=0A= =0A= To initiate SSH connections, an entity must be configured with SSH=0A= client credentials plus information to authenticate the server.=0A= While hosts are often configured to be SSH clients, most=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 26]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= internetworking devices are not. To send notifications over SSHTM,=0A= the internetworking device will need to be configured as an SSH=0A= client. How this credential configuration is done is implementation=0A= and deployment specific.=0A= =0A= 9. Security Considerations=0A= =0A= This document describes a transport model that permits SNMP to=0A= utilize SSH security services. The security threats and how the SSH=0A= Transport Model mitigates those threats is covered in detail=0A= throughout this memo.=0A= =0A= The SSH Transport Model relies on SSH mutual authentication, binding=0A= of keys, confidentiality and integrity. Any authentication method=0A= that meets the requirements of the SSH architecture will provide the=0A= properties of mutual authentication and binding of keys.=0A= =0A= SSHv2 provides Perfect Forward Security (PFS) for encryption keys.=0A= PFS is a major design goal of SSH, and any well-designed keyex=0A= algorithm will provide it.=0A= =0A= The security implications of using SSH are covered in [RFC4251].=0A= =0A= The SSH Transport Model has no way to verify that server=0A= authentication was performed, to learn the host's public key in=0A= advance, or verify that the correct key is being used. The SSH=0A= Transport Model simply trusts that these are properly configured by=0A= the implementer and deployer.=0A= =0A= SSH provides the "none" userauth method. The SSH Transport Model=0A= MUST NOT be used with an SSH connection with the "none" userauth=0A= method. While SSH does support turning off confidentiality and=0A= integrity, they MUST NOT be turned off when used with the SSH=0A= Transport Model.=0A= =0A= The SSH protocol is not always clear on whether the user name field=0A= must be filled in, so for some implementations, such as those using=0A= GSSAPI authentication, it may be necessary to use a mapping algorithm=0A= to transform an SSH identity to a tmSecurityName, or to transform a=0A= tmSecurityName to an SSH identity.=0A= =0A= In other cases the user name may not be verified by the server, so=0A= for these implementations, it may be necessary to obtain the user=0A= name from other credentials exchanged during the SSH exchange.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 27]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= 9.1. Skipping Public Key Verification=0A= =0A= Most key exchange algorithms are able to authenticate the SSH=0A= server's identity to the client. However, for the common case of DH=0A= signed by public keys, this requires the client to know the host's=0A= public key a priori and to verify that the correct key is being used.=0A= If this step is skipped, then authentication of the SSH server to the=0A= SSH client is not done. Data confidentiality and data integrity=0A= protection to the server still exist, but these are of dubious value=0A= when an attacker can insert himself between the client and the real=0A= SSH server. Note that some userauth methods may defend against this=0A= situation, but many of the common ones (including password and=0A= keyboard-interactive) do not, and in fact depend on the fact that the=0A= server's identity has been verified (so passwords are not disclosed=0A= to an attacker).=0A= =0A= SSH MUST NOT be configured to skip public key verification for use=0A= with the SSH Transport Model.=0A= =0A= 9.2. The 'none' MAC Algorithm=0A= =0A= SSH provides the "none" MAC algorithm, which would allow you to turn=0A= off data integrity while maintaining confidentiality. However, if=0A= you do this, then an attacker may be able to modify the data in=0A= flight, which means you effectively have no authentication.=0A= =0A= SSH MUST NOT be configured using the "none" MAC algorithm for use=0A= with the SSH Transport Model.=0A= =0A= 9.3. Use with SNMPv1/v2c Messages=0A= =0A= The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP=0A= 74) [RFC3584] always select the SNMPv1 or SNMPv2c Security Models=0A= respectively. Both of these, and the User-based Security Model=0A= typically used with SNMPv3, derive the securityName and securityLevel=0A= from the SNMP message received, even when the message was received=0A= over a secure transport. Access control decisions are therefore made=0A= based on the contents of the SNMP message, rather than using the=0A= authenticated identity and securityLevel provided by the SSH=0A= Transport Model.=0A= =0A= 9.4. MIB Module Security=0A= =0A= There are no management objects defined in this MIB module that have=0A= a MAX-ACCESS clause of read-write and/or read-create. So, if this=0A= MIB module is implemented correctly, then there is no risk that an=0A= intruder can alter or create any management objects of this MIB=0A= module via direct SNMP SET operations.=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 28]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Some of the readable objects in this MIB module (i.e., objects with a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET and/or NOTIFY access to these objects and possibly=0A= to even encrypt the values of these objects when sending them over=0A= the network via SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o The readable objects in this MIB module are not sensitive.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using IPSec or=0A= SSH), even then, there is no control as to who on the secure network=0A= is allowed to access and GET/SET (read/change/create/delete) the=0A= objects in this MIB module.=0A= =0A= It is RECOMMENDED that implementers consider the security features as=0A= provided by the SNMPv3 framework (see [RFC3410] section 8), including=0A= full support for the USM and the SSH Transport Model cryptographic=0A= mechanisms (for authentication and privacy).=0A= =0A= Further, deployment of SNMP versions prior to SNMPv3 is NOT=0A= RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to=0A= enable cryptographic security. It is then a customer/operator=0A= responsibility to ensure that the SNMP entity giving access to an=0A= instance of this MIB module is properly configured to give access to=0A= the objects only to those principals (users) that have legitimate=0A= rights to indeed GET or SET (change/create/delete) them.=0A= =0A= 10. IANA Considerations=0A= =0A= IANA is requested to assign:=0A= =0A= 1. two TCP registered port numbers in the=0A= http://www.iana.org/assignments/port-numbers registry which will=0A= be the default ports for SNMP over an SSH Transport Model (SSHTM)=0A= as defined in this document, and SNMP over an SSH Transport Model=0A= for notifications (SSHTM-TRAP) as defined in this document. It=0A= would be good if the assigned numbers were x161 and x162.=0A= =0A= 2. an SMI number under mib-2, for the MIB module in this document,=0A= =0A= 3. an SMI number under snmpDomains, for the snmpSSHDomain,=0A= =0A= 4. "ssh" as the corresponding prefix for the snmpSSHDomain in the=0A= SNMP Transport Model registry; defined in [I-D.ietf-isms-tmsm]=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 29]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= 5. "snmp" as an SSH Subsystem Name in the=0A= http://www.iana.org/assignments/ssh-parameters registry.=0A= =0A= -- note to RFC editor -- Please replace YYY and ZZZ in this document=0A= with the assigned port numbers and remove this note.=0A= =0A= 11. Acknowledgements=0A= =0A= The editors would like to thank Jeffrey Hutzelman for sharing his SSH=0A= insights, and Dave Shield for an outstanding job wordsmithing the=0A= existing document to improve organization and clarity.=0A= =0A= Additionally, helpful document reviews were received from: Juergen=0A= Schoenwaelder.=0A= =0A= 12. References=0A= =0A= 12.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for=0A= use in RFCs to Indicate=0A= Requirement Levels",=0A= BCP 14, RFC 2119,=0A= March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed.,=0A= Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed.,=0A= "Structure of Management=0A= Information Version 2=0A= (SMIv2)", STD 58, RFC 2578,=0A= April 1999.=0A= =0A= [RFC2579] McCloghrie, K., Ed.,=0A= Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed.,=0A= "Textual Conventions for=0A= SMIv2", STD 58, RFC 2579,=0A= April 1999.=0A= =0A= [RFC2580] McCloghrie, K., Perkins,=0A= D., and J. Schoenwaelder,=0A= "Conformance Statements for=0A= SMIv2", STD 58, RFC 2580,=0A= April 1999.=0A= =0A= [RFC2865] Rigney, C., Willens, S.,=0A= Rubens, A., and W. Simpson,=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 30]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= "Remote Authentication Dial=0A= In User Service (RADIUS)",=0A= RFC 2865, June 2000.=0A= =0A= [RFC3411] Harrington, D., Presuhn,=0A= R., and B. Wijnen, "An=0A= Architecture for Describing=0A= Simple Network Management=0A= Protocol (SNMP) Management=0A= Frameworks", STD 62,=0A= RFC 3411, December 2002.=0A= =0A= [RFC3413] Levi, D., Meyer, P., and B.=0A= Stewart, "Simple Network=0A= Management Protocol (SNMP)=0A= Applications", STD 62,=0A= RFC 3413, December 2002.=0A= =0A= [RFC3414] Blumenthal, U. and B.=0A= Wijnen, "User-based=0A= Security Model (USM) for=0A= version 3 of the Simple=0A= Network Management Protocol=0A= (SNMPv3)", STD 62,=0A= RFC 3414, December 2002.=0A= =0A= [RFC3418] Presuhn, R., "Management=0A= Information Base (MIB) for=0A= the Simple Network=0A= Management Protocol=0A= (SNMP)", STD 62, RFC 3418,=0A= December 2002.=0A= =0A= [RFC3490] Faltstrom, P., Hoffman, P.,=0A= and A. Costello,=0A= "Internationalizing Domain=0A= Names in Applications=0A= (IDNA)", RFC 3490,=0A= March 2003.=0A= =0A= [RFC3584] Frye, R., Levi, D.,=0A= Routhier, S., and B.=0A= Wijnen, "Coexistence=0A= between Version 1, Version=0A= 2, and Version 3 of the=0A= Internet-standard Network=0A= Management Framework",=0A= BCP 74, RFC 3584,=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 31]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= August 2003.=0A= =0A= [RFC4251] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Protocol Architecture",=0A= RFC 4251, January 2006.=0A= =0A= [RFC4252] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Authentication Protocol",=0A= RFC 4252, January 2006.=0A= =0A= [RFC4253] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Transport Layer Protocol",=0A= RFC 4253, January 2006.=0A= =0A= [RFC4254] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Connection Protocol",=0A= RFC 4254, January 2006.=0A= =0A= [I-D.ietf-isms-tmsm] Harrington, D. and J.=0A= Schoenwaelder, "Transport=0A= Subsystem for the Simple=0A= Network Management Protocol=0A= (SNMP)",=0A= draft-ietf-isms-tmsm-15=0A= (work in progress),=0A= October 2008.=0A= =0A= 12.2. Informative References=0A= =0A= [RFC1994] Simpson, W., "PPP Challenge=0A= Handshake Authentication=0A= Protocol (CHAP)", RFC 1994,=0A= August 1996.=0A= =0A= [RFC3410] Case, J., Mundy, R.,=0A= Partain, D., and B.=0A= Stewart, "Introduction and=0A= Applicability Statements=0A= for Internet-Standard=0A= Management Framework",=0A= RFC 3410, December 2002.=0A= =0A= [RFC3588] Calhoun, P., Loughney, J.,=0A= Guttman, E., Zorn, G., and=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 32]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= J. Arkko, "Diameter Base=0A= Protocol", RFC 3588,=0A= September 2003.=0A= =0A= [RFC3986] Berners-Lee, T., Fielding,=0A= R., and L. Masinter,=0A= "Uniform Resource=0A= Identifier (URI): Generic=0A= Syntax", STD 66, RFC 3986,=0A= January 2005.=0A= =0A= [RFC4256] Cusack, F. and M. Forssen,=0A= "Generic Message Exchange=0A= Authentication for the=0A= Secure Shell Protocol=0A= (SSH)", RFC 4256,=0A= January 2006.=0A= =0A= [RFC4462] Hutzelman, J., Salowey, J.,=0A= Galbraith, J., and V.=0A= Welch, "Generic Security=0A= Service Application Program=0A= Interface (GSS-API)=0A= Authentication and Key=0A= Exchange for the Secure=0A= Shell (SSH) Protocol",=0A= RFC 4462, May 2006.=0A= =0A= [RFC5090] Sterman, B., Sadolevsky,=0A= D., Schwartz, D., Williams,=0A= D., and W. Beck, "RADIUS=0A= Extension for Digest=0A= Authentication", RFC 5090,=0A= February 2008.=0A= =0A= [RFC4742] Wasserman, M. and T.=0A= Goddard, "Using the NETCONF=0A= Configuration Protocol over=0A= Secure SHell (SSH)",=0A= RFC 4742, December 2006.=0A= =0A= [I-D.ietf-isms-transport-security-model] Harrington, D. and W.=0A= Hardaker, "Transport=0A= Security Model for SNMP", d=0A= raft-ietf-isms-transport-=0A= security-model-10 (work in=0A= progress), October 2008.=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 33]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Appendix A. Change Log=0A= =0A= From -13 to -14=0A= =0A= Removed duplicated text on Caches and References, and reference=0A= tmsm document=0A= =0A= Simplified securityStateReference=0A= =0A= Simplified EOP to use tmStateReference rather than ASI parameters=0A= =0A= Simplified openSession and closeSession=0A= =0A= Seperated steps in openSession=0A= =0A= Clarified conditions in the openSession error counter descriptions=0A= =0A= Reworded text to clarify short versus long term information=0A= =0A= Added more warnings about the unreliability of SSH user name=0A= =0A= removed any references to LCD=0A= =0A= From -12 to -13=0A= =0A= Removed redundant sections 3.1.4 and 3.1.5 on privacy and replay/=0A= delay/etc protection.=0A= =0A= From -11- to -12=0A= =0A= Updated "Cached Information and References" to match other ISMS=0A= documents.=0A= =0A= Added separate subsection on Secure Shell Transport Model Cached=0A= Information.=0A= =0A= Added IANA considerations to add snmpSSHDomain and "ssh" to a=0A= registry for domains and corresponding prefixes, defined in TMSM.=0A= =0A= Added support for user@ prefixing in the SSH Transport Address=0A= definition and EOP.=0A= =0A= Added support for the "ssh" prefix to the transport address=0A= definition and IANA considerations section.=0A= =0A= Removed the LCD tables and related configuration since the user@=0A= transport address prefixing and the TSM user prefix changes change=0A= makes it no longer needed.=0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 34]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= From -10- to -11=0A= =0A= Changed LCD to sshtmLCDTable so it would not be confused with the=0A= snmpTsmLCD.=0A= =0A= Removed the text that said the format and content of the LCD is=0A= implementation-specific, since we now have a MIB module to=0A= standardize the format and content.=0A= =0A= Designed sshtmLCDTable to reflect there is only one=0A= transportDomain and one securityLevel supported by this transport=0A= model.=0A= =0A= Used sshtmLCDTmSecurityName to reflect that the values in this=0A= table and the values in the tmStateReference are usually the same=0A= for some fields.=0A= =0A= Added operational considerations about SSH client credential=0A= distribution.=0A= =0A= Modified EOP to use sshtmLCDTable=0A= =0A= Resolved Issue #8: Should we allow transport models to select the=0A= corresponding security model by providing an additional parameter=0A= - the securityModel parameter - to tmStateReference, which would=0A= override the securityModel parameter extracted from a message=0A= header? Doing this would resolve Issue #5, and would allow the=0A= transport security model to be used with all SNMP message=0A= versions. - The consensus is that we will not allow the transport=0A= model to specify the security model.=0A= =0A= From -09- to -10=0A= =0A= Issue #1: Made release of cached session info an implementation=0A= requirement on session close.=0A= =0A= Issue #4: UTF-8 syntax of userauth user name matches syntax of=0A= SnmpAdminString.=0A= =0A= Issue #7: Resolved to not describe how an SSH session is closed.=0A= =0A= From -08- to -09=0A= =0A= Updated MIB assignment to by rfc4181 compatible=0A= =0A= update MIB security considerations with coexistence issues=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 35]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= update sameSession and tmSessionID support=0A= =0A= Fixed note about terminology, for consistency with SNMPv3.=0A= =0A= From -07- to -08=0A= =0A= Updated MIB=0A= =0A= update MIB security considerations=0A= =0A= develop sameSession and tmSessionID support=0A= =0A= Added a note about terminology, for consistency with SNMPv3 rather=0A= than with RFC2828.=0A= =0A= Removed reference to mappings other than the identity function.=0A= =0A= From -06- to -07=0A= =0A= removed section on SSH to EngineID mappings, since engineIDs are=0A= not exposed to the transport model=0A= =0A= removed references to engineIDs and discovery=0A= =0A= removed references to securityModel.=0A= =0A= added security considerations warning about using with SNMPv1/v2c=0A= messages.=0A= =0A= added keyboard interactive discussion=0A= =0A= noted some implementation-dependent points=0A= =0A= removed references to transportModel; we use the transport domain=0A= as a model identifier.=0A= =0A= cleaned up ASIs=0A= =0A= modified MIB to be under snmpModules=0A= =0A= changed transportAddressSSH to snmpSSHDomain style addressing=0A= =0A= From -05- to -06=0A= =0A= replaced transportDomainSSH with RFC3417-style snmpSSHDomain=0A= =0A= replaced transportAddressSSH with RFC3417-style snmpSSHAddress=0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 36]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Changed recvMessage to receiveMessage, and modified OUT to IN to=0A= match TMSM.=0A= =0A= From -04- to -05=0A= =0A= added sshtmUserTable=0A= =0A= moved session table into the transport model MIB from the=0A= transport subsystem MIB=0A= =0A= added and then removed Appendix A - Notification Tables=0A= Configuration (see Transport Security Model)=0A= =0A= made this document a specification of a transport model, rather=0A= than a security model in two parts. Eliminated TMSP and MPSP and=0A= replaced them with "transport model" and "security model".=0A= =0A= Removed security-model-specific processing from this document.=0A= =0A= Removed discussion of snmpv3/v1/v2c message format co-existence=0A= =0A= changed tmSessionReference back to tmStateReference=0A= =0A= "From -03- to -04-"=0A= =0A= changed tmStateReference to tmSessionReference=0A= =0A= =0A= =0A= "From -02- to -03-"=0A= =0A= rewrote almost all sections=0A= =0A= merged ASI section and Elements of Procedure sections=0A= =0A= removed references to the SSH user, in preference to SSH client=0A= =0A= updated references=0A= =0A= created a conventions section to identify common terminology.=0A= =0A= rewrote sections on how SSH addresses threats=0A= =0A= rewrote mapping SSH to engineID=0A= =0A= eliminated discovery section=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 37]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= detailed the Elements of Procedure=0A= =0A= eliminated sections on msgFlags, transport parameters=0A= =0A= resolved issues of opening notifications=0A= =0A= eliminated sessionID (TMSM needs to be updated to match)=0A= =0A= eliminated use of tmsSessiontable except as an example=0A= =0A= updated Security Considerations=0A= =0A= "From -01- to -02-"=0A= =0A= Added TransportDomainSSH and Address=0A= =0A= Removed implementation considerations=0A= =0A= Changed all "user auth" to "client auth"=0A= =0A= Removed unnecessary MIB module objects=0A= =0A= updated references=0A= =0A= improved consistency of references to TMSM as architectural=0A= extension=0A= =0A= updated conventions=0A= =0A= updated threats to be more consistent with RFC3552=0A= =0A= discussion of specific SSH mechanism configurations moved to=0A= security considerations=0A= =0A= modified session discussions to reference TMSM sessions=0A= =0A= expanded discussion of engineIDs=0A= =0A= wrote text to clarify the roles of MPSP and TMSP=0A= =0A= clarified how snmpv3 message parts are ised by SSHSM=0A= =0A= modified nesting of subsections as needed=0A= =0A= securityLevel used by the SSH Transport Model always equals=0A= authPriv=0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 38]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= removed discussion of using SSHSM with SNMPv1/v2c=0A= =0A= started updating Elements of Procedure, but realized missing info=0A= needs discussion.=0A= =0A= updated MIB module relationship to other MIB modules=0A= =0A= "From -00- to -01-"=0A= =0A= -00- initial draft as ISMS work product:=0A= =0A= updated references to secshell RFCs=0A= =0A= Modified text related to issues# 1, 2, 8, 11, 13, 14, 16, 18, 19,=0A= 20, 29, 30, and 32.=0A= =0A= updated security considerations=0A= =0A= removed Juergen Schoenwaelder from authors, at his request=0A= =0A= ran the mib module through smilint=0A= =0A= Authors' Addresses=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= Joseph Salowey=0A= Cisco Systems=0A= 2901 3rd Ave=0A= Seattle, WA 98121=0A= USA=0A= =0A= EMail: jsalowey@cisco.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 39]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Wes Hardaker=0A= Sparta, Inc.=0A= P.O. Box 382=0A= Davis, CA 95617=0A= US=0A= =0A= Phone: +1 530 792 1913=0A= EMail: ietf@hardakers.net=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 40]=0A= =0C=0A= Internet-Draft Secure Shell Transport Model for SNMP February 2009=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2009).=0A= =0A= This document is subject to the rights, licenses and restrictions=0A= contained in BCP 78, and except as set forth therein, the authors=0A= retain all their rights.=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington, et al. Expires August 15, 2009 [Page 41]=0A= =0C=0A= =0A= ------=_NextPart_000_0019_01C98C6C.39368240-- From wjhns1@hardakers.net Wed Feb 11 15:12:37 2009 Return-Path: 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 D8DEC3A6A2A for ; Wed, 11 Feb 2009 15:12:37 -0800 (PST) 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 z4gUXqgZcbSp for ; Wed, 11 Feb 2009 15:12:37 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id DBA093A6A20 for ; Wed, 11 Feb 2009 15:12:36 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 4681D39A1FD; Wed, 11 Feb 2009 15:12:41 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <001801c98c96$220a4050$0600a8c0@china.huawei.com> Date: Wed, 11 Feb 2009 15:12:41 -0800 In-Reply-To: <001801c98c96$220a4050$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 11 Feb 2009 17:14:39 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] Ismssecshell-pre14b 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: , X-List-Received-Date: Wed, 11 Feb 2009 23:12:37 -0000 Looks good aside from one nit regarding: DH> 3) the user@ issue has been addressed. Can we drop one of your new sentences: this will be different than the "foo.com" formatted address reported by SSH for the incoming message. It implies how an implementation passes connection information, which I don't think is relevant. All the text up until then is generic and describes all that is needed (IE, the sentence "the transportAddress passed in the receiveMessage ASI MUST match the "user@foo.com" tmTransportAddress used to open the session" is sufficient) -- Wes Hardaker Sparta, Inc. From j.schoenwaelder@jacobs-university.de Wed Feb 11 15:17:55 2009 Return-Path: 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 069423A6BDE for ; Wed, 11 Feb 2009 15:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 J5IM3Mln18rT for ; Wed, 11 Feb 2009 15:17:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0D76D3A6B4D for ; Wed, 11 Feb 2009 15:17:54 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A4B6C002F; Thu, 12 Feb 2009 00:17:55 +0100 (CET) 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 CPWZ5NkVeah6; Thu, 12 Feb 2009 00:17:47 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAFE6C0033; Thu, 12 Feb 2009 00:17:46 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id CCB3B993494; Thu, 12 Feb 2009 00:17:45 +0100 (CET) Date: Thu, 12 Feb 2009 00:17:45 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090211231745.GD8133@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: Wes Hardaker , David Harrington , isms@ietf.org References: <001801c98c96$220a4050$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: isms@ietf.org Subject: Re: [Isms] Ismssecshell-pre14b 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: , X-List-Received-Date: Wed, 11 Feb 2009 23:17:55 -0000 On Wed, Feb 11, 2009 at 03:12:41PM -0800, Wes Hardaker wrote: > > Looks good aside from one nit regarding: > > DH> 3) the user@ issue has been addressed. > > Can we drop one of your new sentences: > > this will be different than the "foo.com" formatted address > reported by SSH for the incoming message. > > It implies how an implementation passes connection information, which I > don't think is relevant. All the text up until then is generic and > describes all that is needed (IE, the sentence "the transportAddress > passed in the receiveMessage ASI MUST match the "user@foo.com" > tmTransportAddress used to open the session" is sufficient) Nit: should we not use example.com instead foo.com (RFC 2606)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Pasi.Eronen@nokia.com Thu Feb 19 00:04:04 2009 Return-Path: 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 7259D3A6A65 for ; Thu, 19 Feb 2009 00:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 WbDXChQUFLW8 for ; Thu, 19 Feb 2009 00:04:03 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 82C7F3A691C for ; Thu, 19 Feb 2009 00:04:02 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1J83qAi014393; Thu, 19 Feb 2009 02:04:10 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 10:04:00 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 10:03:59 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 19 Feb 2009 09:03:58 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Thu, 19 Feb 2009 09:03:58 +0100 From: To: , Date: Thu, 19 Feb 2009 09:03:58 +0100 Thread-Topic: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 Thread-Index: AclQhz6E3EeYK4jZSYmwNwYWd8X+9g4oT4hAAk/UTZA= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E7A83FB0@NOK-EUMSG-01.mgdnok.nokia.com> References: <1696498986EFEC4D9153717DA325CB720265001D@vaebe104.NOE.Nokia.com> <096401c98b39$b4cab4f0$0600a8c0@china.huawei.com> In-Reply-To: <096401c98b39$b4cab4f0$0600a8c0@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Feb 2009 08:03:59.0110 (UTC) FILETIME=[9E8D8A60:01C99268] X-Nokia-AV: Clean Subject: Re: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 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: , X-List-Received-Date: Thu, 19 Feb 2009 08:04:04 -0000 David Harrington wrote: > > Hi Pasi, > > Iam not certain that I have addressed all your issues. Can you > please check the latest rev? comments inline. The one thing that's still slightly unclear is how tmStateReference cache entry gets created on SSH client side (e.g. command originator). In particular, Section 5.2, step 1, seems to assume that it always gets a tmStateReference. But when the Dispatcher on e.g. command generator (acting as SSH client) calls sendMessage for the first time, it doesn't have a tmStateReference yet? (Or if it does have a tmStateReference, where did it come from?) My guess is that Section 5.2 should say that if tmStateReference is not present, steps 1..3 are skipped, and instead we create a tmStateReference cache entry (because we can't call openSession without having one) and go to step 4 (opening a new session). Best regards, Pasi From Pasi.Eronen@nokia.com Thu Feb 19 00:18:14 2009 Return-Path: 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 EEE1B28C1D6 for ; Thu, 19 Feb 2009 00:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.058, 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 ouz0d9M9R0lz for ; Thu, 19 Feb 2009 00:18:14 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id CC64228C1CC for ; Thu, 19 Feb 2009 00:18:13 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1J8II1b017263; Thu, 19 Feb 2009 10:18:21 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 10:18:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 10:18:15 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 19 Feb 2009 09:18:14 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Thu, 19 Feb 2009 09:18:14 +0100 From: To: , Date: Thu, 19 Feb 2009 09:18:12 +0100 Thread-Topic: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 Thread-Index: AclQhz6E3EeYK4jZSYmwNwYWd8X+9g4oT4hAAk/UTZAAAKXx8A== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E7A83FDE@NOK-EUMSG-01.mgdnok.nokia.com> References: <1696498986EFEC4D9153717DA325CB720265001D@vaebe104.NOE.Nokia.com> <096401c98b39$b4cab4f0$0600a8c0@china.huawei.com> <808FD6E27AD4884E94820BC333B2DB7727E7A83FB0@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E7A83FB0@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Feb 2009 08:18:15.0893 (UTC) FILETIME=[9D3C4050:01C9926A] X-Nokia-AV: Clean Subject: Re: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 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: , X-List-Received-Date: Thu, 19 Feb 2009 08:18:15 -0000 Oops -- please ignore this one; I just found where the tmStateReference is created (transport-security-model, Section 4.2). Best regards, Pasi > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Eronen Pasi (Nokia-NRC/Helsinki) > Sent: 19 February, 2009 10:04 > To: ietfdbh@comcast.net; isms@ietf.org > Subject: Re: [Isms] Comments about > draft-ietf-isms-secshell-13, Section 5 > > David Harrington wrote: > > > > Hi Pasi, > > > > Iam not certain that I have addressed all your issues. Can you > > please check the latest rev? comments inline. > > The one thing that's still slightly unclear is how tmStateReference > cache entry gets created on SSH client side (e.g. command originator). > > In particular, Section 5.2, step 1, seems to assume that it always > gets a tmStateReference. But when the Dispatcher on e.g. command > generator (acting as SSH client) calls sendMessage for the first > time, it doesn't have a tmStateReference yet? (Or if it does have > a tmStateReference, where did it come from?) > > My guess is that Section 5.2 should say that if tmStateReference is > not present, steps 1..3 are skipped, and instead we create a > tmStateReference cache entry (because we can't call openSession > without having one) and go to step 4 (opening a new session). > > Best regards, > Pasi > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From Pasi.Eronen@nokia.com Thu Feb 19 00:20:44 2009 Return-Path: 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 D36DC28C1DD for ; Thu, 19 Feb 2009 00:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 7jrXksL71nsr for ; Thu, 19 Feb 2009 00:20:44 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id BDDC53A6783 for ; Thu, 19 Feb 2009 00:20:43 -0800 (PST) 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 n1J8KUAU001169; Thu, 19 Feb 2009 10:20:49 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 10:20:46 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 10:20:41 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 19 Feb 2009 09:20:40 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Thu, 19 Feb 2009 09:20:40 +0100 From: To: , Date: Thu, 19 Feb 2009 09:20:39 +0100 Thread-Topic: [Isms] draft-ietf-isms-transport-security-model-pre11a.txt Thread-Index: AcmLM+qxOMPxdZmaR9ar7oENPW6RIAHNwAyQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E7A83FE3@NOK-EUMSG-01.mgdnok.nokia.com> References: <094101c98b33$eaf68ff0$0600a8c0@china.huawei.com> In-Reply-To: <094101c98b33$eaf68ff0$0600a8c0@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Feb 2009 08:20:41.0895 (UTC) FILETIME=[F4426370:01C9926A] X-Nokia-AV: Clean Subject: Re: [Isms] draft-ietf-isms-transport-security-model-pre11a.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: , X-List-Received-Date: Thu, 19 Feb 2009 08:20:44 -0000 All my comments have been addressed in this version. Thanks! Best regards, Pasi > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of ext David Harrington > Sent: 10 February, 2009 05:59 > To: isms@ietf.org > Subject: [Isms] draft-ietf-isms-transport-security-model-pre11a.txt > > > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > From Pasi.Eronen@nokia.com Thu Feb 19 00:27:29 2009 Return-Path: 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 C6B4128C1DD for ; Thu, 19 Feb 2009 00:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 godUHXQvBcSp for ; Thu, 19 Feb 2009 00:27:29 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id AA3C328C1D6 for ; Thu, 19 Feb 2009 00:27:28 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1J8RU55026786; Thu, 19 Feb 2009 10:27:37 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 10:27:19 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 10:27:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 10:27:07 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 19 Feb 2009 09:27:06 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Thu, 19 Feb 2009 09:27:06 +0100 From: To: , Date: Thu, 19 Feb 2009 09:27:05 +0100 Thread-Topic: [Isms] draft-ietf-isms-tmsm-pre16a.txt Thread-Index: AcmLM9G0HxzS/QGjS3eoODbmcIO5GAHN/vnw Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E7A83FF2@NOK-EUMSG-01.mgdnok.nokia.com> References: <093d01c98b33$d2d99e80$0600a8c0@china.huawei.com> In-Reply-To: <093d01c98b33$d2d99e80$0600a8c0@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Feb 2009 08:27:07.0783 (UTC) FILETIME=[DA443970:01C9926B] X-Nokia-AV: Clean Subject: Re: [Isms] draft-ietf-isms-tmsm-pre16a.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: , X-List-Received-Date: Thu, 19 Feb 2009 08:27:29 -0000 This version addresses all my comments. Thanks! Best regards, Pasi > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of ext David Harrington > Sent: 10 February, 2009 05:58 > To: isms@ietf.org > Subject: [Isms] draft-ietf-isms-tmsm-pre16a.txt > > > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > From jhutz@cmu.edu Thu Feb 19 11:13:46 2009 Return-Path: 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 C377F3A6B73 for ; Thu, 19 Feb 2009 11:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.836 X-Spam-Level: X-Spam-Status: No, score=-5.836 tagged_above=-999 required=5 tests=[AWL=0.763, 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 MDAFcfHeIj93 for ; Thu, 19 Feb 2009 11:13:46 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id BB0243A6A47 for ; Thu, 19 Feb 2009 11:13:45 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1JJDtG2013611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 14:13:56 -0500 (EST) Date: Thu, 19 Feb 2009 14:13:55 -0500 From: Jeffrey Hutzelman To: Pasi.Eronen@nokia.com, ietfdbh@comcast.net, isms@ietf.org Message-ID: In-Reply-To: <200902190804.n1J84M98018750@raisinbran.srv.cs.cmu.edu> References: <1696498986EFEC4D9153717DA325CB720265001D@vaebe104.NOE.Nokia.com> <096401c98b39$b4cab4f0$0600a8c0@china.huawei.com> <200902190804.n1J84M98018750@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 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: , X-List-Received-Date: Thu, 19 Feb 2009 19:13:46 -0000 --On Thursday, February 19, 2009 09:03:58 AM +0100 Pasi.Eronen@nokia.com wrote: > David Harrington wrote: >> >> Hi Pasi, >> >> Iam not certain that I have addressed all your issues. Can you >> please check the latest rev? comments inline. > > The one thing that's still slightly unclear is how tmStateReference > cache entry gets created on SSH client side (e.g. command originator). > > In particular, Section 5.2, step 1, seems to assume that it always > gets a tmStateReference. But when the Dispatcher on e.g. command > generator (acting as SSH client) calls sendMessage for the first > time, it doesn't have a tmStateReference yet? (Or if it does have > a tmStateReference, where did it come from?) In the expected case, it comes from TSM, in paragraph 4.2(2) of draft-ietf-isms-transport-security-model-10.txt. However, modularity demands that SSHTM work even when not used with TSM, and particularly, section 6.1 of draft-ietf-isms-tmsm-15.txt implies that the sendMessage ASI needs to work even when tmStateReference is not given. > My guess is that Section 5.2 should say that if tmStateReference is > not present, steps 1..3 are skipped, and instead we create a > tmStateReference cache entry (because we can't call openSession > without having one) and go to step 4 (opening a new session). We don't need a tmStateReference cache entry to call openSession. I believe the right behavior here is in fact to skip directly to step 4, as if there had been no LCD entry, and create a new SSH session. The difficulty is that currently we can't call openSession without a tmSecurityName, and we don't have one. I see two possible solutions to this problem: (1) redefine openSession (a private ASI between SSHTM and SSH) to not require a tmSecurityName. In the case where destTransportAddress does not contain an '@' and tmSecurityName is not given, openSession should not pass any username to SSH. Instead, SSH will figure out on its own what username to use. Most SSH client implementations have heuristics for this which are quite often right; in the case of SSHTM-without-TSM, I'd expect these heuristics to be at least as good as anything else we can do, probably including using the SNMP securityName. (2) redefine sendMessage to include the security model, name, and level, so that a secure transport can use them in setting up a session. Then, if there is no tmStateReference, pass the securityName parameter on to openSession. Separately, I think we may have an issue in that sendMessage currently looks for the one-and-only existing session which matches destTransportAddress and tmSecurityName, and then reports an error if tmSameSecurity is true and the session ID does not match. Is it possible that there will be two different sessions with the same transport address and security ID? If so, and even if not, it seems that it may be appropriate to search for the one-and-only existing session with the same sessionID, and then verify that the transport address and security name match, rather than the other way around. -- Jeff From ietfdbh@comcast.net Thu Feb 19 11:43:02 2009 Return-Path: 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 B05753A6B73 for ; Thu, 19 Feb 2009 11:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 L6U8gHrK935I for ; Thu, 19 Feb 2009 11:43:01 -0800 (PST) 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 497FC3A6B1F for ; Thu, 19 Feb 2009 11:43:01 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA04.westchester.pa.mail.comcast.net with comcast id HmiY1b0010bG4ec54vjFVm; Thu, 19 Feb 2009 19:43:15 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA03.westchester.pa.mail.comcast.net with comcast id HvjE1b0050UQ6dC3PvjEY6; Thu, 19 Feb 2009 19:43:15 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , , References: <1696498986EFEC4D9153717DA325CB720265001D@vaebe104.NOE.Nokia.com> <096401c98b39$b4cab4f0$0600a8c0@china.huawei.com> <200902190804.n1J84M98018750@raisinbran.srv.cs.cmu.edu> Date: Thu, 19 Feb 2009 14:43:13 -0500 Message-ID: <05b901c992ca$4da83c50$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmSxjeNZ7maGIV4T+Wxv0EdseDnzQABAuxA Subject: Re: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 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: , X-List-Received-Date: Thu, 19 Feb 2009 19:43:02 -0000 I'll look into this. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Thursday, February 19, 2009 2:14 PM > To: Pasi.Eronen@nokia.com; ietfdbh@comcast.net; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] Comments about > draft-ietf-isms-secshell-13, Section 5 > > --On Thursday, February 19, 2009 09:03:58 AM +0100 > Pasi.Eronen@nokia.com > wrote: > > > David Harrington wrote: > >> > >> Hi Pasi, > >> > >> Iam not certain that I have addressed all your issues. Can you > >> please check the latest rev? comments inline. > > > > The one thing that's still slightly unclear is how tmStateReference > > cache entry gets created on SSH client side (e.g. command > originator). > > > > In particular, Section 5.2, step 1, seems to assume that it always > > gets a tmStateReference. But when the Dispatcher on e.g. command > > generator (acting as SSH client) calls sendMessage for the first > > time, it doesn't have a tmStateReference yet? (Or if it does have > > a tmStateReference, where did it come from?) > > In the expected case, it comes from TSM, in paragraph 4.2(2) of > draft-ietf-isms-transport-security-model-10.txt. > > However, modularity demands that SSHTM work even when not > used with TSM, > and particularly, section 6.1 of draft-ietf-isms-tmsm-15.txt > implies that > the sendMessage ASI needs to work even when tmStateReference > is not given. > > > My guess is that Section 5.2 should say that if tmStateReference is > > not present, steps 1..3 are skipped, and instead we create a > > tmStateReference cache entry (because we can't call openSession > > without having one) and go to step 4 (opening a new session). > > We don't need a tmStateReference cache entry to call openSession. I > believe the right behavior here is in fact to skip directly > to step 4, as > if there had been no LCD entry, and create a new SSH session. The > difficulty is that currently we can't call openSession without a > tmSecurityName, and we don't have one. I see two possible > solutions to > this problem: > > (1) redefine openSession (a private ASI between SSHTM and SSH) to not > require a tmSecurityName. In the case where > destTransportAddress does not > contain an '@' and tmSecurityName is not given, openSession > should not pass > any username to SSH. Instead, SSH will figure out on its own > what username > to use. Most SSH client implementations have heuristics for > this which are > quite often right; in the case of SSHTM-without-TSM, I'd expect these > heuristics to be at least as good as anything else we can do, > probably > including using the SNMP securityName. > > (2) redefine sendMessage to include the security model, name, > and level, so > that a secure transport can use them in setting up a session. > Then, if > there is no tmStateReference, pass the securityName parameter on to > openSession. > > > > Separately, I think we may have an issue in that sendMessage > currently > looks for the one-and-only existing session which matches > destTransportAddress and tmSecurityName, and then reports an error if > tmSameSecurity is true and the session ID does not match. Is > it possible > that there will be two different sessions with the same > transport address > and security ID? If so, and even if not, it seems that it may be > appropriate to search for the one-and-only existing session > with the same > sessionID, and then verify that the transport address and > security name > match, rather than the other way around. > > -- Jeff > From ietfdbh@comcast.net Wed Feb 25 09:20:34 2009 Return-Path: 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 8548C28C28A for ; Wed, 25 Feb 2009 09:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 YU5UKu++8sd3 for ; Wed, 25 Feb 2009 09:20:33 -0800 (PST) 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 35E7728C1A7 for ; Wed, 25 Feb 2009 09:20:33 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA05.westchester.pa.mail.comcast.net with comcast id LBUM1b00B0QuhwU55HLuny; Wed, 25 Feb 2009 17:20:54 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id LHLt1b00r0UQ6dC3NHLuB8; Wed, 25 Feb 2009 17:20:54 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , , References: <1696498986EFEC4D9153717DA325CB720265001D@vaebe104.NOE.Nokia.com> <096401c98b39$b4cab4f0$0600a8c0@china.huawei.com> <200902190804.n1J84M98018750@raisinbran.srv.cs.cmu.edu> Date: Wed, 25 Feb 2009 12:20:52 -0500 Message-ID: <0ad201c9976d$696f96c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmSxjeNZ7maGIV4T+Wxv0EdseDnzQEn3EHw Subject: Re: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 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: , X-List-Received-Date: Wed, 25 Feb 2009 17:20:34 -0000 Hi, By all means, please double check my logic on this ... comments inline. > > The one thing that's still slightly unclear is how tmStateReference > > cache entry gets created on SSH client side (e.g. command > originator). [...] > > In the expected case, it comes from TSM, in paragraph 4.2(2) of > draft-ietf-isms-transport-security-model-10.txt. > > However, modularity demands that SSHTM work even when not > used with TSM, > and particularly, section 6.1 of draft-ietf-isms-tmsm-15.txt > implies that > the sendMessage ASI needs to work even when tmStateReference > is not given. I do not believe that is true. The first step in secshell 5.1 verifies there is a valid tmStateReference cache. If not, processing stops. The sendMessage ASI is architectural, but the processing is (and must be) transport-model specific. The plain-old UDP "transport model" ignores the cache, and does a simple "Send SNMP Request Message to Network". When we update RFC3417, we will presumably want to add elements of procedure for the sendMessage ASI to replace "Send SNMP Request Message to Network". The TMSM does not specify that TSM must be used, but section 5.2 does say that "For architectural modularity between Transport Models and transport-aware Security Models, a fully-defined tmState MUST conceptually include at least the following fields:" and 6.1 says If present and valid, the tmStateReference refers to a cache containing transport-model-specific parameters for the transport and transport security. How a tmStateReference is determined to be present and valid is implementation-dependent. How the information in the cache is used is transport-model-dependent and implementation- dependent. > > > My guess is that Section 5.2 should say that if tmStateReference is > > not present, steps 1..3 are skipped, and instead we create a > > tmStateReference cache entry (because we can't call openSession > > without having one) and go to step 4 (opening a new session). I don't think SSHTM should ever reach step 4 without a tmStateReference. SSHTM is not designed to work with a security model that does not provide a tmStateReference. It would not be secure to do so. > > We don't need a tmStateReference cache entry to call openSession. The way it is currently defined you do, and I believe that is the correct approach. On the way in, it is the responsibility to take tmSecurityName and determine how to translate that into the approrpiate securityname for subsequent processing. The same is true going outbound - the security model should be decidiing which tmSecurityname should be getting used. It MAY be the same as the securityName passed in the ASIs, but it also MAY be different. We cannot make the assumption that they are the same. Creating a tmStateFerence cache using the securityName form the ASI makes that assumption. SSHTM should not generate an outgoing message without a valid tmStateReference provided by a security model. > I > believe the right behavior here is in fact to skip directly > to step 4, as > if there had been no LCD entry, and create a new SSH session. The > difficulty is that currently we can't call openSession without a > tmSecurityName, and we don't have one. I see two possible > solutions to > this problem: > > (1) redefine openSession (a private ASI between SSHTM and SSH) to not > require a tmSecurityName. In the case where > destTransportAddress does not > contain an '@' and tmSecurityName is not given, openSession > should not pass > any username to SSH. Instead, SSH will figure out on its own > what username > to use. Most SSH client implementations have heuristics for > this which are > quite often right; in the case of SSHTM-without-TSM, I'd expect these > heuristics to be at least as good as anything else we can do, > probably > including using the SNMP securityName. > > (2) redefine sendMessage to include the security model, name, > and level, so > that a secure transport can use them in setting up a session. > Then, if > there is no tmStateReference, pass the securityName parameter on to > openSession. > > > > Separately, I think we may have an issue in that sendMessage > currently > looks for the one-and-only existing session which matches > destTransportAddress and tmSecurityName, and then reports an error if > tmSameSecurity is true and the session ID does not match. Is > it possible > that there will be two different sessions with the same > transport address > and security ID? > If so, and even if not, it seems that it may be > appropriate to search for the one-and-only existing session > with the same > sessionID, and then verify that the transport address and > security name > match, rather than the other way around. The Elements of Procedure in pre14* revisions check for the sessionID match first, then for the tmTransportAddress and tmSecurityName match. 3. If tmSameSecurity is true and there is no existing session with the same sessionID as tmSessionID, then increment the sshtmSessionNoAvailableSessions counter, discard the message and return the error indication in the statusInformation. Processing of this message stops. 4. If there is no existing session corresponding to the tmTransportAddress and tmSecurityName, then call openSession() with the tmStateReference as a parameter. > > -- Jeff > From root@core3.amsl.com Wed Feb 25 11:45:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9B91B28C2A4; Wed, 25 Feb 2009 11:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090225194501.9B91B28C2A4@core3.amsl.com> Date: Wed, 25 Feb 2009 11:45:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-secshell-14.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: , X-List-Received-Date: Wed, 25 Feb 2009 19:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Transport Model for SNMP Author(s) : D. Harrington, et al. Filename : draft-ietf-isms-secshell-14.txt Pages : 41 Date : 2009-02-25 This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH). This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-14.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-secshell-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-25114305.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Feb 25 13:30:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 512763A6ACA; Wed, 25 Feb 2009 13:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090225213001.512763A6ACA@core3.amsl.com> Date: Wed, 25 Feb 2009 13:30:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-tmsm-16.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: , X-List-Received-Date: Wed, 25 Feb 2009 21:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Subsystem for the Simple Network Management Protocol (SNMP) Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-16.txt Pages : 42 Date : 2009-02-25 This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transports to include secure transports such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-16.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-25131558.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Feb 25 13:30:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 552CC3A6AA7; Wed, 25 Feb 2009 13:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090225213001.552CC3A6AA7@core3.amsl.com> Date: Wed, 25 Feb 2009 13:30:01 -0800 (PST) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-transport-security-model-11.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: , X-List-Received-Date: Wed, 25 Feb 2009 21:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Security Model for SNMP Author(s) : D. Harrington, W. Hardaker Filename : draft-ietf-isms-transport-security-model-11.txt Pages : 31 Date : 2009-02-25 This memo describes a Transport Security Model for the Simple Network Management Protocol. This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-11.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-transport-security-model-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-25131614.I-D@ietf.org> --NextPart-- From wjhns1@hardakers.net Wed Feb 25 16:36:51 2009 Return-Path: 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 781213A696F for ; Wed, 25 Feb 2009 16:36:51 -0800 (PST) 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 Y+tTvzSPgCZO for ; Wed, 25 Feb 2009 16:36:50 -0800 (PST) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id B20B33A6B1B for ; Wed, 25 Feb 2009 16:36:50 -0800 (PST) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id A404539A1E9; Wed, 25 Feb 2009 16:37:10 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <1696498986EFEC4D9153717DA325CB720265001D@vaebe104.NOE.Nokia.com> <096401c98b39$b4cab4f0$0600a8c0@china.huawei.com> <200902190804.n1J84M98018750@raisinbran.srv.cs.cmu.edu> <0ad201c9976d$696f96c0$0600a8c0@china.huawei.com> Date: Wed, 25 Feb 2009 16:37:10 -0800 In-Reply-To: <0ad201c9976d$696f96c0$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 25 Feb 2009 12:20:52 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 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: , X-List-Received-Date: Thu, 26 Feb 2009 00:36:51 -0000 >>>>> On Wed, 25 Feb 2009 12:20:52 -0500, "David Harrington" said: DH> By all means, please double check my logic on this ... I agree with what you've said... I think we can safely require that if you wish to use the SSH transport we require a SM above that passes down a tsmStateReference. We could probably work around that, but I'm not sure it's worth documenting for the standard. It doesn't make it "unmodular". It doesn't even prevent an implementation from doing it, because as we know implementations frequently don't exactly model the "an" v3 architecture but are still protocol-on-the-wire conferment. -- Wes Hardaker Sparta, Inc. From j.schoenwaelder@jacobs-university.de Wed Feb 25 23:52:49 2009 Return-Path: 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 11ADE28C257 for ; Wed, 25 Feb 2009 23:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.125, 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 ez9s1gFRzSEM for ; Wed, 25 Feb 2009 23:52:48 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0BA2C28C1DC for ; Wed, 25 Feb 2009 23:52:48 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0EA1C0009 for ; Thu, 26 Feb 2009 08:53:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id d1-jtRenl0M9; Thu, 26 Feb 2009 08:53:03 +0100 (CET) Received: from elstar.iuhb02.iu-bremen.de (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04C79C006C; Thu, 26 Feb 2009 08:53:03 +0100 (CET) Received: by elstar.iuhb02.iu-bremen.de (Postfix, from userid 501) id E5CF19AF979; Thu, 26 Feb 2009 08:53:01 +0100 (CET) Date: Thu, 26 Feb 2009 08:53:01 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] wg last call followup 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: , X-List-Received-Date: Thu, 26 Feb 2009 07:52:49 -0000 On November 4th 2008, I started WG last call on the ISMS document set: [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) [2] Transport Security Model for SNMP [3] Secure Shell Transport Model for SNMP [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models We received some comments and the subsequent mailing list discussions have led to some changes to the ISMS core documents. David just posted revised IDs of the core documents: [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) [2] Transport Security Model for SNMP [3] Secure Shell Transport Model for SNMP Please take a look at the changes. Let us know by March 6th if there are any major technical problems with the changes that must be fixed before submitting the documents to the AD for publication. Please keep in mind that we are going for Proposed Standard, the entry-level maturity level for the standards track. If you find editorial issues, please report them clearly marked as editorial issues. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jhutz@cmu.edu Thu Feb 26 15:55:54 2009 Return-Path: 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 A8A2928C197 for ; Thu, 26 Feb 2009 15:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.382, 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 Jn33-ZkQcPnn for ; Thu, 26 Feb 2009 15:55:53 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 733293A6A31 for ; Thu, 26 Feb 2009 15:55:53 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n1QNu9aE012495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Feb 2009 18:56:09 -0500 (EST) Date: Thu, 26 Feb 2009 18:56:09 -0500 From: Jeffrey Hutzelman To: David Harrington , Pasi.Eronen@nokia.com, isms@ietf.org Message-ID: <1665013C4D15CEB45A32105F@minbar.fac.cs.cmu.edu> In-Reply-To: <200902251720.n1PHKw5b025811@grapenut.srv.cs.cmu.edu> References: <1696498986EFEC4D9153717DA325CB720265001D@vaebe104.NOE.Nokia.com> <096401c98b39$b4cab4f0$0600a8c0@china.huawei.com> <200902190804.n1J84M98018750@raisinbran.srv.cs.cmu.edu> <200902251720.n1PHKw5b025811@grapenut.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: jhutz@cmu.edu Subject: Re: [Isms] Comments about draft-ietf-isms-secshell-13, Section 5 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: , X-List-Received-Date: Thu, 26 Feb 2009 23:55:54 -0000 --On Wednesday, February 25, 2009 12:20:52 PM -0500 David Harrington wrote: >> > The one thing that's still slightly unclear is how > tmStateReference >> > cache entry gets created on SSH client side (e.g. command >> originator). > [...] >> >> In the expected case, it comes from TSM, in paragraph 4.2(2) of >> draft-ietf-isms-transport-security-model-10.txt. >> >> However, modularity demands that SSHTM work even when not >> used with TSM, >> and particularly, section 6.1 of draft-ietf-isms-tmsm-15.txt >> implies that >> the sendMessage ASI needs to work even when tmStateReference >> is not given. > > I do not believe that is true. > The first step in secshell 5.1 verifies there is a valid > tmStateReference cache. If not, processing stops. > > The sendMessage ASI is architectural, but the processing is (and must > be) transport-model specific Yes, but the processing must be consistent with the defined semantics of the ASI. As currently defined, the tmStateReference parameter is not required to be "present and valid"; it could be not present or invalid, and that would be a legitimate call to sendMessage. Therefore, either sendMessage must behave reasonably without a tmStateReference, or it must be perfectly clear both that SSHTM's sendMessage requires the parameter be present and valid, and that the transport model architecture permits a transport model to impose such a requirement. > I don't think SSHTM should ever reach step 4 without a > tmStateReference. > SSHTM is not designed to work with a security model that does not > provide a tmStateReference. It would not be secure to do so. How could USM-over-SSHTM possibly be _less_ secure than USM-over-TCP? More generally, why would it be insecure to use SSHTM with a security model that does not provide a tmStateReference? I agree that it would be insecure to use SSHTM with TSM if the TSM didn't pass a tmStateReference when needed (particularly, when tmSameSecurity needs to be true). However, that would be due to a bug in the TSM implementation, not because using SSHTM without a tmStateReference is insecure. I would also agree that a TSM which fails to pass a tmStateReference when tmSameSecurity is _not_ true is buggy, because the TSM spec requires it to always do so. However, in the case of SSHTM, omitting tmStateReference is not even insecure; it just (probably) won't work, because the ssh connection won't get opened with the correct username and so the security names won't match on the other end. In short, a TSM which doesn't pass a tmStateReference is buggy, because TSM is required to pass one, and because doing so is required for the security of TSM in some cases. However, a security model which doesn't pass a tmStateReference to SSHTM is not automatically insecure; USM could care less what SSH username is used. >> We don't need a tmStateReference cache entry to call openSession. > > The way it is currently defined you do And I described a way in which it could be redefined such that knowledge of tmStateReference and of the cache entries is contained only within sendMessage and is not needed in openSession, by passing down the SSH username to use instead of the tmStateReference. Note that I did _not_ suggest attempting to derive the ssh username from the securityName passed in the ASI's. I suggested that it be left unspecified, leaving the SSH layer free to figure it out on its own. The reasoning is that if you're not using a security model which depends on the transport model using a particular tmSecurityName (and thus on SSH using a particular username), then the SSH layer's guess is likely to be at least as good as SNMP's, and possibly quite a lot better. For example, suppose I use some management app on my desktop computer to send commands to SNMP agents on a variety of remote systems. For some reason, I decide I want to use USM over SSHTM to talk to some of those systems. In that case, the app is probably using an SNMP library whose SSHTM implementation works by calling out to whatever SSH implementation is already on the machine. After all, that's one of the reasons for reusing SSH. Now, that SSH implementation, if not given a username, is likely to do something like assume that it should use my local username, and my existing ssh keys (or whatever other credentials). Chances are, every device I want to talk to falls into one of two categories. Either the SSH default behavior works, or _nothing_ will work. > SSHTM should not generate an outgoing message without a valid > tmStateReference provided by a security model. SSHTM doesn't generate outgoing messages. It transports messages provided by someone else. Again, why is it bad or insecure for SSHTM to transport messages without a valid tmStateReference? I think perhaps you're conflating two things here. It's insecure to use TSM without a transport that _uses_ tmStateReference. It's not insecure to use SSHTM without an SM that _provides_ it. ========== All of that said, I think I'd be OK with simply imposing the requirement that SSHTM must only be used with TSM or another transport-aware security model which passes tmStateReference, and then requiring that tmStateReference always be present and valid. However, if we want to do that, then SSHTM needs to _say_ that tmStateReference must always be present and valid. Also, the transport model document (where did "TMSM" come from, anyway?) needs to make it clear that a transport model MAY impose this requirement. Conceptually, such a requirement must be visible across the abstraction (you have to _know_ that this SM meets the requirements of that TM), and TMSM defines that abstraction. ========== > The Elements of Procedure in pre14* revisions check for the sessionID > match first, then for the tmTransportAddress and tmSecurityName match. > > 3. If tmSameSecurity is true and there is no existing session with > the same sessionID as tmSessionID, then increment the > sshtmSessionNoAvailableSessions counter, discard the message > and > return the error indication in the statusInformation. > Processing > of this message stops. > > 4. If there is no existing session corresponding to the > tmTransportAddress and tmSecurityName, then call openSession() > with the tmStateReference as a parameter. Not quite; I think maybe there is a step needed in between.... - Step 3 quoted above is good as far as it goes. - If tmSameSecurity is true and there _was_ an existing session found, then the tmTransportAddress and tmSecurityName must _also_ match, or processing stops in the same way described in step 3. - If tmSameSecurity was _not_ true, then we still need to look for an existing session matching tmTransportAddress and tmSecurityName prior to step 4. Except I'm not sure if that's right.... If tmSameSecurity is not true, do we want to reuse an existing session ever, or always create a new one? We may have already discussed this, but I don't recall the answer. From ietfdbh@comcast.net Wed Feb 25 09:38:24 2009 Return-Path: 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 F07A83A684A for ; Wed, 25 Feb 2009 09:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_12=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 aQTGI52nGbXj for ; Wed, 25 Feb 2009 09:38:19 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id DA7173A68E4 for ; Wed, 25 Feb 2009 09:38:18 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA08.westchester.pa.mail.comcast.net with comcast id LBPA1b0010Fqzac58Heg3w; Wed, 25 Feb 2009 17:38:40 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA08.westchester.pa.mail.comcast.net with comcast id LHfR1b00L0UQ6dC3UHfRRk; Wed, 25 Feb 2009 17:39:26 +0000 From: "David Harrington" To: Date: Wed, 25 Feb 2009 12:38:37 -0500 Message-ID: <0ad901c9976f$e406e170$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0ADA_01C99745.FB30D970" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcmXb+OllWFVPbWYTXa8uKj4SHgpAQ== X-Mailman-Approved-At: Fri, 27 Feb 2009 11:16:00 -0800 Subject: [Isms] draft-ietf-isms-tmsm-16.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: , X-List-Received-Date: Wed, 25 Feb 2009 17:38:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0ADA_01C99745.FB30D970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com ------=_NextPart_000_0ADA_01C99745.FB30D970 Content-Type: text/plain; name="draft-ietf-isms-tmsm-16.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-isms-tmsm-16.txt" =0A= =0A= =0A= Network Working Group D. Harrington=0A= Internet-Draft Huawei Technologies (USA)=0A= Updates: 3411,3412,3414,3417 J. Schoenwaelder=0A= (if approved) Jacobs University Bremen=0A= Intended status: Standards Track February 25, 2009=0A= Expires: August 29, 2009=0A= =0A= =0A= Transport Subsystem for the Simple Network Management Protocol (SNMP)=0A= draft-ietf-isms-tmsm-16=0A= =0A= Status of This Memo=0A= =0A= This Internet-Draft is submitted to IETF in full conformance with the=0A= provisions of BCP 78 and BCP 79. This document may contain material=0A= from IETF Documents or IETF Contributions published or made publicly=0A= available before November 10, 2008. The person(s) controlling the=0A= copyright in some of this material may not have granted the IETF=0A= Trust the right to allow modifications of such material outside the=0A= IETF Standards Process. Without obtaining an adequate license from=0A= the person(s) controlling the copyright in such materials, this=0A= document may not be modified outside the IETF Standards Process, and=0A= derivative works of it may not be created outside the IETF Standards=0A= Process, except to format it for publication as an RFC or to=0A= translate it into languages other than English.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on August 29, 2009.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2009 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 1]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents in effect on the date of=0A= publication of this document (http://trustee.ietf.org/license-info).=0A= Please review these documents carefully, as they describe your rights=0A= and restrictions with respect to this document.=0A= =0A= Abstract=0A= =0A= This document defines a Transport Subsystem, extending the Simple=0A= Network Management Protocol (SNMP) architecture defined in RFC 3411.=0A= This document defines a subsystem to contain Transport Models,=0A= comparable to other subsystems in the RFC3411 architecture. As work=0A= is being done to expand the transports to include secure transports=0A= such as SSH and TLS, using a subsystem will enable consistent design=0A= and modularity of such Transport Models. This document identifies=0A= and describes some key aspects that need to be considered for any=0A= Transport Model for SNMP.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.1. The Internet-Standard Management Framework . . . . . . . . 4=0A= 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 1.3. Where this Extension Fits . . . . . . . . . . . . . . . . 4=0A= 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 3. Requirements of a Transport Model . . . . . . . . . . . . . . 8=0A= 3.1. Message Security Requirements . . . . . . . . . . . . . . 8=0A= 3.1.1. Security Protocol Requirements . . . . . . . . . . . . 8=0A= 3.2. SNMP Requirements . . . . . . . . . . . . . . . . . . . . 8=0A= 3.2.1. Architectural Modularity Requirements . . . . . . . . 9=0A= 3.2.2. Access Control Requirements . . . . . . . . . . . . . 12=0A= 3.2.3. Security Parameter Passing Requirements . . . . . . . 13=0A= 3.2.4. Separation of Authentication and Authorization . . . . 13=0A= 3.3. Session Requirements . . . . . . . . . . . . . . . . . . . 14=0A= 3.3.1. No SNMP Sessions . . . . . . . . . . . . . . . . . . . 14=0A= 3.3.2. Session Establishment Requirements . . . . . . . . . . 15=0A= 3.3.3. Session Maintenance Requirements . . . . . . . . . . . 16=0A= 3.3.4. Message security versus session security . . . . . . . 16=0A= 4. Scenario Diagrams and the Transport Subsystem . . . . . . . . 17=0A= 5. Cached Information and References . . . . . . . . . . . . . . 17=0A= 5.1. securityStateReference . . . . . . . . . . . . . . . . . . 18=0A= 5.2. tmStateReference . . . . . . . . . . . . . . . . . . . . . 18=0A= 5.2.1. Transport information . . . . . . . . . . . . . . . . 19=0A= 5.2.2. securityName . . . . . . . . . . . . . . . . . . . . . 19=0A= 5.2.3. securityLevel . . . . . . . . . . . . . . . . . . . . 20=0A= 5.2.4. Session Information . . . . . . . . . . . . . . . . . 21=0A= 6. Abstract Service Interfaces . . . . . . . . . . . . . . . . . 21=0A= 6.1. sendMessage ASI . . . . . . . . . . . . . . . . . . . . . 22=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 2]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= 6.2. Changes to RFC3411 Outgoing ASIs . . . . . . . . . . . . . 22=0A= 6.2.1. Message Processing Subsystem Primitives . . . . . . . 22=0A= 6.2.2. Security Subsystem Primitives . . . . . . . . . . . . 24=0A= 6.3. The receiveMessage ASI . . . . . . . . . . . . . . . . . . 25=0A= 6.4. Changes to RFC3411 Incoming ASIs . . . . . . . . . . . . . 26=0A= 6.4.1. Message Processing Subsystem Primitive . . . . . . . . 26=0A= 6.4.2. Security Subsystem Primitive . . . . . . . . . . . . . 27=0A= 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28=0A= 7.1. Coexistence, Security Parameters, and Access Control . . . 29=0A= 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30=0A= 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31=0A= 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31=0A= 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31=0A= 10.2. Informative References . . . . . . . . . . . . . . . . . . 32=0A= Appendix A. Why tmStateReference? . . . . . . . . . . . . . . . . 34=0A= A.1. Define an Abstract Service Interface . . . . . . . . . . . 34=0A= A.2. Using an Encapsulating Header . . . . . . . . . . . . . . 34=0A= A.3. Modifying Existing Fields in an SNMP Message . . . . . . . 35=0A= A.4. Using a Cache . . . . . . . . . . . . . . . . . . . . . . 35=0A= Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 35=0A= Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 3]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= 1. Introduction=0A= =0A= This document defines a Transport Subsystem, extending the Simple=0A= Network Management Protocol (SNMP) architecture defined in [RFC3411].=0A= This document identifies and describes some key aspects that need to=0A= be considered for any Transport Model for SNMP.=0A= =0A= 1.1. The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the current=0A= Internet-Standard Management Framework, please refer to section 7 of=0A= RFC 3410 [RFC3410].=0A= =0A= 1.2. Conventions=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC 2119 [RFC2119].=0A= =0A= Non uppercased versions of the keywords should be read as in normal=0A= English. They will usually, but not always, be used in a context=0A= relating to compatibility with the RFC3411 architecture or the=0A= subsystem defined here, but which might have no impact on on-the-wire=0A= compatibility. These terms are used as guidance for designers of=0A= proposed IETF models to make the designs compatible with RFC3411=0A= subsystems and Abstract Service Interfaces (ASIs) (see section 3.2).=0A= Implementers are free to implement differently. Some usages of these=0A= lowercase terms are simply normal English usage.=0A= =0A= For consistency with SNMP-related specifications, this document=0A= favors terminology as defined in STD62 rather than favoring=0A= terminology that is consistent with non-SNMP specifications that use=0A= different variations of the same terminology. This is consistent=0A= with the IESG decision to not require the SNMPv3 terminology be=0A= modified to match the usage of other non-SNMP specifications when=0A= SNMPv3 was advanced to Full Standard.=0A= =0A= 1.3. Where this Extension Fits=0A= =0A= It is expected that readers of this document will have read RFC3410=0A= and RFC3411, and have a general understanding of the functionality=0A= defined in RFCs 3412-3418.=0A= =0A= The "Transport Subsystem" is an additional component for the SNMP=0A= Engine depicted in RFC3411, section 3.1.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 4]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= The following diagram depicts its place in the RFC3411 architecture.:=0A= =0A= +-------------------------------------------------------------------+=0A= | SNMP entity |=0A= | |=0A= | +-------------------------------------------------------------+ |=0A= | | SNMP engine (identified by snmpEngineID) | |=0A= | | | |=0A= | | +------------+ | |=0A= | | | Transport | | |=0A= | | | Subsystem | | |=0A= | | +------------+ | |=0A= | | | |=0A= | | +------------+ +------------+ +-----------+ +-----------+ | |=0A= | | | Dispatcher | | Message | | Security | | Access | | |=0A= | | | | | Processing | | Subsystem | | Control | | |=0A= | | | | | Subsystem | | | | Subsystem | | |=0A= | | +------------+ +------------+ +-----------+ +-----------+ | |=0A= | +-------------------------------------------------------------+ |=0A= | |=0A= | +-------------------------------------------------------------+ |=0A= | | Application(s) | |=0A= | | | |=0A= | | +-------------+ +--------------+ +--------------+ | |=0A= | | | Command | | Notification | | Proxy | | |=0A= | | | Generator | | Receiver | | Forwarder | | |=0A= | | +-------------+ +--------------+ +--------------+ | |=0A= | | | |=0A= | | +-------------+ +--------------+ +--------------+ | |=0A= | | | Command | | Notification | | Other | | |=0A= | | | Responder | | Originator | | | | |=0A= | | +-------------+ +--------------+ +--------------+ | |=0A= | +-------------------------------------------------------------+ |=0A= | |=0A= +-------------------------------------------------------------------+=0A= =0A= =0A= The transport mappings defined in RFC3417 do not provide lower-layer=0A= security functionality, and thus do not provide transport-specific=0A= security parameters. This document updates RFC3411 and RFC3417 by=0A= defining an architectural extension and modifying the ASIs that=0A= transport mappings (hereafter called transport models) can use to=0A= pass transport-specific security parameters to other subsystems,=0A= including transport-specific security parameters that are translated=0A= into the transport-independent securityName and securityLevel=0A= parameters=0A= =0A= The Transport Security Model [I-D.ietf-isms-transport-security-model]=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 5]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= and the Secure Shell Transport Model [I-D.ietf-isms-secshell] utilize=0A= the Transport Subsystem. The Transport Security Model is an=0A= alternative to the existing SNMPv1 Security Model [RFC3584], the=0A= SNMPv2c Security Model [RFC3584], and the User-based Security Model=0A= [RFC3414]. The Secure Shell Transport Model is an alternative to=0A= existing transport mappings as described in [RFC3417].=0A= =0A= 2. Motivation=0A= =0A= Just as there are multiple ways to secure one's home or business, in=0A= a continuum of alternatives, there are multiple ways to secure a=0A= network management protocol. Let's consider three general=0A= approaches.=0A= =0A= In the first approach, an individual could sit on his front porch=0A= waiting for intruders. In the second approach, he could hire an=0A= employee , schedule the employee, position the employee to guard what=0A= he wants protected, hire a second guard to cover if the first gets=0A= sick, and so on. In the third approach, he could hire a security=0A= company, tell them what he wants protected, and leave the details to=0A= them. Considerations of hiring and training employees, positioning=0A= and scheduling the guards, arranging for cover, etc., are the=0A= responsibility of the security company. The individual therefore=0A= achieves the desired security, with no significant effort on his part=0A= other than identifying requirements and verifying the quality of=0A= service being provided.=0A= =0A= The User-based Security Model (USM) as defined in [RFC3414] largely=0A= uses the first approach - it provides its own security. It utilizes=0A= existing mechanisms (e.g., SHA), but provides all the coordination.=0A= USM provides for the authentication of a principal, message=0A= encryption, data integrity checking, timeliness checking, etc.=0A= =0A= USM was designed to be independent of other existing security=0A= infrastructures. USM therefore requires a separate principal and key=0A= management infrastructure. Operators have reported that deploying=0A= another principal and key management infrastructure in order to use=0A= SNMPv3 is a deterrent to deploying SNMPv3. It is possible to use=0A= external mechanisms to handle the distribution of keys for use by=0A= USM. The more important issue is that operators wanted to leverage=0A= existing user base infrastructures that were not specific to SNMP.=0A= =0A= A USM-compliant architecture might combine the authentication=0A= mechanism with an external mechanism, such as RADIUS [RFC2865] to=0A= provide the authentication service. Similarly it might be possible=0A= to utilize an external protocol to encrypt a message, to check=0A= timeliness, to check data integrity, etc. However this corresponds=0A= to the second approach - requiring the coordination of a number of=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 6]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= differently subcontracted services. Building solid security between=0A= the various services is difficult, and there is a significant=0A= potential for gaps in security.=0A= =0A= An alternative approach might be to utilize one or more lower-layer=0A= security mechanisms to provide the message-oriented security services=0A= required. These would include authentication of the sender,=0A= encryption, timeliness checking, and data integrity checking. This=0A= corresponds to the third approach described above. There are a=0A= number of IETF standards available or in development to address these=0A= problems through security layers at the transport layer or=0A= application layer, among them TLS [RFC5246], SASL [RFC4422], and SSH=0A= [RFC4251]=0A= =0A= From an operational perspective, it is highly desirable to use=0A= security mechanisms that can unify the administrative security=0A= management for SNMPv3, command line interfaces (CLIs) and other=0A= management interfaces. The use of security services provided by=0A= lower layers is the approach commonly used for the CLI, and is also=0A= the approach being proposed for other network management protocols,=0A= such as syslog [I-D.ietf-syslog-protocol] and NETCONF [RFC4741].=0A= =0A= This document defines a Transport Subsystem extension to the RFC3411=0A= architecture based on the third approach. This extension specifies=0A= how other lower layer protocols with common security infrastructures=0A= can be used underneath the SNMP protocol and the desired goal of=0A= unified administrative security can be met.=0A= =0A= This extension allows security to be provided by an external protocol=0A= connected to the SNMP engine through an SNMP Transport Model=0A= [RFC3417]. Such a Transport Model would then enable the use of=0A= existing security mechanisms such as (TLS) [RFC5246] or SSH [RFC4251]=0A= within the RFC3411 architecture.=0A= =0A= There are a number of Internet security protocols and mechanisms that=0A= are in wide spread use. Many of them try to provide a generic=0A= infrastructure to be used by many different application layer=0A= protocols. The motivation behind the Transport Subsystem is to=0A= leverage these protocols where it seems useful.=0A= =0A= There are a number of challenges to be addressed to map the security=0A= provided by a secure transport into the SNMP architecture so that=0A= SNMP continues to provide interoperability with existing=0A= implementations. These challenges are described in detail in this=0A= document. For some key issues, design choices are described that=0A= might be made to provide a workable solution that meets operational=0A= requirements and fits into the SNMP architecture defined in=0A= [RFC3411].=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 7]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= 3. Requirements of a Transport Model=0A= =0A= 3.1. Message Security Requirements=0A= =0A= Transport security protocols SHOULD provide protection against the=0A= following message-oriented threats:=0A= =0A= 1. modification of information=0A= =0A= 2. masquerade=0A= =0A= 3. message stream modification=0A= =0A= 4. disclosure=0A= =0A= These threats are described in section 1.4 of [RFC3411]. It is not=0A= required to protect against denial of service or traffic analysis,=0A= but it should not make those threats significantly worse.=0A= =0A= 3.1.1. Security Protocol Requirements=0A= =0A= There are a number of standard protocols that could be proposed as=0A= possible solutions within the Transport Subsystem. Some factors=0A= should be considered when selecting a protocol.=0A= =0A= Using a protocol in a manner for which it was not designed has=0A= numerous problems. The advertised security characteristics of a=0A= protocol might depend on it being used as designed; when used in=0A= other ways, it might not deliver the expected security=0A= characteristics. It is recommended that any proposed model include a=0A= description of the applicability of the Transport Model.=0A= =0A= A Transport Model SHOULD NOT require modifications to the underlying=0A= protocol. Modifying the protocol might change its security=0A= characteristics in ways that could impact other existing usages. If=0A= a change is necessary, the change SHOULD be an extension that has no=0A= impact on the existing usages. Any Transport Model SHOULD include a=0A= description of potential impact on other usages of the protocol.=0A= =0A= Since multiple transport models can exist simultaneously within the=0A= transport subsystem, transport models MUST be able to coexist with=0A= each other.=0A= =0A= 3.2. SNMP Requirements=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 8]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= 3.2.1. Architectural Modularity Requirements=0A= =0A= SNMP version 3 (SNMPv3) is based on a modular architecture (defined=0A= in [RFC3411] section 3) to allow the evolution of the SNMP protocol=0A= standards over time, and to minimize side effects between subsystems=0A= when changes are made.=0A= =0A= The RFC3411 architecture includes a Message Processing Subsystem=0A= permitting different message versions to be handled by a single=0A= engine, a Security Subsystem for enabling different methods of=0A= providing security services, Applications(s) to support different=0A= types of application processors, and an Access Control Subsystem for=0A= allowing multiple approaches to access control. The RFC3411=0A= architecture does not include a subsystem for Transport Models,=0A= despite the fact there are multiple transport mappings already=0A= defined for SNMP. This document describes a Transport Subsystem that=0A= is compatible with the RFC3411 architecture. As work is being done=0A= to use secure transports such as SSH and TLS, using a subsystem will=0A= enable consistent design and modularity of such Transport Models.=0A= =0A= The design of this Transport Subsystem accepts the goals of the=0A= RFC3411 architecture defined in section 1.5 of [RFC3411]. This=0A= Transport Subsystem uses a modular design that permits Transport=0A= Models (which may or may not be security-aware) to be "plugged into"=0A= the RFC3411 architecture . Such Transport Models would be=0A= independent of other modular SNMP components as much as possible.=0A= This design also permits Transport Models to be advanced through the=0A= standards process independently of other Transport Models.=0A= =0A= To encourage a basic level of interoperability, any Transport Model=0A= SHOULD define one mandatory-to-implement security mechanism, but=0A= should also be able to support additional existing and new=0A= mechanisms.=0A= =0A= The following diagram depicts the SNMPv3 architecture including the=0A= new Transport Subsystem defined in this document, and a new Transport=0A= Security Model defined in [I-D.ietf-isms-transport-security-model].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 9]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= +------------------------------+=0A= | Network |=0A= +------------------------------+=0A= ^ ^ ^=0A= | | |=0A= v v v=0A= +-------------------------------------------------------------------+=0A= | +--------------------------------------------------+ |=0A= | | Transport Subsystem | |=0A= | | +-----+ +-----+ +-----+ +-----+ +-------+ | |=0A= | | | UDP | | TCP | | SSH | | TLS | . . . | other | | |=0A= | | +-----+ +-----+ +-----+ +-----+ +-------+ | |=0A= | +--------------------------------------------------+ |=0A= | ^ |=0A= | | |=0A= | Dispatcher v |=0A= | +-------------------+ +---------------------+ +----------------+ |=0A= | | Transport | | Message Processing | | Security | |=0A= | | Dispatch | | Subsystem | | Subsystem | |=0A= | | | | +------------+ | | +------------+ | |=0A= | | | | +->| v1MP |<--->| | USM | | |=0A= | | | | | +------------+ | | +------------+ | |=0A= | | | | | +------------+ | | +------------+ | |=0A= | | | | +->| v2cMP |<--->| | Transport | | |=0A= | | Message | | | +------------+ | | | Security | | |=0A= | | Dispatch <--------->| +------------+ | | | Model | | |=0A= | | | | +->| v3MP |<--->| +------------+ | |=0A= | | | | | +------------+ | | +------------+ | |=0A= | | PDU Dispatch | | | +------------+ | | | Other | | |=0A= | +-------------------+ | +->| otherMP |<--->| | Model(s) | | |=0A= | ^ | +------------+ | | +------------+ | |=0A= | | +---------------------+ +----------------+ |=0A= | v |=0A= | +-------+-------------------------+---------------+ |=0A= | ^ ^ ^ |=0A= | | | | |=0A= | v v v |=0A= | +-------------+ +---------+ +--------------+ +-------------+ |=0A= | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | |=0A= | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |=0A= | | application | | | | applications | | application | |=0A= | +-------------+ +---------+ +--------------+ +-------------+ |=0A= | ^ ^ |=0A= | | | |=0A= | v v |=0A= | +----------------------------------------------+ |=0A= | | MIB instrumentation | SNMP entity |=0A= +-------------------------------------------------------------------+=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 10]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= 3.2.1.1. Changes to the RFC3411 Architecture=0A= =0A= The RFC3411 architecture and the Security Subsystem assume that a=0A= Security Model is called by a Message Processing Model and will=0A= perform multiple security functions within the Security Subsystem. A=0A= Transport Model that supports a secure transport protocol might=0A= perform similar security functions within the Transport Subsystem,=0A= including the translation of transport security parameters to/from=0A= security-model-independent parameters.=0A= =0A= To accommodate this, an implementation-specific cache of transport-=0A= specific information will be described (not shown), and the data=0A= flows on this path will be extended to pass security-model-=0A= independent values. This document amends some of the ASIs defined in=0A= RFC 3411, and these changes are covered in section 6.=0A= =0A= New Security Models may be defined that understand how to work with=0A= these modified ASIs and the transport-information cache. One such=0A= Security Model, the Transport Security Model, is defined in=0A= [I-D.ietf-isms-transport-security-model].=0A= =0A= 3.2.1.2. Changes to RFC3411 processing=0A= =0A= The introduction of secure transports affects the responsibilities=0A= and order of processing within the RFC3411 architecture. While the=0A= steps are the same, they may occur in a different order, and may be=0A= done by different subsystems. With the existing RFC3411=0A= architecture, security processing starts when the Message Processing=0A= Model decodes portions of the encoded message to extract parameters=0A= that identify which Security Model should handle the security-related=0A= tasks.=0A= =0A= A secure transport performs those security functions on the message,=0A= before the message is decoded. Some of these functions might then be=0A= repeated by the selected Security Model.=0A= =0A= 3.2.1.3. Passing Information between SNMP Engines=0A= =0A= A secure Transport Model will establish an authenticated and possibly=0A= encrypted tunnel between the Transport Models of two SNMP engines.=0A= After a transport layer tunnel is established, then SNMP messages can=0A= be sent through the tunnel from one SNMP engine to the other.=0A= Transport Models MAY support sending multiple SNMP messages through=0A= the same tunnel.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 11]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= 3.2.2. Access Control Requirements=0A= =0A= RFC3411 made some design decisions related to the support of an=0A= Access Control Subsystem. These include establishing and passing in=0A= a model-independent manner the securityModel, securityName and=0A= securityLevel parameters, and separating message authentication from=0A= data access authorization.=0A= =0A= 3.2.2.1. securityName and securityLevel Mapping=0A= =0A= SNMP data access controls are expected to work on the basis of who=0A= can perform what operations on which subsets of data, and based on=0A= the security services that will be provided to secure the data in=0A= transit. The securityModel and securityLevel parameters establish=0A= the protections for transit - whether authentication and privacy=0A= services will be or have been applied to the message. The=0A= securityName is a model-independent identifier of the security=0A= "principal".=0A= =0A= A Security Model plays a role in security that goes beyond protecting=0A= the message - it provides a mapping between the security-model-=0A= specific principal for an incoming message to a security-model=0A= independent securityName which can be used for subsequent processing,=0A= such as for access control. The securityName is mapped from a=0A= mechanism-specific identity, and this mapping must be done for=0A= incoming messages by the Security Model before it passes securityName=0A= to the Message Processing Model via the processIncoming ASI.=0A= =0A= A Security Model is also responsible to specify, via the=0A= securityLevel parameter, whether incoming messages have been=0A= authenticated and encrypted, and to ensure that outgoing messages are=0A= authenticated and encrypted based on the value of securityLevel.=0A= =0A= A Transport Model MAY provide suggested values for securityName and=0A= securityLevel. A Security Model may have multiple sources for=0A= determining the principal and desired security services, and a=0A= particular Security Model may or may not utilize the values proposed=0A= by a Transport Model when deciding the value of securityName and=0A= securityLevel.=0A= =0A= Documents defining a new transport domain MUST define a prefix that=0A= MAY be prepended by the Security Model to all passed securityNames.=0A= The prefix MUST include from one to four ASCII characters, not=0A= including a ":" (ASCII 0x3a) character. If a prefix is used, a=0A= securityName is constructed by concatenating the prefix and a ":"=0A= (ASCII 0x3a) character followed by a non-empty identity in an=0A= snmpAdminString compatible format. Transport domains and their=0A= corresponding prefixes are coordinated via the IANA registry "SNMP=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 12]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= Transport Domains".=0A= =0A= 3.2.3. Security Parameter Passing Requirements=0A= =0A= A Message Processing Model might unpack SNMP-specific security=0A= parameters from an incoming message before calling a specific=0A= Security Model to handle the security-related processing of the=0A= message. When using a secure Transport Model, some security=0A= parameters might be extracted from the transport layer by the=0A= Transport Model before the message is passed to the Message=0A= Processing Subsystem.=0A= =0A= This document describes a cache mechanism (see Section 5), into which=0A= the Transport Model puts information about the transport and security=0A= parameters applied to a transport connection or an incoming message,=0A= and a Security Model may extract that information from the cache. A=0A= tmStateReference is passed as an extra parameter in the ASIs between=0A= the Transport Subsystem, the Message Processing and Security=0A= Subsystems, to identify the relevant cache. This approach of passing=0A= a model-independent reference is consistent with the=0A= securityStateReference cache already being passed around in the=0A= RFC3411 ASIs.=0A= =0A= 3.2.4. Separation of Authentication and Authorization=0A= =0A= The RFC3411 architecture defines a separation of authentication and=0A= the authorization to access and/or modify MIB data. A set of model-=0A= independent parameters (securityModel, securityName, and=0A= securityLevel) are passed between the Security Subsystem, the=0A= applications, and the Access Control Subsystem.=0A= =0A= This separation was a deliberate decision of the SNMPv3 WG, to allow=0A= support for authentication protocols which do not provide data access=0A= authorization capabilities, and to support data access authorization=0A= schemes, such as VACM, that do not perform their own authentication.=0A= =0A= A Message Processing Model determines which Security Model is used,=0A= either based on the message version, e.g., SNMPv1 and SNMPv2c, or=0A= possibly by a value specified in the message, e.g., msgSecurityModel=0A= field in SNMPv3.=0A= =0A= The Security Model makes the decision which securityName and=0A= securityLevel values are passed as model-independent parameters to an=0A= application, which then passes them via the isAccessAllowed ASI to=0A= the Access Control Subsystem.=0A= =0A= An Access Control Model performs the mapping from the model-=0A= independent security parameters to a policy within the Access Control=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 13]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= Model that is access-control-model-dependent.=0A= =0A= A Transport Model does not know which Security Model will be used for=0A= an incoming message, so cannot know how the securityName and=0A= securityLevel parameters will be determined. It can propose an=0A= authenticated identity (via the tmSecurityName field), but there is=0A= no guarantee that this value will be used by the Security Model. For=0A= example, non-transport-aware Security Models will typically determine=0A= the securityName (and securityLevel) based on the contents of the=0A= SNMP message itself. Such Security Models will simply not know that=0A= the tmStateReference cache exists.=0A= =0A= Further, even if the Transport Model can influence the choice of=0A= securityName, it cannot directly determine the authorization allowed=0A= to this identity. If two different Transport Models each=0A= authenticate a transport principal, that are then both mapped to the=0A= same securityName, then these two identities will typically be=0A= afforded exactly the same authorization by the Access Control Model.=0A= =0A= The only way for the Access Control Model to differentiate between=0A= identities based on the underlying Transport Model, would be for such=0A= transport-authenticated identities to be mapped to distinct=0A= securityNames. How and if this is done is Security-Model-dependent.=0A= =0A= 3.3. Session Requirements=0A= =0A= Some secure transports have a notion of sessions, while other secure=0A= transports provide channels or other session-like mechanism.=0A= Throughout this document, the term session is used in a broad sense=0A= to cover transport sessions, transport channels, and other transport-=0A= layer session-like mechanisms. Transport-layer sessions that can=0A= secure multiple SNMP messages within the lifetime of the session are=0A= considered desirable because the cost of authentication can be=0A= amortized over potentially many transactions. How a transport=0A= session is actually established, opened, closed, or maintained is=0A= specific to a particular Transport Model.=0A= =0A= To reduce redundancy, this document describes aspects that are=0A= expected to be common to all Transport Model sessions.=0A= =0A= 3.3.1. No SNMP Sessions=0A= =0A= The architecture defined in [RFC3411] and the Transport Subsystem=0A= defined in this document do not support SNMP sessions or include a=0A= session selector in the Abstract Service Interfaces.=0A= =0A= The Transport Subsystem may support transport sessions. However, the=0A= transport subsystem does not have access to the pduType, so cannot=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 14]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= select a given transport session for particular types of traffic.=0A= =0A= Certain parameters of these ASIs might be used to guide the selection=0A= of an appropriate transport session to use for a given request by an=0A= application.=0A= =0A= The transportDomain and transportAddress identify the transport=0A= connection to a remote network node. Elements of the transport=0A= address (such as the port number) might be used by an application to=0A= send a particular PDU type to a particular transport address.=0A= =0A= The securityName identifies which security principal to communicate=0A= with at that address (e.g., different NMS applications), and the=0A= securityLevel might permit selection of different sets of security=0A= properties for different purposes (e.g., encrypted SETs vs. non-=0A= encrypted GETs).=0A= =0A= However, because the handling of transport sessions is specific to=0A= each transport model, some transport models MAY restrict selecting a=0A= particular transport session.=0A= =0A= An application might use a unique combination of transportDomain,=0A= transportAddress, securityModel, securityName, and securityLevel to=0A= try to force the selection of a given transport session. This usage=0A= is NOT RECOMMENDED because it is not guaranteed to be interoperable=0A= across implementatioins and across models.=0A= =0A= Implementations SHOULD be able to maintain some reasonable number of=0A= concurrent transport sessions, and MAY provide non-standard internal=0A= mechanisms to select transport sessions.=0A= =0A= 3.3.2. Session Establishment Requirements=0A= =0A= SNMP applications provide the transportDomain, transportAddress,=0A= securityName, and securityLevel to be used to create a new session.=0A= =0A= If the Transport Model cannot provide at least the requested level of=0A= security, the Transport Model SHOULD discard the message and SHOULD=0A= notify the dispatcher that establishing a session and sending the=0A= message failed. Similarly, if the session cannot be established,=0A= then the message SHOULD be discarded and the dispatcher notified.=0A= =0A= Transport session establishment might require provisioning=0A= authentication credentials at an engine, either statically or=0A= dynamically. How this is done is dependent on the transport model=0A= and the implementation.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 15]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= 3.3.3. Session Maintenance Requirements=0A= =0A= A Transport Model can tear down sessions as needed. It might be=0A= necessary for some implementations to tear down sessions as the=0A= result of resource constraints, for example.=0A= =0A= The decision to tear down a session is implementation-dependent. How=0A= an implementation determines that an operation has completed is=0A= implementation-dependent. While it is possible to tear down each=0A= transport session after processing for each message has completed,=0A= this is not recommended for performance reasons.=0A= =0A= The elements of procedure describe when cached information can be=0A= discarded, and the timing of cache cleanup might have security=0A= implications, but cache memory management is an implementation issue.=0A= =0A= If a Transport Model defines MIB module objects to maintain session=0A= state information, then the Transport Model MUST define what SHOULD=0A= happen to the objects when a related session is torn down, since this=0A= will impact interoperability of the MIB module.=0A= =0A= 3.3.4. Message security versus session security=0A= =0A= A Transport Model session is associated with state information that=0A= is maintained for its lifetime. This state information allows for=0A= the application of various security services to multiple messages.=0A= Cryptographic keys associated with the transport session SHOULD be=0A= used to provide authentication, integrity checking, and encryption=0A= services, as needed, for data that is communicated during the=0A= session. The cryptographic protocols used to establish keys for a=0A= Transport Model session SHOULD ensure that fresh new session keys are=0A= generated for each session. This would ensure that a cross-session=0A= replay attack would be unsuccessful; that is, an attacker could not=0A= take a message observed on one session, and successfully replay this=0A= on another session.=0A= =0A= A good security protocol would also protect against replay attacks=0A= within a session; that is, an attacker could not take a message=0A= observed on a session, and successfully replay this later in the same=0A= session. One approach would be to use sequence information within=0A= the protocol, allowing the participants to detect if messages were=0A= replayed or reordered within a session.=0A= =0A= If a secure transport session is closed between the time a request=0A= message is received, and the corresponding response message is sent,=0A= then the response message SHOULD be discarded, even if a new session=0A= has been established. The SNMPv3 WG decided that this should be a=0A= SHOULD architecturally, and it is a security-model-specific decision=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 16]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= whether to REQUIRE this.=0A= =0A= SNMPv3 was designed to support multiple levels of security,=0A= selectable on a per-message basis by an SNMP application, because,=0A= for example, there is not much value in using encryption for a=0A= Commander Generator to poll for potentially non-sensitive performance=0A= data on thousands of interfaces every ten minutes; the encryption=0A= might add significant overhead to processing of the messages.=0A= =0A= Some Transport Models might support only specific authentication and=0A= encryption services, such as requiring all messages to be carried=0A= using both authentication and encryption, regardless of the security=0A= level requested by an SNMP application. A Transport Model MAY=0A= upgrade the security level requested by a transport-aware security=0A= model, i.e. noAuthNoPriv and authNoPriv might be sent over an=0A= authenticated and encrypted session. A Transport Model MUST NOT=0A= downgrade the security level requested by a transport-aware security=0A= model, and SHOULD discard any message where this would occur.=0A= =0A= 4. Scenario Diagrams and the Transport Subsystem=0A= =0A= RFC3411 section 4.6.1 and 4.6.2 provide scenario diagrams to=0A= illustrate how an outgoing message is created, and how an incoming=0A= message is processed. RFC3411 does not define ASIs for the "Send=0A= SNMP Request Message to Network", "Receive SNMP Response Message from=0A= Network", "Receive SNMP Message from Network" and "Send SNMP message=0A= to Network" arrows in these diagrams.=0A= =0A= This document defines two ASIs corresponding to these arrows: a=0A= sendMessage ASI to send SNMP messages to the network, and a=0A= receiveMessage ASI to receive SNMP messages from the network. These=0A= ASIs are used for all SNMP messages, regardless of pduType.=0A= =0A= 5. Cached Information and References=0A= =0A= When performing SNMP processing, there are two levels of state=0A= information that may need to be retained: the immediate state linking=0A= a request-response pair, and potentially longer-term state relating=0A= to transport and security.=0A= =0A= The RFC3411 architecture uses caches to maintain the short-term=0A= message state, and uses references in the ASIs to pass this=0A= information between subsystems.=0A= =0A= This document defines the requirements for a cache to handle=0A= additional short-term message state and longer-term transport state=0A= information, using a tmStateReference parameter to pass this=0A= information between subsystems.=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 17]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= To simplify the elements of procedure, the release of state=0A= information is not always explicitly specified. As a general rule,=0A= if state information is available when a message being processed gets=0A= discarded, the state related to that message SHOULD also be=0A= discarded. If state information is available when a relationship=0A= between engines is severed, such as the closing of a transport=0A= session, the state information for that relationship SHOULD also be=0A= discarded.=0A= =0A= Since the contents of a cache are meaningful only within an=0A= implementation, and not on-the-wire, the format of the cache is=0A= implementation-specific.=0A= =0A= 5.1. securityStateReference=0A= =0A= The securityStateReference parameter is defined in RFC3411. Its=0A= primary purpose is to provide a mapping between a request and the=0A= corresponding response. This cache is not accessible to Transport=0A= Models, and an entry is typically only retained for the lifetime of a=0A= request-response pair of messages.=0A= =0A= 5.2. tmStateReference=0A= =0A= For each transport session, information about the transport security=0A= is stored in a tmState cache or datastore, that is referenced by a=0A= tmStateReference. The tmStateReference parameter is used to pass=0A= model-specific and mechanism-specific parameters between the=0A= Transport subsystem and transport-aware Security Models.=0A= =0A= In general, when necessary, the tmState is populated by the security=0A= model for outgoing messages and by the transport model for incoming=0A= messages. However, in both cases, the model populating the tmState=0A= may have incomplete information, and the missing information might be=0A= populated by the other model when the information becomes available.=0A= =0A= The tmState might contain both long-term and short-term information.=0A= The session information typically remains valid for the duration of=0A= the transport session, might be used for several messages, and might=0A= be stored in a local configuration datastore. Some information has a=0A= shorter lifespan, such as tmSameSecurity and tmRequestedSecurityLevel=0A= which are associated with a specific message.=0A= =0A= Since this cache is only used within an implementation, and not on-=0A= the-wire, the precise contents and format of the cache are=0A= implementation-dependent. For architectural modularity between=0A= Transport Models and transport-aware Security Models, a fully-defined=0A= tmState MUST conceptually include at least the following fields:=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 18]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= tmTransportDomain=0A= =0A= tmTransportAddress=0A= =0A= tmSecurityName=0A= =0A= tmRequestedSecurityLevel=0A= =0A= tmTransportSecurityLevel=0A= =0A= tmSameSecurity=0A= =0A= tmSessionID=0A= =0A= The details of these fields are described in the following=0A= subsections.=0A= =0A= 5.2.1. Transport information=0A= =0A= Information about the source of an incoming SNMP message is passed up=0A= from the Transport subsystem as far as the Message Processing=0A= subsystem. However these parameters are not included in the=0A= processIncomingMsg ASI defined in RFC3411, and hence this information=0A= is not directly available to the Security Model.=0A= =0A= A transport-aware Security Model might wish to take account of the=0A= transport protocol and originating address when authenticating the=0A= request, and setting up the authorization parameters. It is=0A= therefore necessary for the Transport Model to include this=0A= information in the tmStateReference cache, so that it is accessible=0A= to the Security Model.=0A= =0A= o tmTransportDomain: the transport protocol (and hence the Transport=0A= Model) used to receive the incoming message=0A= =0A= o tmTransportAddress: the source of the incoming message.=0A= =0A= The ASIs used for processing an outgoing message all include explicit=0A= transportDomain and transportAddress parameters. The values within=0A= the securityStateReference cache might override these parameters for=0A= outgoing messages.=0A= =0A= 5.2.2. securityName=0A= =0A= There are actually three distinct "identities" that can be identified=0A= during the processing of an SNMP request over a secure transport:=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 19]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= o transport principal: the transport-authenticated identity, on=0A= whose behalf the secure transport connection was (or should be)=0A= established. This value is transport-, mechanism- and=0A= implementation- specific, and is only used within a given=0A= Transport Model.=0A= =0A= o tmSecurityName: a human-readable name (in snmpAdminString format)=0A= representing this transport identity. This value is transport-=0A= and implementation-specific, and is only used (directly) by the=0A= Transport and Security Models.=0A= =0A= o securityName: a human-readable name (in snmpAdminString format)=0A= representing the SNMP principal in a model-independent manner.=0A= This value is used directly by SNMP Applications, the access=0A= control subsystem, the message processing subsystem, and the=0A= security subsystem.=0A= =0A= The transport principal may or may not be the same as the=0A= tmSecurityName. Similarly, the tmSecurityName may or may not be the=0A= same as the securityName as seen by the Application and Access=0A= Control subsystems. In particular, a non-transport-aware Security=0A= Model will ignore tmSecurityName completely when determining the SNMP=0A= securityName.=0A= =0A= However it is important that the mapping between the transport=0A= principal and the SNMP securityName (for transport-aware Security=0A= Models) is consistent and predictable, to allow configuration of=0A= suitable access control and the establishment of transport=0A= connections.=0A= =0A= 5.2.3. securityLevel=0A= =0A= There are two distinct issues relating to security level as applied=0A= to secure transports. For clarity, these are handled by separate=0A= fields in the tmStateReference cache:=0A= =0A= o tmTransportSecurityLevel: an indication from the Transport Model=0A= of the level of security offered by this session. The Security=0A= Model can use this to ensure that incoming messages were suitably=0A= protected before acting on them.=0A= =0A= o tmRequestedSecurityLevel: an indication from the Security Model of=0A= the level of security required to be provided by the transport=0A= protocol. The Transport Model can use this to ensure that=0A= outgoing messages will not be sent over an insufficiently secure=0A= session.=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 20]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= 5.2.4. Session Information=0A= =0A= For security reasons, if a secure transport session is closed between=0A= the time a request message is received and the corresponding response=0A= message is sent, then the response message SHOULD be discarded, even=0A= if a new session has been established. The SNMPv3 WG decided that=0A= this should be a SHOULD architecturally, and it is a security-model-=0A= specific decision whether to REQUIRE this.=0A= =0A= o tmSameSecurity: this flag is used by a transport-aware Security=0A= Model to indicate whether the Transport Model MUST enforce this=0A= restriction.=0A= =0A= o tmSessionID: in order to verify whether the session has changed,=0A= the Transport Model must be able to compare the session used to=0A= receive the original request with the one to be used to send the=0A= response. This typically requires some form of session=0A= identifier. This value is only ever used by the Transport Model,=0A= so the format and interpretation of this field are model-specific=0A= and implementation-dependent.=0A= =0A= When processing an outgoing message, if tmSameSecurity is true, then=0A= the tmSessionID MUST match the current transport session, otherwise=0A= the message MUST be discarded, and the dispatcher notified that=0A= sending the message failed.=0A= =0A= 6. Abstract Service Interfaces=0A= =0A= Abstract service interfaces have been defined by RFC 3411 to describe=0A= the conceptual data flows between the various subsystems within an=0A= SNMP entity, and to help keep the subsystems independent of each=0A= other except for the common parameters.=0A= =0A= This document introduces a couple of new ASIs to define the interface=0A= between the Transport and Dispatcher Subsystems, and extends some of=0A= the ASIs defined in RFC3411 to include transport-related information.=0A= =0A= This document follows the example of RFC3411 regarding the release of=0A= state information, and regarding error indications.=0A= =0A= 1) The release of state information is not always explicitly=0A= specified in a transport model. As a general rule, if state=0A= information is available when a message gets discarded, the message-=0A= state information should also be released, and if state information=0A= is available when a session is closed, the session state information=0A= should also be released. Keeping sensitive security information=0A= longer than necessary might introduce potential vulnerabilities to an=0A= implementation.=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 21]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= 2)An error indication in statusInformation will typically include the=0A= OID and value for an incremented error counter. This may be=0A= accompanied by values for contextEngineID and contextName for this=0A= counter, a value for securityLevel, and the appropriate state=0A= reference if the information is available at the point where the=0A= error is detected.=0A= =0A= 6.1. sendMessage ASI=0A= =0A= The sendMessage ASI is used to pass a message from the Dispatcher to=0A= the appropriate Transport Model for sending. In the diagram in=0A= section 4.6.1 of RFC 3411, the sendMessage ASI defined in this=0A= document replaces the text "Send SNMP Request Message to Network".=0A= In section 4.6.2, the sendMessage ASI replaces the text "Send SNMP=0A= Message to Network"=0A= =0A= If present and valid, the tmStateReference refers to a cache=0A= containing transport-model-specific parameters for the transport and=0A= transport security. How a tmStateReference is determined to be=0A= present and valid is implementation-dependent. How the information=0A= in the cache is used is transport-model-dependent and implementation-=0A= dependent.=0A= =0A= This may sound underspecified, but a transport model might be=0A= something like SNMP over UDP over IPv6, where no security is=0A= provided, so it might have no mechanisms for utilizing a=0A= tmStateReference cache.=0A= =0A= statusInformation =3D=0A= sendMessage(=0A= IN destTransportDomain -- transport domain to be used=0A= IN destTransportAddress -- transport address to be used=0A= IN outgoingMessage -- the message to send=0A= IN outgoingMessageLength -- its length=0A= IN tmStateReference -- reference to transport state=0A= )=0A= =0A= 6.2. Changes to RFC3411 Outgoing ASIs=0A= =0A= Additional parameters have been added to the ASIs defined in RFC3411,=0A= concerned with communication between the Dispatcher and Message=0A= Processing subsystems, and between the Message Processing and=0A= Security Subsystems.=0A= =0A= 6.2.1. Message Processing Subsystem Primitives=0A= =0A= A tmStateReference parameter has been added as an OUT parameter to=0A= the prepareOutgoingMessage and prepareResponseMessage ASIs. This is=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 22]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= passed from Message Processing Subsystem to the dispatcher, and from=0A= there to the Transport Subsystem.=0A= =0A= How or if the Message Processing Subsystem modifies or utilizes the=0A= contents of the cache is message-processing-model specific.=0A= =0A= statusInformation =3D -- success or errorIndication=0A= prepareOutgoingMessage(=0A= IN transportDomain -- transport domain to be used=0A= IN transportAddress -- transport address to be used=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN securityModel -- Security Model to use=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN contextEngineID -- data from/at this entity=0A= IN contextName -- data from/in this context=0A= IN pduVersion -- the version of the PDU=0A= IN PDU -- SNMP Protocol Data Unit=0A= IN expectResponse -- TRUE or FALSE=0A= IN sendPduHandle -- the handle for matching=0A= incoming responses=0A= OUT destTransportDomain -- destination transport domain=0A= OUT destTransportAddress -- destination transport address=0A= OUT outgoingMessage -- the message to send=0A= OUT outgoingMessageLength -- its length=0A= OUT tmStateReference -- (NEW) reference to transport state=0A= )=0A= =0A= statusInformation =3D -- success or errorIndication=0A= prepareResponseMessage(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN securityModel -- Security Model to use=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN contextEngineID -- data from/at this entity=0A= IN contextName -- data from/in this context=0A= IN pduVersion -- the version of the PDU=0A= IN PDU -- SNMP Protocol Data Unit=0A= IN maxSizeResponseScopedPDU -- maximum size able to accept=0A= IN stateReference -- reference to state information=0A= -- as presented with the request=0A= IN statusInformation -- success or errorIndication=0A= -- error counter OID/value if error=0A= OUT destTransportDomain -- destination transport domain=0A= OUT destTransportAddress -- destination transport address=0A= OUT outgoingMessage -- the message to send=0A= OUT outgoingMessageLength -- its length=0A= OUT tmStateReference -- (NEW) reference to transport state=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 23]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= )=0A= =0A= 6.2.2. Security Subsystem Primitives=0A= =0A= transportDomain and transportAddress parameters have been added as IN=0A= parameters to the generateRequestMsg and generateResponseMsg ASIs,=0A= and a tmStateReference parameter has been added as an OUT parameter.=0A= The transportDomain and transportAddress parameters will have been=0A= passed into the Message Processing Subsystem from the dispatcher, and=0A= are passed on to the Security Subsystem. The tmStateReference=0A= parameter will be passed from the Security Subsystem back to the=0A= Message Processing Subsystem, and on to the dispatcher and Transport=0A= subsystems.=0A= =0A= If a cache exists for a session identifiable from the=0A= tmTransportDomain, tmTransportAddress, tmSecurityName and requested=0A= securityLevel, then a transport-aware Security Model might create a=0A= tmStateReference parameter to this cache, and pass that as an OUT=0A= parameter.=0A= =0A= statusInformation =3D=0A= generateRequestMsg(=0A= IN transportDomain -- (NEW) destination transport domain=0A= IN transportAddress -- (NEW) destination transport address=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN globalData -- message header, admin data=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN securityModel -- for the outgoing message=0A= IN securityEngineID -- authoritative SNMP entity=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- Level of Security requested=0A= IN scopedPDU -- message (plaintext) payload=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- (NEW) reference to transport state=0A= )=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 24]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= statusInformation =3D=0A= generateResponseMsg(=0A= IN transportDomain -- (NEW) destination transport domain=0A= IN transportAddress -- (NEW) destination transport address=0A= IN messageProcessingModel -- Message Processing Model=0A= IN globalData -- msgGlobalData=0A= IN maxMessageSize -- from msgMaxSize=0A= IN securityModel -- as determined by MPM=0A= IN securityEngineID -- the value of snmpEngineID=0A= IN securityName -- on behalf of this principal=0A= IN securityLevel -- for the outgoing message=0A= IN scopedPDU -- as provided by MPM=0A= IN securityStateReference -- as provided by MPM=0A= OUT securityParameters -- filled in by Security Module=0A= OUT wholeMsg -- complete generated message=0A= OUT wholeMsgLength -- length of generated message=0A= OUT tmStateReference -- (NEW) reference to transport state=0A= )=0A= =0A= 6.3. The receiveMessage ASI=0A= =0A= The receiveMessage ASI is used to pass a message from the Transport=0A= Subsystem to the Dispatcher. In the diagram in section 4.6.1 of RFC=0A= 3411, the receiveMessage ASI replaces the text "Receive SNMP Response=0A= Message from Network". In section 4.6.2, the receiveMessage ASI=0A= replaces the text "Receive SNMP Message from Network".=0A= =0A= When a message is received on a given transport session, if a cache=0A= does not already exist for that session, the Transport Model might=0A= create one, referenced by tmStateReference. The contents of this=0A= cache are discussed in section 5. How this information is determined=0A= is implementation- and transport-model-specific.=0A= =0A= "Might create one" may sound underspecified, but a transport model=0A= might be something like SNMP over UDP over IPv6, where transport=0A= security is not provided, so it might not create a cache.=0A= =0A= The Transport Model does not know the securityModel for an incoming=0A= message; this will be determined by the Message Processing Model in a=0A= message-processing-model-dependent manner.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 25]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= statusInformation =3D=0A= receiveMessage(=0A= IN transportDomain -- origin transport domain=0A= IN transportAddress -- origin transport address=0A= IN incomingMessage -- the message received=0A= IN incomingMessageLength -- its length=0A= IN tmStateReference -- reference to transport state=0A= )=0A= =0A= 6.4. Changes to RFC3411 Incoming ASIs=0A= =0A= The tmStateReference parameter has also been added to some of the=0A= incoming ASIs defined in RFC3411. How or if a Message Processing=0A= Model or Security Model uses tmStateReference is message-processing-=0A= and security-model-specific.=0A= =0A= This may sound underspecified, but a message processing model might=0A= have access to all the information from the cache and from the=0A= message. The Message Processing Model might determine that the USM=0A= Security Model is specified in an SNMPv3 message header; the USM=0A= Security Model has no need of values in the tmStateReference cache to=0A= authenticate and secure the SNMP message, but an application might=0A= have specified to use a secure transport such as that provided by the=0A= SSH Transport Model to send the message to its destination.=0A= =0A= 6.4.1. Message Processing Subsystem Primitive=0A= =0A= The tmStateReference parameter of prepareDataElements is passed from=0A= the dispatcher to the Message Processing Subsystem. How or if the=0A= Message Processing Subsystem modifies or utilizes the contents of the=0A= cache is message-processing-model-specific.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 26]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= result =3D -- SUCCESS or errorIndication=0A= prepareDataElements(=0A= IN transportDomain -- origin transport domain=0A= IN transportAddress -- origin transport address=0A= IN wholeMsg -- as received from the network=0A= IN wholeMsgLength -- as received from the network=0A= IN tmStateReference -- (NEW) from the Transport Model=0A= OUT messageProcessingModel -- typically, SNMP version=0A= OUT securityModel -- Security Model to use=0A= OUT securityName -- on behalf of this principal=0A= OUT securityLevel -- Level of Security requested=0A= OUT contextEngineID -- data from/at this entity=0A= OUT contextName -- data from/in this context=0A= OUT pduVersion -- the version of the PDU=0A= OUT PDU -- SNMP Protocol Data Unit=0A= OUT pduType -- SNMP PDU type=0A= OUT sendPduHandle -- handle for matched request=0A= OUT maxSizeResponseScopedPDU -- maximum size sender can accept=0A= OUT statusInformation -- success or errorIndication=0A= -- error counter OID/value if error=0A= OUT stateReference -- reference to state information=0A= -- to be used for possible Response=0A= )=0A= =0A= =0A= =0A= =0A= 6.4.2. Security Subsystem Primitive=0A= =0A= The processIncomingMessage ASI passes tmStateReference from the=0A= Message Processing Subsystem to the Security Subsystem.=0A= =0A= If tmStateReference is present and valid, an appropriate Security=0A= Model might utilize the information in the cache. How or if the=0A= Security Subsystem utilizes the information in the cache is security-=0A= model-specific.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 27]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= statusInformation =3D -- errorIndication or success=0A= -- error counter OID/value if error=0A= processIncomingMsg(=0A= IN messageProcessingModel -- typically, SNMP version=0A= IN maxMessageSize -- of the sending SNMP entity=0A= IN securityParameters -- for the received message=0A= IN securityModel -- for the received message=0A= IN securityLevel -- Level of Security=0A= IN wholeMsg -- as received on the wire=0A= IN wholeMsgLength -- length as received on the wire=0A= IN tmStateReference -- (NEW) from the Transport Model=0A= OUT securityEngineID -- authoritative SNMP entity=0A= OUT securityName -- identification of the principal=0A= OUT scopedPDU, -- message (plaintext) payload=0A= OUT maxSizeResponseScopedPDU -- maximum size sender can handle=0A= OUT securityStateReference -- reference to security state=0A= ) -- information, needed for response=0A= =0A= 7. Security Considerations=0A= =0A= This document defines an architectural approach that permits SNMP to=0A= utilize transport layer security services. Each proposed Transport=0A= Model should discuss the security considerations of that Transport=0A= Model.=0A= =0A= It is considered desirable by some industry segments that SNMP=0A= Transport Models should utilize transport layer security that=0A= addresses perfect forward secrecy at least for encryption keys.=0A= Perfect forward secrecy guarantees that compromise of long term=0A= secret keys does not result in disclosure of past session keys. Each=0A= proposed Transport Model should include a discussion in its security=0A= considerations of whether perfect forward security is appropriate for=0A= that Transport Model.=0A= =0A= The Denial of Service characteristics of various transport models and=0A= security protocols will vary and should be evaluated when determining=0A= the applicability of a transport model to a particular deployment=0A= situation.=0A= =0A= Since the cache will contain security-related parameters,=0A= implementers should store this information (in memory or in=0A= persistent storage) in a manner to protect it from unauthorized=0A= disclosure and/or modification.=0A= =0A= Care must be taken to ensure that a SNMP engine is sending packets=0A= out over a transport using credentials that are legal for that engine=0A= to use on behalf of that user. Otherwise an engine that has multiple=0A= transports open might be "tricked" into sending a message through the=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 28]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= wrong transport.=0A= =0A= A Security Model may have multiple sources from which to define the=0A= securityName and securityLevel. The use of a secure Transport Model=0A= does not imply that the securityName and securityLevel chosen by the=0A= Security Model represent the transport-authenticated identity or the=0A= transport-provided security services. The securityModel,=0A= securityName, and securityLevel parameters are a related set, and an=0A= administrator should understand how the specified securityModel=0A= selects the corresponding securityName and securityLevel.=0A= =0A= 7.1. Coexistence, Security Parameters, and Access Control=0A= =0A= In the RFC3411 architecture, the Message Processing Model makes the=0A= decision about which Security Model to use. The architectural change=0A= described by this document does not alter that.=0A= =0A= The architecture change described by this document does however,=0A= allow SNMP to support two different approaches to security - message-=0A= driven security and transport-driven security. With message-driven=0A= security, SNMP provides its own security, and passes security=0A= parameters within the SNMP message; with transport-driven security,=0A= SNMP depends on an external entity to provide security during=0A= transport by "wrapping" the SNMP message.=0A= =0A= In times of network stress, the security protocol and its underlying=0A= security mechanisms SHOULD NOT depend upon the ready availability of=0A= other network services (e.g., Network Time Protocol (NTP) or=0A= Authentication, Authorization, and Accounting (AAA) protocols or=0A= certificate authorities). The User-based Security Model was=0A= explicitly designed to not depend upon external network services, and=0A= provides its own security services. It is RECOMMENDED that operators=0A= provision authPriv USM to supplement any security model or transport=0A= model that has external dependencies, so that secure SNMP=0A= communications can continue when the external network service is not=0A= available.=0A= =0A= Using a non-transport-aware security model with a secure transport=0A= model is NOT RECOMMENDED, for the following reasons.=0A= =0A= Security models defined before the Transport Security Model (i.e.,=0A= SNMPv1, SNMPv2c, and USM) do not support transport-based security,=0A= and only have access to the security parameters contained within the=0A= SNMP message. They do not know about the security parameters=0A= associated with a secure transport. As a result, the Access Control=0A= Subsystem bases its decisions on the security parameters extracted=0A= from the SNMP message, not on transport-based security parameters.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 29]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= Implications of combining older security models with secure transport=0A= models are known. The securityName used for access control decisions=0A= is based on the message-driven identity, which might be=0A= unauthenticated, not the transport-driven authenticated identity:=0A= =0A= o An SNMPv1 message will always be paired with an SNMPv1 Security=0A= Model (per RFC3584), regardless of the transport mapping or=0A= transport model used, and access controls will be based on the=0A= unauthenticated community name.=0A= =0A= o An SNMPv2c message will always be paired with an SNMPv2c Security=0A= Model (per RFC3584), regardless of the transport mapping or=0A= transport model used, and access controls will be based on the=0A= unauthenticated community name.=0A= =0A= o An SNMPv3 message will always be paired with the securityModel=0A= specified in the msgSecurityParameters field of the message (per=0A= RFC3412), regardless of the transport mapping or transport model=0A= used. If the SNMPv3 message specifies the User-based Security=0A= Model (USM), with noAuthNoPriv, then the access controls will be=0A= based on the unauthenticated USM user.=0A= =0A= o For outgoing messages, if a secure transport model is selected in=0A= combination with a security model that does not populate a=0A= tmStateReference, the secure transport model SHOULD detect the=0A= lack of a valid tmStateReference and fail.=0A= =0A= 8. IANA Considerations=0A= =0A= IANA is requested to create a new registry in the Simple Network=0A= Management Protocol (SNMP) Number Spaces. The new registry should be=0A= called "SNMP Transport Domains". This registry will contain ASCII=0A= strings of one to four characters to identify prefixes for=0A= corresponding SNMP transport domains. Each transport domain requires=0A= an OID assignment under snmpDomains [RFC2578] . Values are to be=0A= assigned via [RFC5226] "Specification Required".=0A= =0A= The registry should be populated with the following initial entries:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 30]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= Registry Name: SNMP Transport Domains=0A= Reference: [RFC2578] [RFC3417] [XXXX]=0A= Registration Procedures: Specification Required=0A= Each domain is assigned a MIB-defined OID under snmpDomains=0A= =0A= Prefix snmpDomains Reference=0A= ------- ----------------------------- ---------=0A= udp snmpUDPDomain RFC3417=0A= clns snmpCLNSDomain RFC3417=0A= cons snmpCONSDomain RFC3417=0A= ddp snmpDDPDomain RFC3417=0A= ipx snmpIPXDomain RFC3417=0A= prxy rfc1157Domain RFC3417=0A= =0A= -- NOTE to RFC editor: replace XXXX with actual RFC number=0A= -- for this document and remove this note=0A= =0A= 9. Acknowledgments=0A= =0A= The Integrated Security for SNMP WG would like to thank the following=0A= people for their contributions to the process:=0A= =0A= The authors of submitted Security Model proposals: Chris Elliot, Wes=0A= Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David=0A= Perkins, Joseph Salowey, and Juergen Schoenwaelder.=0A= =0A= The members of the Protocol Evaluation Team: Uri Blumenthal,=0A= Lakshminath Dondeti, Randy Presuhn, and Eric Rescorla.=0A= =0A= WG members who performed detailed reviews: Jeffrey Hutzelman, Bert=0A= Wijnen, Tom Petch, Wes Hardaker, and Dave Shield.=0A= =0A= 10. References=0A= =0A= 10.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for=0A= use in RFCs to Indicate=0A= Requirement Levels",=0A= BCP 14, RFC 2119,=0A= March 1997.=0A= =0A= [RFC2578] McCloghrie, K., Ed.,=0A= Perkins, D., Ed., and J.=0A= Schoenwaelder, Ed.,=0A= "Structure of Management=0A= Information Version 2=0A= (SMIv2)", STD 58, RFC 2578,=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 31]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= April 1999.=0A= =0A= [RFC3411] Harrington, D., Presuhn,=0A= R., and B. Wijnen, "An=0A= Architecture for Describing=0A= Simple Network Management=0A= Protocol (SNMP) Management=0A= Frameworks", STD 62,=0A= RFC 3411, December 2002.=0A= =0A= [RFC3412] Case, J., Harrington, D.,=0A= Presuhn, R., and B. Wijnen,=0A= "Message Processing and=0A= Dispatching for the Simple=0A= Network Management Protocol=0A= (SNMP)", STD 62, RFC 3412,=0A= December 2002.=0A= =0A= [RFC3414] Blumenthal, U. and B.=0A= Wijnen, "User-based=0A= Security Model (USM) for=0A= version 3 of the Simple=0A= Network Management Protocol=0A= (SNMPv3)", STD 62,=0A= RFC 3414, December 2002.=0A= =0A= [RFC3417] Presuhn, R., "Transport=0A= Mappings for the Simple=0A= Network Management Protocol=0A= (SNMP)", STD 62, RFC 3417,=0A= December 2002.=0A= =0A= 10.2. Informative References=0A= =0A= [RFC2865] Rigney, C., Willens, S.,=0A= Rubens, A., and W. Simpson,=0A= "Remote Authentication Dial=0A= In User Service (RADIUS)",=0A= RFC 2865, June 2000.=0A= =0A= [RFC3410] Case, J., Mundy, R.,=0A= Partain, D., and B.=0A= Stewart, "Introduction and=0A= Applicability Statements=0A= for Internet-Standard=0A= Management Framework",=0A= RFC 3410, December 2002.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 32]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= [RFC3584] Frye, R., Levi, D.,=0A= Routhier, S., and B.=0A= Wijnen, "Coexistence=0A= between Version 1, Version=0A= 2, and Version 3 of the=0A= Internet-standard Network=0A= Management Framework",=0A= BCP 74, RFC 3584,=0A= August 2003.=0A= =0A= [RFC5246] Dierks, T. and E. Rescorla,=0A= "The Transport Layer=0A= Security (TLS) Protocol=0A= Version 1.2", RFC 5246,=0A= August 2008.=0A= =0A= [RFC4422] Melnikov, A. and K.=0A= Zeilenga, "Simple=0A= Authentication and Security=0A= Layer (SASL)", RFC 4422,=0A= June 2006.=0A= =0A= [RFC4251] Ylonen, T. and C. Lonvick,=0A= "The Secure Shell (SSH)=0A= Protocol Architecture",=0A= RFC 4251, January 2006.=0A= =0A= [RFC4741] Enns, R., "NETCONF=0A= Configuration Protocol",=0A= RFC 4741, December 2006.=0A= =0A= [RFC5226] Narten, T. and H.=0A= Alvestrand, "Guidelines for=0A= Writing an IANA=0A= Considerations Section in=0A= RFCs", BCP 26, RFC 5226,=0A= May 2008.=0A= =0A= [I-D.ietf-isms-transport-security-model] Harrington, D. and W.=0A= Hardaker, "Transport=0A= Security Model for SNMP", d=0A= raft-ietf-isms-transport-=0A= security-model-10 (work in=0A= progress), October 2008.=0A= =0A= [I-D.ietf-isms-secshell] Harrington, D., Salowey,=0A= J., and W. Hardaker,=0A= "Secure Shell Transport=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 33]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= Model for SNMP",=0A= draft-ietf-isms-secshell-13=0A= (work in progress),=0A= November 2008.=0A= =0A= [I-D.ietf-syslog-protocol] Gerhards, R., "The syslog=0A= Protocol", draft-ietf-=0A= syslog-protocol-23 (work in=0A= progress), September 2007.=0A= =0A= Appendix A. Why tmStateReference?=0A= =0A= This appendix considers why a cache-based approach was selected for=0A= passing parameters.=0A= =0A= There are four approaches that could be used for passing information=0A= between the Transport Model and a Security Model.=0A= =0A= 1. one could define an ASI to supplement the existing ASIs, or=0A= =0A= 2. one could add a header to encapsulate the SNMP message,=0A= =0A= 3. one could utilize fields already defined in the existing SNMPv3=0A= message, or=0A= =0A= 4. one could pass the information in an implementation-specific=0A= cache or via a MIB module.=0A= =0A= A.1. Define an Abstract Service Interface=0A= =0A= Abstract Service Interfaces (ASIs) are defined by a set of primitives=0A= that specify the services provided and the abstract data elements=0A= that are to be passed when the services are invoked. Defining=0A= additional ASIs to pass the security and transport information from=0A= the Transport Subsystem to Security Subsystem has the advantage of=0A= being consistent with existing RFC3411/3412 practice, and helps to=0A= ensure that any Transport Model proposals pass the necessary data,=0A= and do not cause side effects by creating model-specific dependencies=0A= between itself and other models or other subsystems other than those=0A= that are clearly defined by an ASI.=0A= =0A= A.2. Using an Encapsulating Header=0A= =0A= A header could encapsulate the SNMP message to pass necessary=0A= information from the Transport Model to the dispatcher and then to a=0A= Message Processing Model. The message header would be included in=0A= the wholeMessage ASI parameter, and would be removed by a=0A= corresponding Message Processing Model. This would imply the (one=0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 34]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= and only) messaging dispatcher would need to be modified to determine=0A= which SNMP message version was involved, and a new Message Processing=0A= Model would need to be developed that knew how to extract the header=0A= from the message and pass it to the Security Model.=0A= =0A= A.3. Modifying Existing Fields in an SNMP Message=0A= =0A= [RFC3412] defines the SNMPv3 message, which contains fields to pass=0A= security related parameters. The Transport Subsystem could use these=0A= fields in an SNMPv3 message, or comparable fields in other message=0A= formats to pass information between Transport Models in different=0A= SNMP engines, and to pass information between a Transport Model and a=0A= corresponding Message Processing Model.=0A= =0A= If the fields in an incoming SNMPv3 message are changed by the=0A= Transport Model before passing it to the Security Model, then the=0A= Transport Model will need to decode the ASN.1 message, modify the=0A= fields, and re-encode the message in ASN.1 before passing the message=0A= on to the message dispatcher or to the transport layer. This would=0A= require an intimate knowledge of the message format and message=0A= versions so the Transport Model knew which fields could be modified.=0A= This would seriously violate the modularity of the architecture.=0A= =0A= A.4. Using a Cache=0A= =0A= This document describes a cache, into which the Transport Model puts=0A= information about the security applied to an incoming message, and a=0A= Security Model can extract that information from the cache. Given=0A= that there might be multiple TM-security caches, a tmStateReference=0A= is passed as an extra parameter in the ASIs between the Transport=0A= Subsystem and the Security Subsystem, so the Security Model knows=0A= which cache of information to consult.=0A= =0A= This approach does create dependencies between a specific Transport=0A= Model and a corresponding specific Security Model. However, the=0A= approach of passing a model-independent reference to a model-=0A= dependent cache is consistent with the securityStateReference already=0A= being passed around in the RFC3411 ASIs.=0A= =0A= Appendix B. Open Issues=0A= =0A= NOTE to RFC editor: If this section is empty, then please remove this=0A= open issues section before publishing this document as an RFC. (If=0A= it is not empty, please send it back to the editor to resolve.=0A= =0A= o=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 35]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= Appendix C. Change Log=0A= =0A= NOTE to RFC editor: Please remove this change log before publishing=0A= this document as an RFC.=0A= =0A= Changes from -15- to -16-=0A= =0A= o editorial changes=0A= =0A= o clarified long-term vs short-term nature of tmState=0A= =0A= o removed any references to LCD=0A= =0A= Changes from -14- to -15-=0A= =0A= o editorial changes and reorganization=0A= =0A= Changes from -13- to -14-=0A= =0A= o=0A= =0A= Changes from -12- to -13-=0A= =0A= o moved conventions after Internet Standard framework, for=0A= consistency with related documents.=0A= =0A= o editorial changes and reorganization=0A= =0A= Changes from -10- to -12-=0A= =0A= o clarified relation to other documents.=0A= =0A= o clarified relation to older security models.=0A= =0A= o moved comparison of TSM and USM to TSM document=0A= =0A= Changes from -09- to -10-=0A= =0A= o Pointed to companion documents=0A= =0A= o Wordsmithed extensively=0A= =0A= o Modified the note about SNMPv3-consistent terminology=0A= =0A= o Modified the note about RFC2119 terminology.=0A= =0A= o Modified discussion of cryptographic key generation.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 36]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= o Added security considerations about coexistence with older=0A= security models=0A= =0A= o Expanded discussion of same session functionality=0A= =0A= o Described how sendMessage and receiveMessage fit into RFC3411=0A= diagrams=0A= =0A= o Modified prepareResponseMessage ASI=0A= =0A= Changes from -08- to -09-=0A= =0A= o A question was raised that notifications would not work properly,=0A= but we could never find the circumstances where this was true.=0A= =0A= o removed appendix with parameter matrix=0A= =0A= o Added a note about terminology, for consistency with SNMPv3 rather=0A= than with RFC2828.=0A= =0A= Changes from -07- to -08-=0A= =0A= o Identified new parameters in ASIs.=0A= =0A= o Added discussion about well-known ports.=0A= =0A= Changes from -06- to -07-=0A= =0A= o Removed discussion of double authentication=0A= =0A= o Removed all direct and indirect references to pduType by Transport=0A= Subsystem=0A= =0A= o Added warning regarding keeping sensitive security information=0A= available longer than needed.=0A= =0A= o Removed knowledge of securityStateReference from Transport=0A= Subsystem.=0A= =0A= o Changed transport session identifier to not include securityModel,=0A= since this is not known for incoming messages until the message=0A= processing model.=0A= =0A= Changes from revision -05- to -06-=0A= =0A= mostly editorial changes=0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 37]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= removed some paragraphs considered unnecessary=0A= =0A= added Updates to header=0A= =0A= modified some text to get the security details right=0A= =0A= modified text re: ASIs so they are not API-like=0A= =0A= cleaned up some diagrams=0A= =0A= cleaned up RFC2119 language=0A= =0A= added section numbers to citations to RFC3411=0A= =0A= removed gun for political correctness=0A= =0A= Changes from revision -04- to -05-=0A= =0A= removed all objects from the MIB module.=0A= =0A= changed document status to "Standard" rather than the xml2rfc=0A= default of informational.=0A= =0A= =0A= =0A= changed mention of MD5 to SHA=0A= =0A= moved addressing style to TDomain and TAddress=0A= =0A= modified the diagrams as requested=0A= =0A= removed the "layered stack" diagrams that compared USM and a=0A= Transport Model processing=0A= =0A= removed discussion of speculative features that might exist in=0A= future Transport Models=0A= =0A= removed openSession and closeSession ASIs, since those are model-=0A= dependent=0A= =0A= removed the MIB module=0A= =0A= removed the MIB boilerplate intro (this memo defines a SMIv2 MIB )=0A= =0A= removed IANA considerations related to the now-gone MIB module=0A= =0A= removed security considerations related to the MIB module=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 38]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= removed references needed for the MIB module=0A= =0A= changed receiveMessage ASI to use origin transport domain/address=0A= =0A= updated Parameter CSV appendix=0A= =0A= Changes from revision -03- to -04-=0A= =0A= changed title from Transport Mapping Security Model Architectural=0A= Extension to Transport Subsystem=0A= =0A= modified the abstract and introduction=0A= =0A= changed TMSM to TMS=0A= =0A= changed MPSP to simply Security Model=0A= =0A= changed SMSP to simply Security Model=0A= =0A= changed TMSP to Transport Model=0A= =0A= removed MPSP and TMSP and SMSP from Acronyms section=0A= =0A= modified diagrams=0A= =0A= removed most references to dispatcher functionality=0A= =0A= worked to remove dependencies between transport and security=0A= models.=0A= =0A= defined snmpTransportModel enumeration similar to=0A= snmpSecurityModel, etc.=0A= =0A= eliminated all reference to SNMPv3 msgXXXX fields=0A= =0A= changed tmSessionReference back to tmStateReference=0A= =0A= Changes from revision -02- to -03-=0A= =0A= o removed session table from MIB module=0A= =0A= o removed sessionID from ASIs=0A= =0A= o reorganized to put ASI discussions in EOP section, as was done in=0A= SSHSM=0A= =0A= o changed user auth to client auth=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 39]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= o changed tmStateReference to tmSessionReference=0A= =0A= o modified document to meet consensus positions published by JS=0A= =0A= * authoritative is model-specific=0A= =0A= * msgSecurityParameters usage is model-specific=0A= =0A= * msgFlags vs. securityLevel is model/implementation-specific=0A= =0A= * notifications must be able to cause creation of a session=0A= =0A= * security considerations must be model-specific=0A= =0A= * TDomain and TAddress are model-specific=0A= =0A= * MPSP changed to SMSP (Security Model security processing)=0A= =0A= Changes from revision -01- to -02-=0A= =0A= o wrote text for session establishment requirements section.=0A= =0A= o wrote text for session maintenance requirements section.=0A= =0A= o removed section on relation to SNMPv2-MIB=0A= =0A= o updated MIB module to pass smilint=0A= =0A= o Added Structure of the MIB module, and other expected MIB-related=0A= sections.=0A= =0A= o updated author address=0A= =0A= o corrected spelling=0A= =0A= o removed msgFlags appendix=0A= =0A= o Removed section on implementation considerations.=0A= =0A= o started modifying the security boilerplate to address TMS and MIB=0A= security issues=0A= =0A= o reorganized slightly to better separate requirements from proposed=0A= solution. This probably needs additional work.=0A= =0A= o removed section with sample protocols and sample=0A= tmSessionReference.=0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 40]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= o Added section for acronyms=0A= =0A= o moved section comparing parameter passing techniques to appendix.=0A= =0A= o Removed section on notification requirements.=0A= =0A= Changes from revision -00-=0A= =0A= o changed SSH references from I-Ds to RFCs=0A= =0A= o removed parameters from tmSessionReference for DTLS that revealed=0A= lower layer info.=0A= =0A= o Added TMS-MIB module=0A= =0A= o Added Internet-Standard Management Framework boilerplate=0A= =0A= o Added Structure of the MIB Module=0A= =0A= o Added MIB security considerations boilerplate (to be completed)=0A= =0A= o Added IANA Considerations=0A= =0A= o Added ASI Parameter table=0A= =0A= o Added discussion of Sessions=0A= =0A= o Added Open issues and Change Log=0A= =0A= o Rearranged sections=0A= =0A= Authors' Addresses=0A= =0A= David Harrington=0A= Huawei Technologies (USA)=0A= 1700 Alma Dr. Suite 100=0A= Plano, TX 75075=0A= USA=0A= =0A= Phone: +1 603 436 8634=0A= EMail: dharrington@huawei.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 41]=0A= =0C=0A= Internet-Draft SNMP Transport Subsystem February 2009=0A= =0A= =0A= Juergen Schoenwaelder=0A= Jacobs University Bremen=0A= Campus Ring 1=0A= 28725 Bremen=0A= Germany=0A= =0A= Phone: +49 421 200-3587=0A= EMail: j.schoenwaelder@iu-bremen.de=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Harrington & Schoenwaelder Expires August 29, 2009 [Page 42]=0A= =0C=0A= =0A= ------=_NextPart_000_0ADA_01C99745.FB30D970-- From cfinss@dial.pipex.com Sat Feb 28 12:36:14 2009 Return-Path: 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 AB68328C14C for ; Sat, 28 Feb 2009 12:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_05=-1.11, RCVD_IN_NJABL_PROXY=1.643] 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 G+SgvCBVcxFs for ; Sat, 28 Feb 2009 12:36:13 -0800 (PST) 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 62F7728C166 for ; Sat, 28 Feb 2009 12:36:13 -0800 (PST) X-Trace: 135987418/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.127/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.127 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FAMMuqUk+vBF//2dsb2JhbACDLDARihfJJgeCVIE/Bg X-IronPort-AV: E=Sophos;i="4.38,282,1233532800"; d="scan'208";a="135987418" X-IP-Direction: IN Received: from 1cust127.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.127]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Feb 2009 20:36:34 +0000 Message-ID: <000301c999db$aa141460$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> Date: Sat, 28 Feb 2009 20:32:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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] wg last call followup - tsm 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: , X-List-Received-Date: Sat, 28 Feb 2009 20:36:14 -0000 Editorial TSM s3.1.2 uses REQUIRES, an excellent word, one I use myself, but which does not appear in RFC2119. Is this a problem? If so, I suggest inverting the sentence from " The Transport Security Model REQUIRES that the security parameters used for a response are the same as those used for the corresponding request. " to "For the Transport Security Model, the security parameters used for a response MUST be the same as those used for the corresponding request. " 4.2 2) SSHTM requires a value for tmSameSecurity in the cache else processing stops 5.2 1). Here, 4.2 1) specifies the setting of tmSameSecurity to true so for clarity, I think that 4.2 2) should specify the setting of tmSameSecurity to false. 4.2 indentation changes half way through, I am unclear why. Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Thursday, February 26, 2009 8:53 AM Subject: [Isms] wg last call followup > On November 4th 2008, I started WG last call on the ISMS document set: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > [2] Transport Security Model for SNMP > > [3] Secure Shell Transport Model for SNMP > > [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models > > > We received some comments and the subsequent mailing list discussions > have led to some changes to the ISMS core documents. David just posted > revised IDs of the core documents: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > [2] Transport Security Model for SNMP > > [3] Secure Shell Transport Model for SNMP > > > Please take a look at the changes. Let us know by March 6th if there > are any major technical problems with the changes that must be fixed > before submitting the documents to the AD for publication. Please > keep in mind that we are going for Proposed Standard, the entry-level > maturity level for the standards track. > > If you find editorial issues, please report them clearly marked as > editorial issues. > From cfinss@dial.pipex.com Sat Feb 28 12:50:16 2009 Return-Path: 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 9C77628C0D0 for ; Sat, 28 Feb 2009 12:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.328 X-Spam-Level: X-Spam-Status: No, score=0.328 tagged_above=-999 required=5 tests=[AWL=-1.130, BAYES_40=-0.185, RCVD_IN_NJABL_PROXY=1.643] 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 jvl4ztIfuFcG for ; Sat, 28 Feb 2009 12:50:12 -0800 (PST) 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 981FD3A684B for ; Sat, 28 Feb 2009 12:50:11 -0800 (PST) X-Trace: 190175305/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.17.127/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.17.127 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4FAN4xqUk+vBF//2dsb2JhbACDLUGKF7oqCY5gAQaCVA6BMQY X-IronPort-AV: E=Sophos;i="4.38,282,1233532800"; d="scan'208";a="190175305" X-IP-Direction: IN Received: from 1cust127.tnt1.lnd3.gbr.da.uu.net (HELO allison) ([62.188.17.127]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Feb 2009 20:50:33 +0000 Message-ID: <006501c999dd$9de4a7c0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , References: <20090226075301.GA29686@elstar.iuhb02.iu-bremen.de> Date: Sat, 28 Feb 2009 20:45:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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] wg last call followup - sshtm 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: , X-List-Received-Date: Sat, 28 Feb 2009 20:50:16 -0000 I am still struggling with the 'Pasi problem' that he raised last November and although I recall seeing a message from him that he was satisfied, I cannot understand how it works in the current I-Ds; I cannot understand part of the I-Ds so tell me first what is meant to happen. Suppose securityName is alice and transport address is bob@example.com:ssh in a Command Generator. For a Request, sshtm passes bob to SSH and that is used for the session setup as per s5.3 3 1. The Command Responder uses bob for access control etc. The response will come back, SSH will pass a name of bob (s5.1 2) to stm as a securityName via tmStateReference which will pass it on to tsm which may or may not prefix it (s5.2 3) and then it will get passed to the application. So the application specified alice and got back bob. Is this how it is meant to work? Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Thursday, February 26, 2009 8:53 AM Subject: [Isms] wg last call followup > On November 4th 2008, I started WG last call on the ISMS document set: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > [2] Transport Security Model for SNMP > > [3] Secure Shell Transport Model for SNMP > > [4] Remote Authentication Dial-In User Service (RADIUS) Usage for Simple > Network Management Protocol (SNMP) Transport Models > > > We received some comments and the subsequent mailing list discussions > have led to some changes to the ISMS core documents. David just posted > revised IDs of the core documents: > > [1] Transport Subsystem for the Simple Network Management Protocol (SNMP) > > [2] Transport Security Model for SNMP > > [3] Secure Shell Transport Model for SNMP > > > Please take a look at the changes. Let us know by March 6th if there > are any major technical problems with the changes that must be fixed > before submitting the documents to the AD for publication. Please > keep in mind that we are going for Proposed Standard, the entry-level > maturity level for the standards track. > > If you find editorial issues, please report them clearly marked as > editorial issues. > > /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