From isms-bounces@lists.ietf.org Mon Jan 21 16:27:34 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH4B2-0004f0-Sm; Mon, 21 Jan 2008 16:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH4B1-0004et-LR for isms@ietf.org; Mon, 21 Jan 2008 16:27:31 -0500 Received: from qmta08.westchester.pa.mail.comcast.net ([76.96.62.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JH4B1-0005co-5o for isms@ietf.org; Mon, 21 Jan 2008 16:27:31 -0500 Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA08.westchester.pa.mail.comcast.net with comcast id fx9q1Y0060xGWP80502z00; Mon, 21 Jan 2008 21:27:30 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA12.westchester.pa.mail.comcast.net with comcast id fxTT1Y0084HwxpC3Y00000; Mon, 21 Jan 2008 21:27:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=gqqA0By4RFsA:10 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=EeJv3j_dsY_EuyRkGIEA:9 a=OhxqKlpmCyAFRp1kAPwCRoHUB5EA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: Date: Mon, 21 Jan 2008 16:27:27 -0500 Message-ID: <00e301c85c74$6be83180$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 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AchA6S3M1E/9ZjQ1QVesxeMmNT4cMAbWK76wAAyHbUA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: [Isms] moving isms documents nearer to completion X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, Here's a review of where we stand: TMSM: WGLC completed. all raised issues addressed in -11- all [todo] and [discuss] resolved AUTH48 correction: s/secutiry/security/ s/tmSameSession/tmSameSecurity/ TSM: WGLC completed. all raised issues addressed in -07- all [todo] and [discuss] resolved SSHTM: current draft is -09- sec 4.2 [todo/discuss] yet to be resolved. (user-principal vs host-principal) sec 5.3 [todo] yet to be resolved. (How to translate from authn-method-specific names to common tmSecurityName) need to verify UTF-8 references and SnmpAdminsString are consistent unresolved issues: dual authentication issues authentication of the notification receiver (http://www1.ietf.org/mail-archive/web/isms/current/msg02602.html) properly closing an SSH session whether to try to support v1/v2c transport-authn for ACM I think this is the complete list to date. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, December 17, 2007 3:13 PM > To: Dave Harrington > Subject: moving isms documents nearer to completion > > David, > > thanks for posting updated version in November. Am I correct that all > issues have been closed in the -tmsm and -transport-model documents? > If yes, I might be tempted to last call them again perhaps together > with the radius document. > > For the SSH document, we need to compile a concise list of the open > issues so that we can go through them and see how we can get them > closed. Are the TODO and discuss markers in the document complete? > > /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 15:45:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmTT-0005gr-Ud; Wed, 23 Jan 2008 15:45:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmTS-0005ge-DL for isms@ietf.org; Wed, 23 Jan 2008 15:45:30 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHmTR-0006VR-Ev for isms@ietf.org; Wed, 23 Jan 2008 15:45:30 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6906E8A359; Wed, 23 Jan 2008 21:45:28 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31202-04; Wed, 23 Jan 2008 21:45:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 719908A33A; Wed, 23 Jan 2008 21:45:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9C4C4488193; Wed, 23 Jan 2008 21:45:21 +0100 (CET) Date: Wed, 23 Jan 2008 21:45:21 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] moving isms documents nearer to completion Message-ID: <20080123204521.GA13934@elstar.local> Mail-Followup-To: David B Harrington , isms@ietf.org References: <00e301c85c74$6be83180$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e301c85c74$6be83180$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org On Mon, Jan 21, 2008 at 04:27:27PM -0500, David B Harrington wrote: > Here's a review of where we stand: > > TMSM: > WGLC completed. > all raised issues addressed in -11- > all [todo] and [discuss] resolved > AUTH48 correction: > s/secutiry/security/ > s/tmSameSession/tmSameSecurity/ > > TSM: > WGLC completed. > all raised issues addressed in -07- > all [todo] and [discuss] resolved > > SSHTM: > current draft is -09- > sec 4.2 [todo/discuss] yet to be resolved. (user-principal vs > host-principal) > sec 5.3 [todo] yet to be resolved. (How to translate from > authn-method-specific names to common tmSecurityName) > need to verify UTF-8 references and SnmpAdminsString are consistent > unresolved issues: > dual authentication issues > authentication of the notification receiver > > (http://www1.ietf.org/mail-archive/web/isms/current/msg02602.html) > properly closing an SSH session > whether to try to support v1/v2c transport-authn for ACM > > I think this is the complete list to date. Thanks David, this is helpful. I will now start separate email threads for the issues we still have open with the secshell document. In the subsequent discussion, we have to figure out (a) whether the issue is relevant wrt. our charter and (b) find and agree on a solution for the issue. I will also put up a wiki page tomorrow so that we have a place to track our progress. /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 15:46:20 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmUG-0007fM-Lk; Wed, 23 Jan 2008 15:46:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmUF-0007Vo-9M for isms@ietf.org; Wed, 23 Jan 2008 15:46:19 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHmUE-0006XA-VX for isms@ietf.org; Wed, 23 Jan 2008 15:46:19 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 72C6E8A261 for ; Wed, 23 Jan 2008 21:46:18 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31366-03-2; Wed, 23 Jan 2008 21:46:13 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B49428A33C; Wed, 23 Jan 2008 21:46:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1B4A24881AF; Wed, 23 Jan 2008 21:46:07 +0100 (CET) Date: Wed, 23 Jan 2008 21:46:07 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080123204607.GB13934@elstar.local> 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.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Isms] ISMS #1: tmStateReference X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org ISMS #1: tmStateReference Status: open Section 4.1 of draft-ietf-isms-secshell-09.txt contains the following text: The SSH Transport Model has the responsibility for explicitly releasing the complete tmStateReference and deleting the associated information when a session is closed. [DISCUSS: does thi smean an admin cannot preconfigure informationi for connections? How does this work with the TARGET-MIB?] I do not understand the discuss, clearly not in the context of this section. Q1.1: What is the issue here? Or is this an editorial left over? /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 15:46:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmUd-0001pj-0V; Wed, 23 Jan 2008 15:46:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmUc-0001jQ-6t for isms@ietf.org; Wed, 23 Jan 2008 15:46:42 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHmUb-00013g-Pn for isms@ietf.org; Wed, 23 Jan 2008 15:46:42 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4FAA28A29D for ; Wed, 23 Jan 2008 21:46:41 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31202-08; Wed, 23 Jan 2008 21:46:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93BA98A261; Wed, 23 Jan 2008 21:46:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E022C4881DD; Wed, 23 Jan 2008 21:46:34 +0100 (CET) Date: Wed, 23 Jan 2008 21:46:34 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080123204634.GC13934@elstar.local> 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.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Isms] ISMS #2: tmSecurityName X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org ISMS #2: tmSecurityName Status: open Section 4.2 of draft-ietf-isms-secshell-09.txt contains the following text: [TODO: standardize some dynamic mechanisms for SSHTM, per auth- protocol, such as user-auth, host-auth, etc. Make the list of authProtocols expandable, and provide default algorithms.] [DISCUSS: this cannot be implementation-dependent. It used to identify the layer 8 principal for use in such things as logging and for access control policy assignment. it must generate a predictable securityName representing the principal, regardless of the authentication mechanism. USM provides this by pre-configuration of the mapping of the auth protocol and auth-specific credentials to a securityName, in the usmUserTable. We MUST have the similar mapping, preferably done dynamically rather than statically. Therefore either the dynamic mapping algoruithm MUST be standardzied. or we MUST have a static mapping.] My understanding here is that the core of the issue is to mandate a specific mapping from the known SSH authentication mechanisms to the tmSecurityName. Q2.1: Is there agreement that we need to mandata a common mapping? Q2.2: If yes, which user authentication protocols do we have to consider and how does the mapping for each one look like? /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 15:47:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmVI-0002Ye-9L; Wed, 23 Jan 2008 15:47:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmVH-0002YY-BJ for isms@ietf.org; Wed, 23 Jan 2008 15:47:23 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHmVH-0006Yv-06 for isms@ietf.org; Wed, 23 Jan 2008 15:47:23 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 776408A33C for ; Wed, 23 Jan 2008 21:47:22 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31349-07; Wed, 23 Jan 2008 21:47:17 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C15BA8A261; Wed, 23 Jan 2008 21:47:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 27FFA4881F2; Wed, 23 Jan 2008 21:47:17 +0100 (CET) Date: Wed, 23 Jan 2008 21:47:17 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080123204717.GD13934@elstar.local> 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.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Isms] ISMS #3: passing username to the SSH layer X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org ISMS #3: passing username to the SSH layer Status: open Section 5.3 of draft-ietf-isms-secshell-09.txt contains the following text: 2) The provided transport domain, transport address, securityName and securityLevel are used to lookup an associated entry in the Local Configuration Datastore (LCD). Any model-specific information concerning the principal at the destination is extracted. This step allows preconfiguration of model-specific principals mapped to the transport/name/level, for example, for sending notifications. In an implementation-specific manner, pass the username extracted from the LCD to the SSH layer. [TODO: this may need to be standardized.] This might be the reverse operations of what we have in ISMS #2 but I am not sure. Q3.1: Clarify what the issue is that needs to be solved. Is it just the reverse of ISMS #2 or something bigger? Does it need to be standardized? Q3.2: If yes, how does the to be standardized mapping look like? /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 15:47:51 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmVj-0002ut-GK; Wed, 23 Jan 2008 15:47:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmVh-0002ua-WD for isms@ietf.org; Wed, 23 Jan 2008 15:47:50 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHmVh-000168-Kd for isms@ietf.org; Wed, 23 Jan 2008 15:47:49 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CB9F8A29D for ; Wed, 23 Jan 2008 21:47:49 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31366-06-7; Wed, 23 Jan 2008 21:47:44 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD4138A261; Wed, 23 Jan 2008 21:47:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1F79948821F; Wed, 23 Jan 2008 21:47:37 +0100 (CET) Date: Wed, 23 Jan 2008 21:47:37 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080123204737.GE13934@elstar.local> 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.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Isms] ISMS #4: UTF-8 and SnmpAdminString consistency X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org ISMS #4: UTF-8 and SnmpAdminString consistency Status: open Dave Harrington wrote: need to verify UTF-8 references and SnmpAdminsString are consistent It is unclear what the concern is here. Q4.1: What is the precise concern here? Q4.2: If there is an issue, is there a UTF-8 person who can help us to get this properly resolved? /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 15:48:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmVw-0003Dq-Lv; Wed, 23 Jan 2008 15:48:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmVv-0003Dd-Eg for isms@ietf.org; Wed, 23 Jan 2008 15:48:03 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHmVv-0006a8-4f for isms@ietf.org; Wed, 23 Jan 2008 15:48:03 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92B9F8A33A for ; Wed, 23 Jan 2008 21:48:02 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31633-02; Wed, 23 Jan 2008 21:47:57 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF7318A261; Wed, 23 Jan 2008 21:47:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 45FA1488234; Wed, 23 Jan 2008 21:47:57 +0100 (CET) Date: Wed, 23 Jan 2008 21:47:57 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080123204757.GF13934@elstar.local> 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.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Isms] ISMS #5: dual authentication issues X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org ISMS #5: dual authentication issues Status: open Dave Harrington wrote: dual authentication issues This issue requires better explanation. I assume it is about what happens if you run for example SNMPv3/USM over SSHTM. Q5.1: Is the issue well stated? Q5.2: What are the possible solutions and their pros/cons? /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 15:48:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmWD-0003S3-Se; Wed, 23 Jan 2008 15:48:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmWC-0003ON-7k for isms@ietf.org; Wed, 23 Jan 2008 15:48:20 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHmWB-0006aV-Ub for isms@ietf.org; Wed, 23 Jan 2008 15:48:20 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C3B38A261 for ; Wed, 23 Jan 2008 21:48:19 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31696-01; Wed, 23 Jan 2008 21:48:14 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFBA68A29D; Wed, 23 Jan 2008 21:48:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 454B4488249; Wed, 23 Jan 2008 21:48:14 +0100 (CET) Date: Wed, 23 Jan 2008 21:48:14 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080123204814.GG13934@elstar.local> 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.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Isms] ISMS #6: authentication of the notifications receiver X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org ISMS #6: authentication of the notifications receiver Status: open Dave Harrington wrote: authentication of the notification receiver We first need to clarify what is missing here to understand the issue. Q6.1: What is missing in this context? Q6.2: What are the possible solutions and their pros/cons? /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 15:48:41 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmWX-0003XS-3N; Wed, 23 Jan 2008 15:48:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmWW-0003XN-6W for isms@ietf.org; Wed, 23 Jan 2008 15:48:40 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHmWV-000181-Kw for isms@ietf.org; Wed, 23 Jan 2008 15:48:40 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 29F048A33A for ; Wed, 23 Jan 2008 21:48:39 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31697-02-2; Wed, 23 Jan 2008 21:48:34 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E11B8A261; Wed, 23 Jan 2008 21:48:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0468948825E; Wed, 23 Jan 2008 21:48:31 +0100 (CET) Date: Wed, 23 Jan 2008 21:48:30 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080123204830.GH13934@elstar.local> 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.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Isms] ISMS #7: properly closing an SSH session X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org ISMS #7: properly closing an SSH session Status: open Juergen Schoenwaelder wrote in http://www1.ietf.org/mail-archive/web/isms/current/msg02602.html: I have a question for SSH experts (hope there are some on this list). I am wondering what the proper way of closing the SSH session is in our case. Note that we run a single SSH channel over the SSH transport and there are several options now. a) Be brutal and simply close the underlying TCP connection. b) Be a bit less brutal and send an SSH_DISCONNECT with say a reason code of SSH_DISCONNECT_BY_APPLICATION and be done. c) Be friendly and play the game of doing an SSH_CHANNEL_CLOSE exchange followed by SSH_DISCONNECT. d) Be overly friendly by exchanging SSH_CHANNEL_EOF before exchanging SSH_CHANNEL_CLOSE and doing an SSH_DISCONNECT. My reading of the RFCs indicates that d) is not really required and of course a) will always work. There might be reasons to do b) although it is not clear which benefit one would get (since my understanding is that SSH_DISCONNECT does not impact who is closing the TCP connection and who has to go into wait state). Any suggestions what should be done to play the SSH game nicely? Q7.1: Is there a need to document this in the SSHTM specification or is this implementation detail? What do other documents using SSH do? Q7.2: If we decide to standardize the connection closing behaviour, what is the suggested way to close the SSH connection? /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 15:48:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmWp-0003dk-9K; Wed, 23 Jan 2008 15:48:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmWo-0003de-MW for isms@ietf.org; Wed, 23 Jan 2008 15:48:58 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHmWo-00018p-Aw for isms@ietf.org; Wed, 23 Jan 2008 15:48:58 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2B848A261 for ; Wed, 23 Jan 2008 21:48:57 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 31696-03; Wed, 23 Jan 2008 21:48:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D7CE8A29D; Wed, 23 Jan 2008 21:48:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 83CF348828B; Wed, 23 Jan 2008 21:48:51 +0100 (CET) Date: Wed, 23 Jan 2008 21:48:51 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20080123204851.GI13934@elstar.local> 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.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org ISMS #8: support of v1/v2c transport-authn for ACM Status: open David Harrington wrote: whether to try to support v1/v2c transport-authn for ACM I believe this concerns the question whether this WG should consider how SNMPv1/SNMPv2c, that is the community based security model, can utilize a secure transport. Q8.1: Is this question in scope of the WG charter? Q8.2: If yes, what needs to be done to make this happen? Is there a way to make existing code do something it was not expected to do? /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 15:55:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmcm-00016z-Vp; Wed, 23 Jan 2008 15:55:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmcl-00016r-B3 for isms@ietf.org; Wed, 23 Jan 2008 15:55:07 -0500 Received: from qmta04.westchester.pa.mail.comcast.net ([76.96.62.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHmck-0001JB-VL for isms@ietf.org; Wed, 23 Jan 2008 15:55:07 -0500 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA04.westchester.pa.mail.comcast.net with comcast id gfgb1Y00E16LCl0050Z500; Wed, 23 Jan 2008 20:55:06 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id gkv11Y00J4HwxpC3S00000; Wed, 23 Jan 2008 20:55:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=0uMUxz2US4D5OeUrmzYA:9 a=0iu4kPVFci1gffQzHusA:7 a=X48PRm9wSn86gN7G-L759_DEEl8A:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <20080123204607.GB13934@elstar.local> Subject: RE: [Isms] ISMS #1: tmStateReference Date: Wed, 23 Jan 2008 15:55:01 -0500 Message-ID: <017a01c85e02$391433f0$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: <20080123204607.GB13934@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcheAQOxDorczgE7Tvao1S6hBpm/MgAAK86Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, tmStateReference contains information that may be implementation-specific, and some of the information may need to be static to allow preconfiguration of state in the target-mib and associated tables. The text says it is the responsibility of the transport model to explicitly release the tmStateReference and associated information. Should this be implementation-dependent, and if so, are there any operational (e.g., notifications) or security issues with released or non-released transport/security state? dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 23, 2008 3:46 PM > To: isms@ietf.org > Subject: [Isms] ISMS #1: tmStateReference > > ISMS #1: tmStateReference > Status: open > > Section 4.1 of draft-ietf-isms-secshell-09.txt contains the following > text: > > The SSH Transport Model has the responsibility for explicitly > releasing the complete tmStateReference and deleting the associated > information when a session is closed. [DISCUSS: does thi smean an > admin cannot preconfigure informationi for connections? How does > this work with the TARGET-MIB?] > > I do not understand the discuss, clearly not in the context of this > section. > > Q1.1: What is the issue here? Or is this an editorial left over? > > /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@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 16:14:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmvZ-0001Nw-Sc; Wed, 23 Jan 2008 16:14:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHmvZ-0001Nr-2b for isms@ietf.org; Wed, 23 Jan 2008 16:14:33 -0500 Received: from qmta04.westchester.pa.mail.comcast.net ([76.96.62.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHmvY-00025P-Hr for isms@ietf.org; Wed, 23 Jan 2008 16:14:32 -0500 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA04.westchester.pa.mail.comcast.net with comcast id gbVd1Y00B17dt5G0511A00; Wed, 23 Jan 2008 21:14:32 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.westchester.pa.mail.comcast.net with comcast id glEU1Y00C4HwxpC3Z00000; Wed, 23 Jan 2008 21:14:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=_3gfOE6MorJLOs47HF4A:9 a=rVE8s3TMt8Hjubahx2wA:7 a=CJxy0vMzn4Acdr2rOVk2ugF6hhsA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <20080123204634.GC13934@elstar.local> Subject: RE: [Isms] ISMS #2: tmSecurityName Date: Wed, 23 Jan 2008 16:14:28 -0500 Message-ID: <017b01c85e04$f0b8c460$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: <20080123204634.GC13934@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcheARDO4YVrhgMjTWugzv8tx6z2FQAAWAQw X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, The issue here is a feature of USM and the SNMP architecture that may be needed with transport security transport models. Part of the purpose of securityName was to provide a consistent name for the principal regardless of security algorithm used for authn. Such a consistent name can then be used for logging, for configuring tables of entries, such as for notifications and access controls, with a known identifier for a principal. If we use the identity mapping for all SSH authn protocols, then there may be multiple securityNames generated for a given principal. That means that the VACM securityToGroup table will need to be configured with all the possible securityName variations for a given principal. If RADIUS is used to perform the securityName-to-group mappping, then the RADIUS server will need to be configured to recognize all the various securityNames for a given principal, or RADIUS would need to know all the various mappings from SSH authn protocols so the RADIUS server can provide the authn-specific identity to a model-independent securityName and groupName. The USM usertable allows a principal to be authenticated using a model-dependent identifier, and the authenticated identity is then mapped to a securityName. Multiple entries in the table can generate the same securityName, so a principal may have multiple ways they can be authenticated and still end up with the same securityname. How do we do this with a protocol like SSH, where we shouldn't even necessarily know about the underlying authn protocols? If this is done, it needs to be done by functionality that understands both SSH authn and the SNMP securityName, which is presumably the transport model. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 23, 2008 3:47 PM > To: isms@ietf.org > Subject: [Isms] ISMS #2: tmSecurityName > > ISMS #2: tmSecurityName > Status: open > > Section 4.2 of draft-ietf-isms-secshell-09.txt contains the following > text: > > [TODO: standardize some dynamic mechanisms for SSHTM, per auth- > protocol, such as user-auth, host-auth, etc. Make the list of > authProtocols expandable, and provide default algorithms.] > [DISCUSS: > this cannot be implementation-dependent. It used to identify the > layer 8 principal for use in such things as logging and for access > control policy assignment. it must generate a predictable > securityName representing the principal, regardless of the > authentication mechanism. USM provides this by > pre-configuration of > the mapping of the auth protocol and auth-specific credentials to a > securityName, in the usmUserTable. We MUST have the > similar mapping, > preferably done dynamically rather than statically. > Therefore either > the dynamic mapping algoruithm MUST be standardzied. or we > MUST have > a static mapping.] > > My understanding here is that the core of the issue is to mandate a > specific mapping from the known SSH authentication mechanisms to the > tmSecurityName. > > Q2.1: Is there agreement that we need to mandata a common mapping? > > Q2.2: If yes, which user authentication protocols do we have to > consider and how does the mapping for each one look like? > > /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@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 16:28:13 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHn8m-0006gj-SX; Wed, 23 Jan 2008 16:28:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHn8m-0006gV-1x for isms@ietf.org; Wed, 23 Jan 2008 16:28:12 -0500 Received: from qmta10.westchester.pa.mail.comcast.net ([76.96.62.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHn8j-0007gS-Rt for isms@ietf.org; Wed, 23 Jan 2008 16:28:12 -0500 Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA10.westchester.pa.mail.comcast.net with comcast id glKA1Y00J0Fqzac5A01k00; Wed, 23 Jan 2008 21:28:03 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id glU51Y0044HwxpC3U00000; Wed, 23 Jan 2008 21:28:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=XrVOHZIUxlUA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=tKQr1HaqZ4-aYgN54OwA:9 a=E9aRwUHmHVVn9Bryw60A:7 a=Jl4HrXO6X3GKel3WH_8ZoWif9SwA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , References: <20080123204717.GD13934@elstar.local> Subject: RE: [Isms] ISMS #3: passing username to the SSH layer Date: Wed, 23 Jan 2008 16:28:05 -0500 Message-ID: <018501c85e06$d7566fc0$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: <20080123204717.GD13934@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcheASk+2JIMY15WRtqxbsxtfaLfugAA/PtQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I think this is slightly different than #2, although it is related to #2. In much the same way that multiple authn protocols can be mapped to a single securityname for incoming messages, a single securityname can be mapped to multiple authn protocols for outgoing messages. Unless the transform is always the identity transform, this may need to be standardized so we can be sure we get the right security credentials for the outgoing message. This is probably most important for notifications, where an administrator might want to ensure that the notification is sent using a specific principal using a specific secure-enough protocol. An administrator needs to be able to configure the appropriate references to securityname and probably to authn protocol for notifications (e.g., the target-table stuff). To make it possible to configure this using SNMP, administrators should be to be able to configure this in a vendor-independent manner, so we may need to standardize some of this. If this is left as an implementation-dependent detail, then it becomes much harder for administrators to configure target-table et al across their SNMP domain. Put another way, the target-table stuff is actually part of the LCD, and it is unclear whether we have everything we need standardized enough to work as designed. We need to determine whether there is more stuff in the LCD that needs standardizing in order to work for various use cases. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 23, 2008 3:47 PM > To: isms@ietf.org > Subject: [Isms] ISMS #3: passing username to the SSH layer > > ISMS #3: passing username to the SSH layer > Status: open > > Section 5.3 of draft-ietf-isms-secshell-09.txt contains the following > text: > > 2) The provided transport domain, transport address, > securityName and > securityLevel are used to lookup an associated entry in the Local > Configuration Datastore (LCD). Any model-specific information > concerning the principal at the destination is extracted. > This step > allows preconfiguration of model-specific principals mapped to the > transport/name/level, for example, for sending notifications. > > In an implementation-specific manner, pass the username extracted > from the LCD to the SSH layer. [TODO: this may need to be > standardized.] > > This might be the reverse operations of what we have in ISMS #2 but I > am not sure. > > Q3.1: Clarify what the issue is that needs to be solved. Is it just > the reverse of ISMS #2 or something bigger? Does it need to be > standardized? > > Q3.2: If yes, how does the to be standardized mapping look like? > > /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@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 16:32:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnD3-0002C2-0P; Wed, 23 Jan 2008 16:32:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnD1-0002Al-Gy for isms@ietf.org; Wed, 23 Jan 2008 16:32:35 -0500 Received: from qmta07.westchester.pa.mail.comcast.net ([76.96.62.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHnD0-0007nq-2G for isms@ietf.org; Wed, 23 Jan 2008 16:32:35 -0500 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA07.westchester.pa.mail.comcast.net with comcast id gjP81Y00K16LCl0050AT00; Wed, 23 Jan 2008 21:32:33 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id glYV1Y00L4HwxpC3S00000; Wed, 23 Jan 2008 21:32:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=rRm1hiugaW8A:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=gn_b54-SMBcyfO_oZ_kA:9 a=JQd5S5liQlcCfcOaL_MA:7 a=syqiRCatizyxmZWGBMXR6vIH3acA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , References: <20080123204737.GE13934@elstar.local> Subject: RE: [Isms] ISMS #4: UTF-8 and SnmpAdminString consistency Date: Wed, 23 Jan 2008 16:32:29 -0500 Message-ID: <018e01c85e07$7531a930$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: <20080123204737.GE13934@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcheAT9Mp5Qdx+x6RpulB+d5IA36MwABaBqw X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, UTF-8 was defined in an RFC, and SnmpAdminString references that RFC. Somebody pointed out that the original RFC was obsoleted(?) and we should reference the updated RFC. But there are significant differences between the two UTF8 RFCs, and they may impact the definition of SnmpAdminString. So it becomes unclear whether our reference should remain to the old RFC, or to the new RFC for UTF8. The differences are over my head, and we need a UTF8 expert to look at the differences and look at SnmpAdminString and advise us. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 23, 2008 3:48 PM > To: isms@ietf.org > Subject: [Isms] ISMS #4: UTF-8 and SnmpAdminString consistency > > ISMS #4: UTF-8 and SnmpAdminString consistency > Status: open > > Dave Harrington wrote: > > need to verify UTF-8 references and SnmpAdminsString are > consistent > > It is unclear what the concern is here. > > Q4.1: What is the precise concern here? > > Q4.2: If there is an issue, is there a UTF-8 person who can help us > to get this properly resolved? > > /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@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 16:35:17 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnFd-0007NG-1I; Wed, 23 Jan 2008 16:35:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnFb-0007Fl-Vp for isms@ietf.org; Wed, 23 Jan 2008 16:35:16 -0500 Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHnFb-0002fT-LO for isms@ietf.org; Wed, 23 Jan 2008 16:35:15 -0500 Received: from atlantis.pc.cs.cmu.edu (ATLANTIS.PC.CS.CMU.EDU [128.2.216.110]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0NLZ9x5000415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2008 16:35:09 -0500 (EST) Date: Wed, 23 Jan 2008 16:35:09 -0500 From: Jeffrey Hutzelman To: David Harrington , isms@ietf.org Subject: RE: [Isms] ISMS #1: tmStateReference Message-ID: <6B96CA4988BA3B036169B819@atlantis.pc.cs.cmu.edu> In-Reply-To: <017a01c85e02$391433f0$0600a8c0@china.huawei.com> References: <20080123204607.GB13934@elstar.local> <017a01c85e02$391433f0$0600a8c0@china.huawei.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: jhutz@cmu.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --On Wednesday, January 23, 2008 03:55:01 PM -0500 David Harrington wrote: > Hi, > > tmStateReference contains information that may be > implementation-specific, and some of the information may need to be > static to allow preconfiguration of state in the target-mib and > associated tables. > > The text says it is the responsibility of the transport model to > explicitly release the tmStateReference and associated information. > Should this be implementation-dependent, and if so, are there any > operational (e.g., notifications) or security issues with released or > non-released transport/security state? It sounds like "explicitly release" in this case means things like freeing the memory occupied by the tmStateReference or whatever it points to, or returning an object or identifier to a free pool. Both the mechanism and timing of this, as well as who is responsible for doing it, seem highly implementation-dependent. I don't think this is a detail we need to specify. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 16:41:08 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnLH-0001WK-Ow; Wed, 23 Jan 2008 16:41:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnLG-0001WA-Kc for isms@ietf.org; Wed, 23 Jan 2008 16:41:06 -0500 Received: from qmta07.westchester.pa.mail.comcast.net ([76.96.62.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHnLG-0007xw-90 for isms@ietf.org; Wed, 23 Jan 2008 16:41:06 -0500 Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA07.westchester.pa.mail.comcast.net with comcast id gkJt1Y00P0vyq2s0506l00; Wed, 23 Jan 2008 21:41:06 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id glh21Y0054HwxpC3R00000; Wed, 23 Jan 2008 21:41:05 +0000 X-Authority-Analysis: v=1.0 c=1 a=w5AnnzxsK2wA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=msxMkv4MpKb8q7hsc1gA:9 a=juQv68B_bY9wd1t-F10A:7 a=4vrVThRcNyh1_MRtK6k2J45qvy0A:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <20080123204757.GF13934@elstar.local> Subject: RE: [Isms] ISMS #5: dual authentication issues Date: Wed, 23 Jan 2008 16:41:02 -0500 Message-ID: <018f01c85e08$a68a2600$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: <20080123204757.GF13934@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcheAUGuVNDvPvWHRfCM5o0KkcQ5GAABjy8w X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, Yes, this issue is about using two different authn mechansims for the same message. The SNMP architecture, and the ASIs, assume you will use only one protocol to authenticate a principal. With secure transport AND a security model, we end up with problems. One issue is which authenticated identity is used for access controls? Our current solution is to make the "inner-most" authentication (e.g., the one specified in the SNMP message) the one that sets the securityName for use with access control. That is consistent with RFC3412 and RFC3584, which says the security model is chosen by the message processing model. A second issue is whether, for a message to be secured by both USM and transport security (SSH), the engine knows which credentials to use for the USM security and which for the transport security, since the ASIs do not provide both. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 23, 2008 3:48 PM > To: isms@ietf.org > Subject: [Isms] ISMS #5: dual authentication issues > > ISMS #5: dual authentication issues > Status: open > > Dave Harrington wrote: > > dual authentication issues > > This issue requires better explanation. I assume it is about what > happens if you run for example SNMPv3/USM over SSHTM. > > Q5.1: Is the issue well stated? > > Q5.2: What are the possible solutions and their pros/cons? > > /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@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 16:43:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnO3-0005nw-Ph; Wed, 23 Jan 2008 16:43:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnO2-0005gA-Jd for isms@ietf.org; Wed, 23 Jan 2008 16:43:58 -0500 Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHnO2-0002r1-6W for isms@ietf.org; Wed, 23 Jan 2008 16:43:58 -0500 Received: from atlantis.pc.cs.cmu.edu (ATLANTIS.PC.CS.CMU.EDU [128.2.216.110]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0NLhpvG001162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2008 16:43:51 -0500 (EST) Date: Wed, 23 Jan 2008 16:43:51 -0500 From: Jeffrey Hutzelman To: David Harrington , isms@ietf.org Subject: RE: [Isms] ISMS #2: tmSecurityName Message-ID: <4C7DC417130524F400AE3ABA@atlantis.pc.cs.cmu.edu> In-Reply-To: <017b01c85e04$f0b8c460$0600a8c0@china.huawei.com> References: <20080123204634.GC13934@elstar.local> <017b01c85e04$f0b8c460$0600a8c0@china.huawei.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: jhutz@cmu.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --On Wednesday, January 23, 2008 04:14:28 PM -0500 David Harrington wrote: > How do we do this with a protocol like SSH, where we shouldn't even > necessarily know about the underlying authn protocols? If this is > done, it needs to be done by functionality that understands both SSH > authn and the SNMP securityName, which is presumably the transport > model. Well, that depends on what direction we're talking about. SSH has one set of mechanisms that prove the identity of the SSH server to the SSH client (key exchange), and a second set which prove the identity of the SSH client to the SSH server (user authentication). In the case of user authentication, ssh provides for a "user name" which is sent by the client, and the job of the userauth method is to prove that the client is authorized to act for that user. The authentication name used by the underlying mechanism is, of course, mechanism-specific, but the resulting username is mechanism independent. In the traditional case, the username corresponds to the name of an account on the machine where the SSH server runs, and any requests made by the client to do things like run subsystems or start shells are run as that user. It seems quite clear to me that for SNMP, the SSH username should be used directly as the SNMP securityName, with no need for any further mapping. The mapping from, say, a certificate or Kerberos principal name to the ssh username is handled by the particular userauth method in use. The reverse direction is, as you know, much trickier. This is partly because SSH has no formal model for naming servers, and partly because the practical ways to name such things do not look anything like usernames. For at least some cases, I believe we've agreed to solve this problem by requiring that responses be sent back along the same session as the request, eliminating the need to establish an SSH connection in the "wrong" direction. There may be some open issues here; I simply don't recall. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 16:45:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnPL-0001OY-IP; Wed, 23 Jan 2008 16:45:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnPK-0001OF-3B for isms@ietf.org; Wed, 23 Jan 2008 16:45:18 -0500 Received: from qmta02.westchester.pa.mail.comcast.net ([76.96.62.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHnPI-000836-NQ for isms@ietf.org; Wed, 23 Jan 2008 16:45:18 -0500 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA02.westchester.pa.mail.comcast.net with comcast id gdly1Y00E17dt5G050od00; Wed, 23 Jan 2008 21:45:16 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.westchester.pa.mail.comcast.net with comcast id gllD1Y0024HwxpC3Z00000; Wed, 23 Jan 2008 21:45:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=GlLcdvnCslMA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=LniU-B3rkDXjd8AkmhEA:9 a=qSG-JZfeQgyxPA0SiTgA:7 a=GMjcqIpD9UQOjLR4ps8DOkKhiukA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <20080123204814.GG13934@elstar.local> Subject: RE: [Isms] ISMS #6: authentication of the notifications receiver Date: Wed, 23 Jan 2008 16:45:12 -0500 Message-ID: <019001c85e09$3be6d7c0$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: <20080123204814.GG13934@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcheAUs48Ecqf/VrSTut2aA22PD3AQAB4Y7g X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, We have not resolved whether the principal associated with a notification receiver must be a principal (aka user) or whether a hostname is adequate. There are many aspects of this problem, and the WG needs to discuss these and reach some consensus on how we want to proceed. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 23, 2008 3:48 PM > To: isms@ietf.org > Subject: [Isms] ISMS #6: authentication of the notifications receiver > > ISMS #6: authentication of the notifications receiver > Status: open > > Dave Harrington wrote: > > authentication of the notification receiver > > We first need to clarify what is missing here to understand the issue. > > Q6.1: What is missing in this context? > > Q6.2: What are the possible solutions and their pros/cons? > > /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@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 16:55:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnYn-0002Tj-OR; Wed, 23 Jan 2008 16:55:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnYm-0002Td-Fb for isms@ietf.org; Wed, 23 Jan 2008 16:55:04 -0500 Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHnYm-0008GZ-2l for isms@ietf.org; Wed, 23 Jan 2008 16:55:04 -0500 Received: from atlantis.pc.cs.cmu.edu (ATLANTIS.PC.CS.CMU.EDU [128.2.216.110]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0NLsxso002615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2008 16:54:59 -0500 (EST) Date: Wed, 23 Jan 2008 16:54:59 -0500 From: Jeffrey Hutzelman To: David Harrington , j.schoenwaelder@jacobs-university.de, isms@ietf.org Subject: RE: [Isms] ISMS #4: UTF-8 and SnmpAdminString consistency Message-ID: In-Reply-To: <018e01c85e07$7531a930$0600a8c0@china.huawei.com> References: <20080123204737.GE13934@elstar.local> <018e01c85e07$7531a930$0600a8c0@china.huawei.com> 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-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: jhutz@cmu.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --On Wednesday, January 23, 2008 04:32:29 PM -0500 David Harrington wrote: > Hi, > > UTF-8 was defined in an RFC, and SnmpAdminString references that RFC. > Somebody pointed out that the original RFC was obsoleted(?) and we > should reference the updated RFC. But there are significant > differences between the two UTF8 RFCs, and they may impact the > definition of SnmpAdminString. So it becomes unclear whether our > reference should remain to the old RFC, or to the new RFC for UTF8. > > The differences are over my head, and we need a UTF8 expert to look at > the differences and look at SnmpAdminString and advise us. UTF-8 was originally defined in RFC2044, UTR #4, and ISO-10464-1 annex R. RFC2044 was obsoleted by RFC2279, which notes that a description can also be found in Unicode 2.0. RFC2279 was obsoleted by RFC3629. To which of these does the definition of SnmpAdminString refer? -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 17:04:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnhx-0006iQ-96; Wed, 23 Jan 2008 17:04:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnhv-0006iJ-OL for isms@ietf.org; Wed, 23 Jan 2008 17:04:31 -0500 Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHnhv-0003Ja-AG for isms@ietf.org; Wed, 23 Jan 2008 17:04:31 -0500 Received: from atlantis.pc.cs.cmu.edu (ATLANTIS.PC.CS.CMU.EDU [128.2.216.110]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0NM4IZl002979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2008 17:04:18 -0500 (EST) Date: Wed, 23 Jan 2008 17:04:18 -0500 From: Jeffrey Hutzelman To: David Harrington , isms@ietf.org Subject: RE: [Isms] ISMS #5: dual authentication issues Message-ID: In-Reply-To: <018f01c85e08$a68a2600$0600a8c0@china.huawei.com> References: <20080123204757.GF13934@elstar.local> <018f01c85e08$a68a2600$0600a8c0@china.huawei.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: jhutz@cmu.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --On Wednesday, January 23, 2008 04:41:02 PM -0500 David Harrington wrote: > Hi, > > Yes, this issue is about using two different authn mechansims for the > same message. The SNMP architecture, and the ASIs, assume you will use > only one protocol to authenticate a principal. With secure transport > AND a security model, we end up with problems. > > One issue is which authenticated identity is used for access controls? > Our current solution is to make the "inner-most" authentication (e.g., > the one specified in the SNMP message) the one that sets the > securityName for use with access control. That is consistent with > RFC3412 and RFC3584, which says the security model is chosen by the > message processing model. I think this is the correct answer. Under the SNMPv3 architecture (which I don't believe we are not empowered to change), the only way transport security gets its foot in the door is through the use of the transport security model. If some other security model is used, then transport security is completely irrelevant, except that if you try to use it and get it wrong, then things will probably not work. :-) > A second issue is whether, for a message to be secured by both USM and > transport security (SSH), the engine knows which credentials to use > for the USM security and which for the transport security, since the > ASIs do not provide both. If the transport security model is not used, there is no binding between transport security and the authenticated identities used for access control, so I don't think the message can truly be said to be "secured" by transport security. As I understand it, the ASI's provide only the securityName; the actual underlying credentials (USM keys, Kerberos keys, certificates, etc) used are obtained in a fashion that is at least partly implementation-dependent. I don't think we need to describe how to send messages using transport security along with a non-transport security model. Even if we choose to permit this behavior, I don't think we need to describe how to make it work when the credentials are not the same. The fact that it works at all on the receiving side is more an indication that we haven't broken the abstraction than an actual goal in itself. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 17:06:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnkJ-0003B6-Fs; Wed, 23 Jan 2008 17:06:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnkI-000367-HG for isms@ietf.org; Wed, 23 Jan 2008 17:06:58 -0500 Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHnkI-0008V3-60 for isms@ietf.org; Wed, 23 Jan 2008 17:06:58 -0500 Received: from atlantis.pc.cs.cmu.edu (ATLANTIS.PC.CS.CMU.EDU [128.2.216.110]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0NM6qxD003085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2008 17:06:53 -0500 (EST) Date: Wed, 23 Jan 2008 17:06:52 -0500 From: Jeffrey Hutzelman To: j.schoenwaelder@jacobs-university.de, isms@ietf.org Subject: Re: [Isms] ISMS #7: properly closing an SSH session Message-ID: <57D0B037A598025732816178@atlantis.pc.cs.cmu.edu> In-Reply-To: <20080123204830.GH13934@elstar.local> References: <20080123204830.GH13934@elstar.local> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: jhutz@cmu.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --On Wednesday, January 23, 2008 09:48:30 PM +0100 Juergen Schoenwaelder wrote: > Q7.1: Is there a need to document this in the SSHTM specification or > is this implementation detail? What do other documents using SSH > do? No. The mechanisms for closing SSH sessions are specified by SSH. It is inappropriate for SSHTM to discuss connection setup at the layer of specific SSH protocol messages, any more than a TCP transport model would tell you when to send SYN, ACK, and RST messages to manage a TCP connection. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 17:07:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnkh-0004jR-PW; Wed, 23 Jan 2008 17:07:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnkg-0004c7-Fd for isms@ietf.org; Wed, 23 Jan 2008 17:07:22 -0500 Received: from qmta04.westchester.pa.mail.comcast.net ([76.96.62.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHnkf-0008Vh-Sx for isms@ietf.org; Wed, 23 Jan 2008 17:07:22 -0500 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA04.westchester.pa.mail.comcast.net with comcast id gcXn1Y00Q1GhbT8050tk00; Wed, 23 Jan 2008 22:07:21 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.westchester.pa.mail.comcast.net with comcast id gm7H1Y00V4HwxpC3T00000; Wed, 23 Jan 2008 22:07:21 +0000 X-Authority-Analysis: v=1.0 c=1 a=yzxyBjtJUVUA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=iFpsZZyImvw08SMrQYoA:9 a=Op7-zDd23Q_we9tJH2zoi2HgZLUA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , References: <20080123204851.GI13934@elstar.local> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Wed, 23 Jan 2008 17:07:17 -0500 Message-ID: <019101c85e0c$51af2370$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: <20080123204851.GI13934@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcheAWc73nO9Vk4WTiyoHipsz7CIRQAB/MFw X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, Bert Wijnen wrote: " Now I do see that in sect 2.3 you explain/state that the Transport Security Model cannot be used with SNMPv1 and SNMPv2c. I wonder if this is what the operator/user community wants/accepts??" If we deliver something that does not meet what operators want, and they refuse to use our ISMS standard (as well as our USM standard), have we wasted another two and a half years? To standardize the use of SNMPv1/v2c over secure transports means we would need to modify some existing elements of procedure in RFC3584 and RFC3412 (I think those are the only two). The changes could be conditional changes based on the existence of, or contents of, tmStateReference so the elements of procedure would be backwards compatible with existing implementations. Basically, a secure transport model can specify which security model should be used to determine securityName, but in the absence of a secure transport model determination, the MPM decides which security model should be used. The work would need to specify something like "to support this functionality, the elements of procedure of RFC3412 are amended by the following change: ...." I think the result would be more in keeping with what operators want. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, January 23, 2008 3:49 PM > To: isms@ietf.org > Subject: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > ISMS #8: support of v1/v2c transport-authn for ACM > Status: open > > David Harrington wrote: > > whether to try to support v1/v2c transport-authn for ACM > > I believe this concerns the question whether this WG should consider > how SNMPv1/SNMPv2c, that is the community based security model, can > utilize a secure transport. > > Q8.1: Is this question in scope of the WG charter? > > Q8.2: If yes, what needs to be done to make this happen? Is there a > way to make existing code do something it was not expected to > do? > > /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@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 17:13:19 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnqR-0007i6-Fz; Wed, 23 Jan 2008 17:13:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnqQ-0007hr-68 for isms@ietf.org; Wed, 23 Jan 2008 17:13:18 -0500 Received: from qmta02.westchester.pa.mail.comcast.net ([76.96.62.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHnqP-0000h1-T1 for isms@ietf.org; Wed, 23 Jan 2008 17:13:18 -0500 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA02.westchester.pa.mail.comcast.net with comcast id gj9u1Y00Q1GhbT8050HW00; Wed, 23 Jan 2008 22:13:17 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.westchester.pa.mail.comcast.net with comcast id gmDE1Y0064HwxpC3T00000; Wed, 23 Jan 2008 22:13:17 +0000 X-Authority-Analysis: v=1.0 c=1 a=rRm1hiugaW8A:10 a=rAnwrEbGM8q9yKqhrHMA:9 a=XdnOVYWeVnrlqlmMGdtoRDWN3xAA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=XF7b4UCPwd8A:10 From: "David Harrington" To: "'Jeffrey Hutzelman'" , , References: <20080123204737.GE13934@elstar.local> <018e01c85e07$7531a930$0600a8c0@china.huawei.com> Subject: RE: [Isms] ISMS #4: UTF-8 and SnmpAdminString consistency Date: Wed, 23 Jan 2008 17:13:14 -0500 Message-ID: <019201c85e0d$261957c0$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.3138 Thread-index: AcheCpwAdDDFNgO6REyZo+EqH2EZuQAAmN/A X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org The definition of SnmpAdminString (in RFC3411) refers to RFC2279. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Wednesday, January 23, 2008 4:55 PM > To: David Harrington; j.schoenwaelder@jacobs-university.de; > isms@ietf.org > Cc: jhutz@cmu.edu > Subject: RE: [Isms] ISMS #4: UTF-8 and SnmpAdminString consistency > > --On Wednesday, January 23, 2008 04:32:29 PM -0500 David Harrington > wrote: > > > Hi, > > > > UTF-8 was defined in an RFC, and SnmpAdminString references > that RFC. > > Somebody pointed out that the original RFC was obsoleted(?) and we > > should reference the updated RFC. But there are significant > > differences between the two UTF8 RFCs, and they may impact the > > definition of SnmpAdminString. So it becomes unclear whether our > > reference should remain to the old RFC, or to the new RFC for UTF8. > > > > The differences are over my head, and we need a UTF8 expert > to look at > > the differences and look at SnmpAdminString and advise us. > > UTF-8 was originally defined in RFC2044, UTR #4, and > ISO-10464-1 annex R. > > RFC2044 was obsoleted by RFC2279, which notes that a > description can also > be found in Unicode 2.0. > > RFC2279 was obsoleted by RFC3629. > > To which of these does the definition of SnmpAdminString refer? > > -- Jeff > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 17:22:28 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnzI-0004FY-4Y; Wed, 23 Jan 2008 17:22:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHnzH-0004FT-Ai for isms@ietf.org; Wed, 23 Jan 2008 17:22:27 -0500 Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHnzG-0004sH-Sy for isms@ietf.org; Wed, 23 Jan 2008 17:22:27 -0500 Received: from atlantis.pc.cs.cmu.edu (ATLANTIS.PC.CS.CMU.EDU [128.2.216.110]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0NMMD65004110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2008 17:22:13 -0500 (EST) Date: Wed, 23 Jan 2008 17:22:13 -0500 From: Jeffrey Hutzelman To: David Harrington , j.schoenwaelder@jacobs-university.de, isms@ietf.org Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Message-ID: <9AEF930B6C54D4349E40858E@atlantis.pc.cs.cmu.edu> In-Reply-To: <019101c85e0c$51af2370$0600a8c0@china.huawei.com> References: <20080123204851.GI13934@elstar.local> <019101c85e0c$51af2370$0600a8c0@china.huawei.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: jhutz@cmu.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --On Wednesday, January 23, 2008 05:07:17 PM -0500 David Harrington wrote: > Hi, > > Bert Wijnen wrote: > " Now I do see that in sect 2.3 you explain/state that the Transport > Security Model cannot be used with SNMPv1 and SNMPv2c. > I wonder if this is what the operator/user community > wants/accepts??" > > If we deliver something that does not meet what operators want, and > they refuse to use our ISMS standard (as well as our USM standard), > have we wasted another two and a half years? > > To standardize the use of SNMPv1/v2c over secure transports means we > would need to modify some existing elements of procedure in RFC3584 > and RFC3412 (I think those are the only two). The changes could be > conditional changes based on the existence of, or contents of, > tmStateReference so the elements of procedure would be backwards > compatible with existing implementations. > > Basically, a secure transport model can specify which security model > should be used to determine securityName, but in the absence of a > secure transport model determination, the MPM decides which security > model should be used. The work would need to specify something like > "to support this functionality, the elements of procedure of RFC3412 > are amended by the following change: ...." > > I think the result would be more in keeping with what operators want. Hrm. Wouldn't this have the effect that if SNMPv3 is used with USM over SSH case, it is USM that gets ignored rather than SSH? I don't think we want that. OTOH, I'm inclined to agree that what you describe is likely to result in reasonable behavior for SNMPv1/v2c. I think to make this work, we need to distinguish between MPM's that actually have the ability to negotiate a security model from those that do not. Having just reread the charter, I'm unclear on whether this is in scope. The language "The new security model must not modify any other aspects of SNMPv3 protocol as defined in STD 62" seems intended to limit what we can do, but I'm not sure to what extent. I do agree that making this work is worthwhile, and probably requires changes to the EoP. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 17:25:33 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHo2H-0000kP-UL; Wed, 23 Jan 2008 17:25:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHo2H-0000g0-AI for isms@ietf.org; Wed, 23 Jan 2008 17:25:33 -0500 Received: from qmta05.westchester.pa.mail.comcast.net ([76.96.62.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHo2G-0001R9-QS for isms@ietf.org; Wed, 23 Jan 2008 17:25:33 -0500 Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA05.westchester.pa.mail.comcast.net with comcast id gePi1Y0060bG4ec050tE00; Wed, 23 Jan 2008 22:25:32 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.westchester.pa.mail.comcast.net with comcast id gmRV1Y0054HwxpC3P00000; Wed, 23 Jan 2008 22:25:32 +0000 X-Authority-Analysis: v=1.0 c=1 a=w5AnnzxsK2wA:10 a=zrZpL3t1saJMLTYX52gA:9 a=q-0xGiuEnHvqQNnagkQA:7 a=X3ga2psDtBDOBfNof911qDVqHlAA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=oqs56FR1YJwA:10 From: "David Harrington" To: "'Jeffrey Hutzelman'" , References: <20080123204757.GF13934@elstar.local> <018f01c85e08$a68a2600$0600a8c0@china.huawei.com> Subject: RE: [Isms] ISMS #5: dual authentication issues Date: Wed, 23 Jan 2008 17:25:29 -0500 Message-ID: <019301c85e0e$dc086570$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.3138 Thread-index: AcheC+31k4+VoVDqRDSyrOzbGSznhQAAXlig X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org So you favor adding text that says when using a secure transport model, the security model field in the SNMPv3 message MUST be set to TSM? or is it text that says if you are using a non-transport security model, such as the community security model, then you MUST NOT (SHOULD NOT) use a secure transport model? That would imply the (possibly already existing) module which constructs the message must now know which transport model is being used, and whether it is secure, and error out under some conditions. Would that violate architectural modularity? dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Wednesday, January 23, 2008 5:04 PM > To: David Harrington; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: RE: [Isms] ISMS #5: dual authentication issues > > --On Wednesday, January 23, 2008 04:41:02 PM -0500 David Harrington > wrote: > > > Hi, > > > > Yes, this issue is about using two different authn > mechansims for the > > same message. The SNMP architecture, and the ASIs, assume > you will use > > only one protocol to authenticate a principal. With secure transport > > AND a security model, we end up with problems. > > > > One issue is which authenticated identity is used for > access controls? > > Our current solution is to make the "inner-most" > authentication (e.g., > > the one specified in the SNMP message) the one that sets the > > securityName for use with access control. That is consistent with > > RFC3412 and RFC3584, which says the security model is chosen by the > > message processing model. > > I think this is the correct answer. Under the SNMPv3 > architecture (which I > don't believe we are not empowered to change), the only way transport > security gets its foot in the door is through the use of the > transport > security model. If some other security model is used, then transport > security is completely irrelevant, except that if you try to > use it and get > it wrong, then things will probably not work. :-) > > > > A second issue is whether, for a message to be secured by > both USM and > > transport security (SSH), the engine knows which credentials to use > > for the USM security and which for the transport security, since the > > ASIs do not provide both. > > If the transport security model is not used, there is no > binding between > transport security and the authenticated identities used for access > control, so I don't think the message can truly be said to be > "secured" by > transport security. > > As I understand it, the ASI's provide only the securityName; > the actual > underlying credentials (USM keys, Kerberos keys, > certificates, etc) used > are obtained in a fashion that is at least partly > implementation-dependent. > > I don't think we need to describe how to send messages using > transport > security along with a non-transport security model. Even if > we choose to > permit this behavior, I don't think we need to describe how > to make it work > when the credentials are not the same. The fact that it > works at all on > the receiving side is more an indication that we haven't broken the > abstraction than an actual goal in itself. > > -- Jeff > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 17:38:09 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHoET-0000jk-0F; Wed, 23 Jan 2008 17:38:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHoES-0000jf-GB for isms@ietf.org; Wed, 23 Jan 2008 17:38:08 -0500 Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHoES-0005Jy-3C for isms@ietf.org; Wed, 23 Jan 2008 17:38:08 -0500 Received: from atlantis.pc.cs.cmu.edu (ATLANTIS.PC.CS.CMU.EDU [128.2.216.110]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0NMbwCA004752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2008 17:37:58 -0500 (EST) Date: Wed, 23 Jan 2008 17:37:58 -0500 From: Jeffrey Hutzelman To: David Harrington , j.schoenwaelder@jacobs-university.de, isms@ietf.org Subject: RE: [Isms] ISMS #4: UTF-8 and SnmpAdminString consistency Message-ID: <7FFE3AE221DC97079A342ED7@atlantis.pc.cs.cmu.edu> In-Reply-To: <019201c85e0d$261957c0$0600a8c0@china.huawei.com> References: <20080123204737.GE13934@elstar.local> <018e01c85e07$7531a930$0600a8c0@china.huawei.com> <019201c85e0d$261957c0$0600a8c0@china.huawei.com> 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-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: jhutz@cmu.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --On Wednesday, January 23, 2008 05:13:14 PM -0500 David Harrington wrote: > The definition of SnmpAdminString (in RFC3411) refers to RFC2279. Ok, So we're concerned about the differences described in RFC3629 section 12. Many of those are not relevant or don't create incompatibilities; for example, the inclusion of ABNF describing valid UTF-8, expanded security consideratons, and registation of MIME charsets. There are some issues which are relevant: - Restricting the range of characters to U+0000-U+10FFFF, which is not a practical problem because no such characters exist. This appears to be an artifact of restating UTF-8 as an encoding of Unicode characters rather than of UCS4. - The requirement that invalid sequences (particularly, non-minimal encodings) be rejected. These sequences were never valid and will not be produced by a correct implementation of any version of UTF-8, but RFC2279 only RECOMMENDED that they be rejected, whereas RFC3629 REQUIRES doing so. Reading the SSHTM draft, I see the issue is over whether SSH usernames are compatible with SnmpAdminString, given that the former are defined in terms of RFC3629 while the latter uses RFC2979. My answer is that this should not be a problem; aside from the question of characters beyond U+10FFFF (of which there are none), any string valid for the one is valid for the other, and has the same meaning. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 17:50:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHoQ7-00077u-4N; Wed, 23 Jan 2008 17:50:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHoQ5-00073F-97 for isms@ietf.org; Wed, 23 Jan 2008 17:50:09 -0500 Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHoQ4-0005gd-SO for isms@ietf.org; Wed, 23 Jan 2008 17:50:09 -0500 Received: from atlantis.pc.cs.cmu.edu (ATLANTIS.PC.CS.CMU.EDU [128.2.216.110]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0NMo2mZ005075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2008 17:50:02 -0500 (EST) Date: Wed, 23 Jan 2008 17:50:02 -0500 From: Jeffrey Hutzelman To: David Harrington , isms@ietf.org Subject: RE: [Isms] ISMS #5: dual authentication issues Message-ID: In-Reply-To: <019301c85e0e$dc086570$0600a8c0@china.huawei.com> References: <20080123204757.GF13934@elstar.local> <018f01c85e08$a68a2600$0600a8c0@china.huawei.com> <019301c85e0e$dc086570$0600a8c0@china.huawei.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: jhutz@cmu.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --On Wednesday, January 23, 2008 05:25:29 PM -0500 David Harrington wrote: > So you favor adding text that says when using a secure transport > model, the security model field in the SNMPv3 message MUST be set to > TSM? > > or is it text that says if you are using a non-transport security > model, such as the community security model, then you MUST NOT (SHOULD > NOT) use a secure transport model? > > That would imply the (possibly already existing) module which > constructs the message must now know which transport model is being > used, and whether it is secure, and error out under some conditions. > Would that violate architectural modularity? That's a good question. Conceptually, I do not oppose a requirement that TSM and secure transport models be used together or not at all. From a practical standpoint, I don't think it's very difficult for operators to understand that, and I would actually expect the tools that configure such things to conflate the two, such that you are offered the choice of using USM or SSH (or possibly, USM/UDP, USM/TCP, or SSH). However, it likely would break modularity and be a significant burden for the application to verify that this rule is followed (the application can know what transport model is in use, because this is inherent in the transport mapping, yes?). One concern I do have is that when sending a message, we must not use TSM without a secure transport model, because that would result in sending an unproctected message, possibly when the application thinks it has asked for confidentiality. We should make sure this cannot happen. I think we've agreed that we want to be able to use a secure transport model with SNMPv1/SNMPv2c, and that doing so probably requires modifying the EoP such that when you use a secure transport, you magically get TSM instead of the community security model. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 17:55:12 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHoUy-0006eH-Qz; Wed, 23 Jan 2008 17:55:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHoUx-0006Zv-Uf for isms@ietf.org; Wed, 23 Jan 2008 17:55:11 -0500 Received: from qmta03.westchester.pa.mail.comcast.net ([76.96.62.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHoUx-0005nw-CT for isms@ietf.org; Wed, 23 Jan 2008 17:55:11 -0500 Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA03.westchester.pa.mail.comcast.net with comcast id gl8R1Y00H1HzFnQ050Bl00; Wed, 23 Jan 2008 22:55:10 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.westchester.pa.mail.comcast.net with comcast id gmv71Y0034HwxpC3a00000; Wed, 23 Jan 2008 22:55:10 +0000 X-Authority-Analysis: v=1.0 c=1 a=yzxyBjtJUVUA:10 a=lbDw0DS4zTfB9KZYthgA:9 a=_lQaDD6u0GZE1sNTfjqv2jJ8j4AA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=uWS-M9W3EfsA:10 From: "David Harrington" To: "'Jeffrey Hutzelman'" , , References: <20080123204851.GI13934@elstar.local> <019101c85e0c$51af2370$0600a8c0@china.huawei.com> <9AEF930B6C54D4349E40858E@atlantis.pc.cs.cmu.edu> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Wed, 23 Jan 2008 17:55:07 -0500 Message-ID: <019401c85e13$00162520$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: <9AEF930B6C54D4349E40858E@atlantis.pc.cs.cmu.edu> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcheDm61WavrDbR5RDKTXU62gzoduwAAKPbA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org inline > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Wednesday, January 23, 2008 5:22 PM > To: David Harrington; j.schoenwaelder@jacobs-university.de; > isms@ietf.org > Cc: jhutz@cmu.edu > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > --On Wednesday, January 23, 2008 05:07:17 PM -0500 David Harrington > wrote: > > > Hi, > > > > Bert Wijnen wrote: > > " Now I do see that in sect 2.3 you explain/state that the > Transport > > Security Model cannot be used with SNMPv1 and SNMPv2c. > > I wonder if this is what the operator/user community > > wants/accepts??" > > > > If we deliver something that does not meet what operators want, and > > they refuse to use our ISMS standard (as well as our USM standard), > > have we wasted another two and a half years? > > > > To standardize the use of SNMPv1/v2c over secure transports means we > > would need to modify some existing elements of procedure in RFC3584 > > and RFC3412 (I think those are the only two). The changes could be > > conditional changes based on the existence of, or contents of, > > tmStateReference so the elements of procedure would be backwards > > compatible with existing implementations. > > > > Basically, a secure transport model can specify which security model > > should be used to determine securityName, but in the absence of a > > secure transport model determination, the MPM decides which security > > model should be used. The work would need to specify something like > > "to support this functionality, the elements of procedure of RFC3412 > > are amended by the following change: ...." > > > > I think the result would be more in keeping with what > operators want. > > Hrm. Wouldn't this have the effect that if SNMPv3 is used > with USM over > SSH case, it is USM that gets ignored rather than SSH? I > don't think we > want that. > > OTOH, I'm inclined to agree that what you describe is likely > to result in > reasonable behavior for SNMPv1/v2c. > > I think to make this work, we need to distinguish between MPM's that > actually have the ability to negotiate a security model from > those that do > not. All MPMs determine which security model gets called, according to the architecture. How the determination is made is message-model specific. The three existing messaging models make the determination based on fields in the message header (i.e., the community field of v1/v2c, or the msgSecurityModel field in the SNMPv3 header). My suggestion is to **conditionally** modify the determination algorithm so that **if** a secure transport model is used, the secure transport model chooses (or requests) which security model the messaging model should call. If the transport model (such as the UDP transport "model") does not make such a determination, then the decision reverts to the existing MPM determination algorithm. > > Having just reread the charter, I'm unclear on whether this > is in scope. > The language "The new security model must not modify any > other aspects of > SNMPv3 protocol as defined in STD 62" seems intended to limit > what we can > do, but I'm not sure to what extent. I do agree that making > this work is > worthwhile, and probably requires changes to the EoP. I expect that the change required would be of the form: in RFC3412 section 7.2, insert step 3a) "If tmStateReference exists and specifies a security model in the tmSecurityModel field, then set msgSecurityModel to tmSecurityModel." I would have preferred to see existing text that said "set securityModel, to msgSecurityModel", and then to add a step that said "If If tmStateReference exists and specifies a security model in the tmSecurityModel field, then set securityModel to tmSecurityModel." But we never actually specific the assignment of the msgSecurityModel value to the securityModel parameter of processIncomingMessage(). dbh > > > -- Jeff > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 17:57:50 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHoXW-0000gE-Pt; Wed, 23 Jan 2008 17:57:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHoXU-0000aG-Th for isms@ietf.org; Wed, 23 Jan 2008 17:57:48 -0500 Received: from qmta04.westchester.pa.mail.comcast.net ([76.96.62.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHoXU-0005tC-H1 for isms@ietf.org; Wed, 23 Jan 2008 17:57:48 -0500 Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA04.westchester.pa.mail.comcast.net with comcast id gjSv1Y0091HzFnQ050N400; Wed, 23 Jan 2008 22:57:48 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.westchester.pa.mail.comcast.net with comcast id gmxk1Y0044HwxpC3a00000; Wed, 23 Jan 2008 22:57:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=rRm1hiugaW8A:10 a=evg3e-qFL2jQJqvtZuYA:9 a=TG7B3bbQRu4xdVSqr1gA:7 a=Tl20RWjk4vQZOegq_9OzijoJ2iMA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=XF7b4UCPwd8A:10 From: "David Harrington" To: "'Jeffrey Hutzelman'" , , References: <20080123204737.GE13934@elstar.local> <018e01c85e07$7531a930$0600a8c0@china.huawei.com> <019201c85e0d$261957c0$0600a8c0@china.huawei.com> <7FFE3AE221DC97079A342ED7@atlantis.pc.cs.cmu.edu> Subject: RE: [Isms] ISMS #4: UTF-8 and SnmpAdminString consistency Date: Wed, 23 Jan 2008 17:57:44 -0500 Message-ID: <019501c85e13$5da1e620$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: <7FFE3AE221DC97079A342ED7@atlantis.pc.cs.cmu.edu> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcheEJ+Wie1bk4CBTqCk+ObjXZUM5wAAo5kg X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Then I will assume there are no possible incompatibilities between SSH user_name and SnmpAdminStrings. Thank you. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Wednesday, January 23, 2008 5:38 PM > To: David Harrington; j.schoenwaelder@jacobs-university.de; > isms@ietf.org > Cc: jhutz@cmu.edu > Subject: RE: [Isms] ISMS #4: UTF-8 and SnmpAdminString consistency > > --On Wednesday, January 23, 2008 05:13:14 PM -0500 David Harrington > wrote: > > > The definition of SnmpAdminString (in RFC3411) refers to RFC2279. > > Ok, So we're concerned about the differences described in > RFC3629 section > 12. Many of those are not relevant or don't create > incompatibilities; for > example, the inclusion of ABNF describing valid UTF-8, > expanded security > consideratons, and registation of MIME charsets. > > There are some issues which are relevant: > > - Restricting the range of characters to U+0000-U+10FFFF, which is not > a practical problem because no such characters exist. This appears > to be an artifact of restating UTF-8 as an encoding of Unicode > characters rather than of UCS4. > > - The requirement that invalid sequences (particularly, non-minimal > encodings) be rejected. These sequences were never valid and will > not be produced by a correct implementation of any version of UTF-8, > but RFC2279 only RECOMMENDED that they be rejected, whereas RFC3629 > REQUIRES doing so. > > > Reading the SSHTM draft, I see the issue is over whether SSH > usernames are > compatible with SnmpAdminString, given that the former are > defined in terms > of RFC3629 while the latter uses RFC2979. My answer is that > this should > not be a problem; aside from the question of characters > beyond U+10FFFF (of > which there are none), any string valid for the one is valid > for the other, > and has the same meaning. > > -- Jeff > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 19:24:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHptk-00069E-W7; Wed, 23 Jan 2008 19:24:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHptk-000662-39 for isms@ietf.org; Wed, 23 Jan 2008 19:24:52 -0500 Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHptj-0004up-HX for isms@ietf.org; Wed, 23 Jan 2008 19:24:52 -0500 Received: from atlantis.pc.cs.cmu.edu (ATLANTIS.PC.CS.CMU.EDU [128.2.216.110]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0O0Oah9007389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2008 19:24:36 -0500 (EST) Date: Wed, 23 Jan 2008 19:24:36 -0500 From: Jeffrey Hutzelman To: David Harrington , j.schoenwaelder@jacobs-university.de, isms@ietf.org Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Message-ID: <5226CB98076DF837DB0267CF@atlantis.pc.cs.cmu.edu> In-Reply-To: <019401c85e13$00162520$0600a8c0@china.huawei.com> References: <20080123204851.GI13934@elstar.local> <019101c85e0c$51af2370$0600a8c0@china.huawei.com> <9AEF930B6C54D4349E40858E@atlantis.pc.cs.cmu.edu> <019401c85e13$00162520$0600a8c0@china.huawei.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: jhutz@cmu.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --On Wednesday, January 23, 2008 05:55:07 PM -0500 David Harrington wrote: > inline > >> -----Original Message----- >> From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] >> Sent: Wednesday, January 23, 2008 5:22 PM >> To: David Harrington; j.schoenwaelder@jacobs-university.de; >> isms@ietf.org >> Cc: jhutz@cmu.edu >> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for > ACM >> >> --On Wednesday, January 23, 2008 05:07:17 PM -0500 David Harrington >> wrote: >> >> > Hi, >> > >> > Bert Wijnen wrote: >> > " Now I do see that in sect 2.3 you explain/state that the >> Transport >> > Security Model cannot be used with SNMPv1 and SNMPv2c. >> > I wonder if this is what the operator/user community >> > wants/accepts??" >> > >> > If we deliver something that does not meet what operators want, > and >> > they refuse to use our ISMS standard (as well as our USM > standard), >> > have we wasted another two and a half years? >> > >> > To standardize the use of SNMPv1/v2c over secure transports means > we >> > would need to modify some existing elements of procedure in > RFC3584 >> > and RFC3412 (I think those are the only two). The changes could be >> > conditional changes based on the existence of, or contents of, >> > tmStateReference so the elements of procedure would be backwards >> > compatible with existing implementations. >> > >> > Basically, a secure transport model can specify which security > model >> > should be used to determine securityName, but in the absence of a >> > secure transport model determination, the MPM decides which > security >> > model should be used. The work would need to specify something > like >> > "to support this functionality, the elements of procedure of > RFC3412 >> > are amended by the following change: ...." >> > >> > I think the result would be more in keeping with what >> operators want. >> >> Hrm. Wouldn't this have the effect that if SNMPv3 is used >> with USM over >> SSH case, it is USM that gets ignored rather than SSH? I >> don't think we >> want that. >> >> OTOH, I'm inclined to agree that what you describe is likely >> to result in >> reasonable behavior for SNMPv1/v2c. >> >> I think to make this work, we need to distinguish between MPM's that > >> actually have the ability to negotiate a security model from >> those that do >> not. > > All MPMs determine which security model gets called, according to the > architecture. How the determination is made is message-model specific. > The three existing messaging models make the determination based on > fields in the message header (i.e., the community field of v1/v2c, or > the msgSecurityModel field in the SNMPv3 header). > > My suggestion is to **conditionally** modify the determination > algorithm so that **if** a secure transport model is used, the secure > transport model chooses (or requests) which security model the > messaging model should call. If the transport model (such as the UDP > transport "model") does not make such a determination, then the > decision reverts to the existing MPM determination algorithm. Right, I got that. But one effect of that is that if you use SSH, then SSH is always going to say "use TSM", and the msgSecurityModel field in the SNMPv3 header is going to be ignored (well, changed to TSM, but with the same effect). Which means you then can't actually do USM-over-SSH. I'd just as soon not have SNMPv3 be affected by whatever we decide to do to make v1/v2c work. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 20:10:47 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqcA-00015F-Ce; Wed, 23 Jan 2008 20:10:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqc8-0000lt-Jy for isms@ietf.org; Wed, 23 Jan 2008 20:10:44 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHqc7-0001aT-Vu for isms@ietf.org; Wed, 23 Jan 2008 20:10:44 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qY3mnkmOaplbcroWy3BUTU3BKDe/Q9ZLt1Xpwvw9NlQ5Uti99i+CoDR9uNCdd7G3; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.81.232] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JHqc1-0003Pt-QU for isms@ietf.org; Wed, 23 Jan 2008 20:10:38 -0500 Message-ID: <015e01c85e26$2f919f60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080123204814.GG13934@elstar.local> <019001c85e09$3be6d7c0$0600a8c0@china.huawei.com> Subject: Re: [Isms] ISMS #6: authentication of the notifications receiver Date: Wed, 23 Jan 2008 17:12:27 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911779aa569e18aa85acf8e8ab0cb4806233350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.81.232 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David Harrington" > To: > Sent: Wednesday, January 23, 2008 1:45 PM > Subject: RE: [Isms] ISMS #6: authentication of the notifications receiver ... > We have not resolved whether the principal associated with a > notification receiver must be a principal (aka user) or whether a > hostname is adequate. There are many aspects of this problem, and the > WG needs to discuss these and reach some consensus on how we want to > proceed. ... As far as the SNMP infrastructure is concerned, it *is* a principal. It's really agnostic about whether a principal happens to be a user or something else, even though we created a "user-based" security model. The real question here is the *operational* one. Here's a use case; you be the judge of whether it's realistic or not: There are two notification receiver applications on a host. One, running on behalf of security admin, gathers security alarms. The other, running on behalf of joe operator, gets everything else. Security admin and joe operator do not trust each other, and while willing to run on the same box, are not willing to run a shared application. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 20:19:24 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqkW-0006Z3-G8; Wed, 23 Jan 2008 20:19:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqkU-0006LY-SH for isms@ietf.org; Wed, 23 Jan 2008 20:19:22 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHqkT-00060T-FY for isms@ietf.org; Wed, 23 Jan 2008 20:19:22 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ddkfF5w6BpsPcC4EEf3L9oo13rYgmrzb5mz6gUTFIzTPnRbsRfjZmuWGgvFeM52Z; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.81.232] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JHqkS-0001Nf-EO for isms@ietf.org; Wed, 23 Jan 2008 20:19:21 -0500 Message-ID: <016d01c85e27$6754b800$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080123204851.GI13934@elstar.local> Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Wed, 23 Jan 2008 17:21:09 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117964301b3970f8bf725f6f9669abe2e6e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.81.232 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Wednesday, January 23, 2008 12:48 PM > Subject: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > ISMS #8: support of v1/v2c transport-authn for ACM > Status: open > > David Harrington wrote: > > whether to try to support v1/v2c transport-authn for ACM > > I believe this concerns the question whether this WG should consider > how SNMPv1/SNMPv2c, that is the community based security model, can > utilize a secure transport. > > Q8.1: Is this question in scope of the WG charter? I'd say no > Q8.2: If yes, what needs to be done to make this happen? Is there a > way to make existing code do something it was not expected to > do? Even if it could be in scope, I think we need a clear answer *why* one would want to do such a thing. What would be the point of building a SNMPv1 or SNMPv2c implementation over SSH? It still wouldn't support 64-bit counters, GetBulk, Informs, or extended error codes. Seems like it would be inviting folks to waste their time. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 23 20:22:27 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqnT-0001uc-HR; Wed, 23 Jan 2008 20:22:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHqnT-0001uX-07 for isms@ietf.org; Wed, 23 Jan 2008 20:22:27 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHqnS-00062k-Nv for isms@ietf.org; Wed, 23 Jan 2008 20:22:26 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=BZFMRojGq2weQq42lI4jEOs8NzdSkT31N39oeNKu8YK8n3yNfuTM6kIpH+OE203M; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.81.232] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JHqnS-0000ie-BY for isms@ietf.org; Wed, 23 Jan 2008 20:22:26 -0500 Message-ID: <000401c85e27$d7093720$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080123204851.GI13934@elstar.local> <016d01c85e27$6754b800$6801a8c0@oemcomputer> Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Wed, 23 Jan 2008 17:24:16 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc891172e19009e484c907fc03677a1b863fce7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.81.232 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Randy Presuhn" ... > Even if it could be in scope, I think we need a clear answer *why* > one would want to do such a thing. What would be the point of > building a SNMPv1 or SNMPv2c implementation over SSH? > It still wouldn't support 64-bit counters, GetBulk, Informs, or > extended error codes. Seems like it would be inviting folks > to waste their time. ... ("It" being SNMPv1.) Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jan 24 14:55:04 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8AC-0006Z9-9X; Thu, 24 Jan 2008 14:55:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8AB-0006Yz-BD for isms@ietf.org; Thu, 24 Jan 2008 14:55:03 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI8AA-0001Tu-Pm for isms@ietf.org; Thu, 24 Jan 2008 14:55:03 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 588C88A367; Thu, 24 Jan 2008 20:55:02 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 25025-07; Thu, 24 Jan 2008 20:54:57 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75D828A36A; Thu, 24 Jan 2008 20:54:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6BE7A48A16F; Thu, 24 Jan 2008 20:54:51 +0100 (CET) Date: Thu, 24 Jan 2008 20:54:51 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Message-ID: <20080124195451.GD16515@elstar.local> Mail-Followup-To: David Harrington , isms@ietf.org References: <20080123204851.GI13934@elstar.local> <019101c85e0c$51af2370$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019101c85e0c$51af2370$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org On Wed, Jan 23, 2008 at 05:07:17PM -0500, David Harrington wrote: > Hi, > > Bert Wijnen wrote: > " Now I do see that in sect 2.3 you explain/state that the Transport > Security Model cannot be used with SNMPv1 and SNMPv2c. > I wonder if this is what the operator/user community > wants/accepts??" > > If we deliver something that does not meet what operators want, and > they refuse to use our ISMS standard (as well as our USM standard), > have we wasted another two and a half years? > > To standardize the use of SNMPv1/v2c over secure transports means we > would need to modify some existing elements of procedure in RFC3584 > and RFC3412 (I think those are the only two). The changes could be > conditional changes based on the existence of, or contents of, > tmStateReference so the elements of procedure would be backwards > compatible with existing implementations. > > Basically, a secure transport model can specify which security model > should be used to determine securityName, but in the absence of a > secure transport model determination, the MPM decides which security > model should be used. The work would need to specify something like > "to support this functionality, the elements of procedure of RFC3412 > are amended by the following change: ...." > > I think the result would be more in keeping with what operators want. Speaking as technical contributor... Can you provide a reason why SNMPv2c'/SSH is operationally more desirable than SNMPv3/TSM/SSH? I fail to see the benefit because both SNMPv3/TSM/SSH and the new SNMPv2c'/SSH will essentially do the same, namely pull the securityName out of the SSH layer. /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jan 24 15:24:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8d8-0004zQ-Md; Thu, 24 Jan 2008 15:24:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI8d7-0004zL-CC for isms@ietf.org; Thu, 24 Jan 2008 15:24:57 -0500 Received: from mail.elbrysnetworks.com ([64.140.243.164] helo=gumby.elbrysnetworks.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JI8d7-0002P2-1F for isms@ietf.org; Thu, 24 Jan 2008 15:24:57 -0500 Received: (qmail 6750 invoked from network); 24 Jan 2008 15:24:56 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 24 Jan 2008 15:24:56 -0500 From: "David B. Nelson" To: References: <20080123204851.GI13934@elstar.local><019101c85e0c$51af2370$0600a8c0@china.huawei.com> <20080124195451.GD16515@elstar.local> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Thu, 24 Jan 2008 15:21:16 -0500 Organization: Elbrys Networks, Inc. Message-ID: <033d01c85ec6$abf75db0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080124195451.GD16515@elstar.local> Thread-Index: AchewwVDSbsm64OaR82KXgLmauGHqAAAqlQQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Juergen Schoenwaelder writes... > Can you provide a reason why SNMPv2c/SSH is operationally more > desirable than SNMPv3/TSM/SSH? > > I fail to see the benefit because both SNMPv3/TSM/SSH and the > new SNMPv2c/SSH will essentially do the same, namely pull the > securityName out of the SSH layer. I don't see the benefit either. The SNMP architecture is modular. AFAICT, SNMP implementations are generally not so modular. Assuming that a new software product release would be needed (no plug and play), why would the engineering/development/deployment effort to enhance SNMPv2c product be desirable, if the same effort applied to SNMPv3 product produced the same security benefits to the operator? It might be academically interesting to specify how to implement SNMPv2c/SSH, but why would someone choose it over SNMPv3/TSM/SSH? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 25 10:51:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQpc-00035y-UI; Fri, 25 Jan 2008 10:51:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQpc-00035r-7q for isms@ietf.org; Fri, 25 Jan 2008 10:51:04 -0500 Received: from mk-outboundfilter-2.mail.uk.tiscali.com ([212.74.114.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIQpa-0000zd-Mr for isms@ietf.org; Fri, 25 Jan 2008 10:51:04 -0500 X-Trace: 17782903/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.6 X-SBRS: None X-RemoteIP: 62.241.163.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALqTmUc+8aMG/2dsb2JhbACKTaQX X-IP-Direction: IN Received: from astro.systems.pipex.net ([62.241.163.6]) by smtp.pipex.tiscali.co.uk with ESMTP; 25 Jan 2008 15:51:00 +0000 Received: from pc6 (1Cust77.tnt13.lnd4.gbr.da.uu.net [62.188.142.77]) by astro.systems.pipex.net (Postfix) with SMTP id 83A25E00009F; Fri, 25 Jan 2008 15:50:58 +0000 (GMT) Message-ID: <04c301c85f61$73cde940$0601a8c0@pc6> From: "tom.petch" To: "David B. Nelson" , References: <20080123204851.GI13934@elstar.local><019101c85e0c$51af2370$0600a8c0@china.huawei.com><20080124195451.GD16515@elstar.local> <033d01c85ec6$abf75db0$5d1216ac@xpsuperdvd2> Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Fri, 25 Jan 2008 13:56:50 +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 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "David B. Nelson" To: Sent: Thursday, January 24, 2008 9:21 PM Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > Juergen Schoenwaelder writes... > > > Can you provide a reason why SNMPv2c/SSH is operationally more > > desirable than SNMPv3/TSM/SSH? > > > > I fail to see the benefit because both SNMPv3/TSM/SSH and the > > new SNMPv2c/SSH will essentially do the same, namely pull the > > securityName out of the SSH layer. > > I don't see the benefit either. The SNMP architecture is modular. AFAICT, > SNMP implementations are generally not so modular. Assuming that a new > software product release would be needed (no plug and play), why would the > engineering/development/deployment effort to enhance SNMPv2c product be > desirable, if the same effort applied to SNMPv3 product produced the same > security benefits to the operator? > > It might be academically interesting to specify how to implement > SNMPv2c/SSH, but why would someone choose it over SNMPv3/TSM/SSH? > SNMPv3 has a mandatory-to-implement USM, SNMPv2c does not; should save on the development effort. Tom Petch > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 25 10:51:07 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQpf-00039Y-25; Fri, 25 Jan 2008 10:51:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQpd-00036g-KU for isms@ietf.org; Fri, 25 Jan 2008 10:51:05 -0500 Received: from mk-outboundfilter-2.mail.uk.tiscali.com ([212.74.114.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIQpd-0001nn-43 for isms@ietf.org; Fri, 25 Jan 2008 10:51:05 -0500 X-Trace: 17782936/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.6 X-SBRS: None X-RemoteIP: 62.241.163.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALqTmUc+8aMG/2dsb2JhbACKTaQX X-IP-Direction: IN Received: from astro.systems.pipex.net ([62.241.163.6]) by smtp.pipex.tiscali.co.uk with ESMTP; 25 Jan 2008 15:51:03 +0000 Received: from pc6 (1Cust77.tnt13.lnd4.gbr.da.uu.net [62.188.142.77]) by astro.systems.pipex.net (Postfix) with SMTP id 09B4AE0000A4; Fri, 25 Jan 2008 15:51:01 +0000 (GMT) Message-ID: <04c401c85f61$750cd1e0$0601a8c0@pc6> From: "tom.petch" To: "Jeffrey Hutzelman" , "David Harrington" , References: <20080123204607.GB13934@elstar.local><017a01c85e02$391433f0$0600a8c0@china.huawei.com> <6B96CA4988BA3B036169B819@atlantis.pc.cs.cmu.edu> Subject: Re: [Isms] ISMS #1: tmStateReference Date: Fri, 25 Jan 2008 14:48:04 +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 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "Jeffrey Hutzelman" To: "David Harrington" ; Cc: Sent: Wednesday, January 23, 2008 10:35 PM Subject: RE: [Isms] ISMS #1: tmStateReference > --On Wednesday, January 23, 2008 03:55:01 PM -0500 David Harrington > wrote: > > > Hi, > > > > tmStateReference contains information that may be > > implementation-specific, and some of the information may need to be > > static to allow preconfiguration of state in the target-mib and > > associated tables. > > > > The text says it is the responsibility of the transport model to > > explicitly release the tmStateReference and associated information. > > Should this be implementation-dependent, and if so, are there any > > operational (e.g., notifications) or security issues with released or > > non-released transport/security state? > > It sounds like "explicitly release" in this case means things like freeing > the memory occupied by the tmStateReference or whatever it points to, or > returning an object or identifier to a free pool. Both the mechanism and > timing of this, as well as who is responsible for doing it, seem highly > implementation-dependent. I don't think this is a detail we need to > specify. > I think that that creates a security exposure. There is no pointer on an outgoing message for which session to use. The (rather loose) binding is based on a match in the cache for transportDomain/Address + securityName/Level/Model so if a session with instances of these objects is taken down and replaced by another with the same instances, and the cache is not cleared when the session is taken down, then the outgoing message could go over an inappropriate session. So I think yes, session failure MUST clear cache. Tom Petch > -- Jeff > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 25 10:51:10 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQph-0003AI-6M; Fri, 25 Jan 2008 10:51:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQpf-00039z-HG for isms@ietf.org; Fri, 25 Jan 2008 10:51:07 -0500 Received: from mk-outboundfilter-1.mail.uk.tiscali.com ([212.74.114.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIQpd-0000zk-RE for isms@ietf.org; Fri, 25 Jan 2008 10:51:07 -0500 X-Trace: 26747337/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$MX-ACCEPTED/pipex-infrastructure/62.241.163.6 X-SBRS: None X-RemoteIP: 62.241.163.6 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALqTmUc+8aMG/2dsb2JhbACKTaQX X-IP-Direction: IN Received: from astro.systems.pipex.net ([62.241.163.6]) by smtp.pipex.tiscali.co.uk with ESMTP; 25 Jan 2008 15:51:04 +0000 Received: from pc6 (1Cust77.tnt13.lnd4.gbr.da.uu.net [62.188.142.77]) by astro.systems.pipex.net (Postfix) with SMTP id 7A924E0000A5; Fri, 25 Jan 2008 15:51:03 +0000 (GMT) Message-ID: <04c501c85f61$75eea660$0601a8c0@pc6> From: "tom.petch" To: "Jeffrey Hutzelman" , "David Harrington" , References: <20080123204757.GF13934@elstar.local><018f01c85e08$a68a2600$0600a8c0@china.huawei.com><019301c85e0e$dc086570$0600a8c0@china.huawei.com> Subject: Re: [Isms] ISMS #5: dual authentication issues Date: Fri, 25 Jan 2008 15:47:42 +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 X-Spam-Score: -100.0 (---------------------------------------------------) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "Jeffrey Hutzelman" To: "David Harrington" ; Cc: Sent: Wednesday, January 23, 2008 11:50 PM Subject: RE: [Isms] ISMS #5: dual authentication issues > --On Wednesday, January 23, 2008 05:25:29 PM -0500 David Harrington > wrote: > > > So you favor adding text that says when using a secure transport > > model, the security model field in the SNMPv3 message MUST be set to > > TSM? > > > > or is it text that says if you are using a non-transport security > > model, such as the community security model, then you MUST NOT (SHOULD > > NOT) use a secure transport model? > > > > That would imply the (possibly already existing) module which > > constructs the message must now know which transport model is being > > used, and whether it is secure, and error out under some conditions. > > Would that violate architectural modularity? > > That's a good question. Conceptually, I do not oppose a requirement that > TSM and secure transport models be used together or not at all. From a > practical standpoint, I don't think it's very difficult for operators to > understand that, and I would actually expect the tools that configure such > things to conflate the two, such that you are offered the choice of using > USM or SSH (or possibly, USM/UDP, USM/TCP, or SSH). However, it likely > would break modularity and be a significant burden for the application to > verify that this rule is followed (the application can know what transport > model is in use, because this is inherent in the transport mapping, yes?). > > One concern I do have is that when sending a message, we must not use TSM > without a secure transport model, because that would result in sending an > unproctected message, possibly when the application thinks it has asked for > confidentiality. We should make sure this cannot happen. > > > I think we've agreed that we want to be able to use a secure transport > model with SNMPv1/SNMPv2c, and that doing so probably requires modifying > the EoP such that when you use a secure transport, you magically get TSM > instead of the community security model. > Going back to the original question, then dual authentication per se is a good thing and, in a wider context, is becoming a requirement for high security systems (eg high finance). What matters is that the credentials all authenticate one and the same identity (principal) for the message and as long as it is clear who/what that principal is (and other issues have raised concerns about that), then it should not matter how many times we authenticate. Tom Petch > -- Jeff > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 25 11:44:05 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIRes-0000q0-BV; Fri, 25 Jan 2008 11:44:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIRes-0000pu-1O for isms@ietf.org; Fri, 25 Jan 2008 11:44:02 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIReq-0002jC-3X for isms@ietf.org; Fri, 25 Jan 2008 11:44:02 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C75098A2B3; Fri, 25 Jan 2008 17:43:58 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 04262-10-4; Fri, 25 Jan 2008 17:43:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 204DD8A2D1; Fri, 25 Jan 2008 17:43:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F244648B707; Fri, 25 Jan 2008 17:43:40 +0100 (CET) Date: Fri, 25 Jan 2008 17:43:40 +0100 From: Juergen Schoenwaelder To: "tom.petch" Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Message-ID: <20080125164340.GA18150@elstar.local> Mail-Followup-To: "tom.petch" , "David B. Nelson" , isms@ietf.org References: <033d01c85ec6$abf75db0$5d1216ac@xpsuperdvd2> <04c301c85f61$73cde940$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04c301c85f61$73cde940$0601a8c0@pc6> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org On Fri, Jan 25, 2008 at 01:56:50PM +0100, tom.petch wrote: > ----- Original Message ----- > From: "David B. Nelson" > To: > Sent: Thursday, January 24, 2008 9:21 PM > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > > > Juergen Schoenwaelder writes... > > > > > Can you provide a reason why SNMPv2c/SSH is operationally more > > > desirable than SNMPv3/TSM/SSH? > > > > > > I fail to see the benefit because both SNMPv3/TSM/SSH and the > > > new SNMPv2c/SSH will essentially do the same, namely pull the > > > securityName out of the SSH layer. > > > > I don't see the benefit either. The SNMP architecture is modular. AFAICT, > > SNMP implementations are generally not so modular. Assuming that a new > > software product release would be needed (no plug and play), why would the > > engineering/development/deployment effort to enhance SNMPv2c product be > > desirable, if the same effort applied to SNMPv3 product produced the same > > security benefits to the operator? > > > > It might be academically interesting to specify how to implement > > SNMPv2c/SSH, but why would someone choose it over SNMPv3/TSM/SSH? > > > > SNMPv3 has a mandatory-to-implement USM, SNMPv2c does not; should save on the > development effort. SNMPv2c is experimental in the first place. Still it makes operators happy. So you can do SNMPv3/TSM/SSH and make operators happy without doing USM. You are not going to be SNMPv3 compliant - but does the operator care? Are we seriously considering to hack around in the otherwise religiously followed SNMP architecture just to get around the USM requirement for SNMPv3? /js (as technical contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 25 11:53:37 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIRo9-0004eI-J3; Fri, 25 Jan 2008 11:53:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIRo8-0004bb-72 for isms@ietf.org; Fri, 25 Jan 2008 11:53:36 -0500 Received: from qmta09.westchester.pa.mail.comcast.net ([76.96.62.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIRo6-0002uY-2Q for isms@ietf.org; Fri, 25 Jan 2008 11:53:36 -0500 Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA09.westchester.pa.mail.comcast.net with comcast id hNvi1Y0030vyq2s590Rt00; Fri, 25 Jan 2008 16:53:16 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id hUtU1Y0014HwxpC3R00000; Fri, 25 Jan 2008 16:53:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=yzxyBjtJUVUA:10 a=caCtcVXH2QF62Rlr_ScA:9 a=l3YAqTAmBEUWDGa7-G0A:7 a=aeZBd1mzF_LUoKZ8hf6xvGLqVoIA:4 a=-utQw5L2n1AA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'David B. Nelson'" , References: <20080123204851.GI13934@elstar.local><019101c85e0c$51af2370$0600a8c0@china.huawei.com><20080124195451.GD16515@elstar.local> <033d01c85ec6$abf75db0$5d1216ac@xpsuperdvd2> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Fri, 25 Jan 2008 11:53:27 -0500 Message-ID: <029b01c85f72$cf519580$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: <033d01c85ec6$abf75db0$5d1216ac@xpsuperdvd2> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AchewwVDSbsm64OaR82KXgLmauGHqAAAqlQQACoHykA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: David B. Nelson [mailto:dnelson@elbrysnetworks.com] > Sent: Thursday, January 24, 2008 3:21 PM > To: isms@ietf.org > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > Juergen Schoenwaelder writes... > > > Can you provide a reason why SNMPv2c/SSH is operationally more > > desirable than SNMPv3/TSM/SSH? > > > > I fail to see the benefit because both SNMPv3/TSM/SSH and the > > new SNMPv2c/SSH will essentially do the same, namely pull the > > securityName out of the SSH layer. > > I don't see the benefit either. The SNMP architecture is > modular. AFAICT, > SNMP implementations are generally not so modular. Assuming > that a new > software product release would be needed (no plug and play), > why would the > engineering/development/deployment effort to enhance SNMPv2c > product be > desirable, if the same effort applied to SNMPv3 product > produced the same > security benefits to the operator? Implmentation cost of developing what? adding SSH to the SNMPv3 engine of an agent vs the cost of adding SSH support to the SNMPv2c engine of an agent? Yes, the costs might be similar for that development effort. How about the costs of converting an SNMPv1/v2c NMS with full graphical interfaces to being an NMS with full graphical support for SNMPv3? Let's see what the costs of that development might be: 1) changing the database and GUIs to use contextEngineIDs rather than IP addresses to identify a node, 2) changing the database and GUIs that support entering a communityName to entering a securityEngineID plaus securityName, and then mapping those to the SSH equivalents, 3) changing any support for communities as "naming scope" that can encompass multiple devices to support contextNames that are local to a specific contextEngineID, etc. etc. etc. SNMPv3 adds a whole lot of changes in the conceptualization of the system beyond what SNMPv2c added versus SNMPv1. It would be comparatively MUCH simpler to add SSH support to an existing SNMPv1/v2c application than adding SSH PLUS SNMPv3 support to the same application. And of course, it would be much easier to train existing NOC personnel in how to use SSH added to already known SNMPv1/v2c applications, than to train them in all the concepts of SNMPv3 plus how to use SSH for securing the transport. There is a massive difference in costs between making NMS applications that already support SNMPv1/v2c capable of using SSH versus making it a requirement to upgrade to SNMPv3 to get SSH support. And many application vendors have already made it quite clear they are not convinced the demand is there for them to invest in such massive upgrades to their applications to support SNMPv3, and most operators have already made it clear they don't intend to demand this of application vendors. So where are the benefits? In the reduced costs of migrating a system, versus the cost of migrating an agent. Does this mean we should just toss SNMPv3 and the modular architecture? No, conceptually it means that vendors and operators can migrate portions of the (architectural) system as needed. They can still use SNMPv1 and SNMPv2c messags, but with an SSH/TCP transport and a TSM-like security model to supplement/replace the UDP transport model and the community-based security models. This gives them good authentication and encrypted messages based on existing security systems, which many operators and NMS vendors agree they want now. Since an SSH approach provides real authentication, compared to communties, they can utilize VACM (without having to support USM) when they decide that functionality is really needed. If they keep using SNMPv1/v2c messages, they can continue to use community as a "naming scope" while migrating away from community as an authenticator. When they want contextEngineID/contextEngineNmae naming scopes, they can migrate to SNMPv3 messages to get that. Forcing full SNMPv3 in order to get SSH secure transport makes it hard to convince people they should migrate their SNMP systems. David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 25 12:09:02 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIS34-0001pa-LU; Fri, 25 Jan 2008 12:09:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIS32-0001ow-Lb for isms@ietf.org; Fri, 25 Jan 2008 12:09:00 -0500 Received: from qmta09.westchester.pa.mail.comcast.net ([76.96.62.96]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIS32-0004m7-6u for isms@ietf.org; Fri, 25 Jan 2008 12:09:00 -0500 Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA09.westchester.pa.mail.comcast.net with comcast id hPUz1Y0071HzFnQ590Rm00; Fri, 25 Jan 2008 17:08:43 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.westchester.pa.mail.comcast.net with comcast id hV8v1Y00Y4HwxpC3a00000; Fri, 25 Jan 2008 17:08:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=yzxyBjtJUVUA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=6sBc7pWbQH8cOywzhsAA:9 a=WosyA6d0a5yxlQ4cFnkA:7 a=iOGQL9ofdvkG__SQdVTNUCVdhKgA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: , "'tom.petch'" References: <033d01c85ec6$abf75db0$5d1216ac@xpsuperdvd2><04c301c85f61$73cde940$0601a8c0@pc6> <20080125164340.GA18150@elstar.local> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Fri, 25 Jan 2008 12:08:55 -0500 Message-ID: <029c01c85f74$f841b540$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: <20080125164340.GA18150@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AchfcYbxOFRlyTEuTPCWz7BoqsPAmgAAXnLQ X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, January 25, 2008 11:44 AM > To: tom.petch > Cc: isms@ietf.org > Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > SNMPv2c is experimental in the first place. Still it makes operators > happy. So you can do SNMPv3/TSM/SSH and make operators happy without > doing USM. You are not going to be SNMPv3 compliant - but does the > operator care? No they don't. So we can publish something as a standard that we know nobody will actually implement because it makes no sense, but at least we can sleep soundly at night knowing the standard maintained the sacred modularity of RFC3411, and knowing that implementers are smart enough to find proprietary hacks to the standard to make it work the way operators want it to. Do we have our priorities in order here? > Are we seriously considering to hack around in the > otherwise religiously followed SNMP architecture just to get around > the USM requirement for SNMPv3? "religiously followed?" - we have redesigned the ASIs! We have added the equivalent of void pointers so we can pass model-dependent structures from one subsystem to other subsystems! In RFC3411/3412, the security model was not allowed to know anything about the transport, including which transport was being used! "religiously followed?" The fact that we have added tmStateReference to the ASIs is what makes it possible to support SNMPv1/v2c over SSH in a manner that is at as close to the original architectural modularity as the changes made for tmStateReference, and adding support for SNMPv1/v2c over SSH would make operators happy. dbh > > /js (as technical contributor) > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 25 12:39:39 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISWh-0008Ah-5M; Fri, 25 Jan 2008 12:39:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISWg-0008Ab-EK for isms@ietf.org; Fri, 25 Jan 2008 12:39:38 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JISWf-0006cD-RP for isms@ietf.org; Fri, 25 Jan 2008 12:39:38 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 692798A175; Fri, 25 Jan 2008 18:39:36 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09695-05; Fri, 25 Jan 2008 18:39:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 114788A30C; Fri, 25 Jan 2008 18:39:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 023C048B868; Fri, 25 Jan 2008 18:39:23 +0100 (CET) Date: Fri, 25 Jan 2008 18:39:23 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Message-ID: <20080125173923.GC18150@elstar.local> Mail-Followup-To: David Harrington , "'David B. Nelson'" , isms@ietf.org References: <033d01c85ec6$abf75db0$5d1216ac@xpsuperdvd2> <029b01c85f72$cf519580$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <029b01c85f72$cf519580$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org On Fri, Jan 25, 2008 at 11:53:27AM -0500, David Harrington wrote: > How about the costs of converting an SNMPv1/v2c NMS with full > graphical interfaces to being an NMS with full graphical support for > SNMPv3? Let's see what the costs of that development might be: > 1) changing the database and GUIs to use contextEngineIDs rather than > IP addresses to identify a node, Frankly, almost nobody does identify agents using contextEngineIDs as far as I can tell. So you don't have to do this change to move from SNMPv2c to SNMPv3. > 2) changing the database and GUIs that support entering a > communityName to entering a securityEngineID plaus securityName, and > then mapping those to the SSH equivalents, For our hacked NET-SNMP code, using SNMPv3/TSM/SSH is almost identical to using SNMPv2c as long as you use the default context. Instead of a community name and a transport address, you provide an SSH user name and a transport address. And even better, if you do not provide an SSH user name, we use the user's account name - so it is even a parameter less! > 3) changing any support for communities as "naming scope" that can > encompass multiple devices to support contextNames that are local to a > specific contextEngineID, Since there is no standard way to encode a context name in a community string, this is grey area on the management application side anyway. > etc. etc. etc. ??? > There is a massive difference in costs between making NMS > applications that already support SNMPv1/v2c capable of using SSH > versus making it a requirement to upgrade to SNMPv3 to get SSH > support. I don't really believe this. Perhaps my notion of massive is different from others. If the argument is that SNMPv3 is too complex to implement for management applications, then this discussion probably needs to be raised in some other forum of the IETF. /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 25 13:09:52 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISzv-0007X3-8u; Fri, 25 Jan 2008 13:09:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISzu-0007O4-5t for isms@ietf.org; Fri, 25 Jan 2008 13:09:50 -0500 Received: from mail.elbrysnetworks.com ([64.140.243.164] helo=gumby.elbrysnetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JISzt-00067e-SE for isms@ietf.org; Fri, 25 Jan 2008 13:09:50 -0500 Received: (qmail 469 invoked from network); 25 Jan 2008 13:09:49 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 25 Jan 2008 13:09:49 -0500 From: "David B. Nelson" To: References: <033d01c85ec6$abf75db0$5d1216ac@xpsuperdvd2> <029b01c85f72$cf519580$0600a8c0@china.huawei.com> <20080125173923.GC18150@elstar.local> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Fri, 25 Jan 2008 13:06:06 -0500 Organization: Elbrys Networks, Inc. Message-ID: <000301c85f7c$f4b69910$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20080125173923.GC18150@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AchfeUE5e5t+k9vHS36b6ZhD6Zu7BQAAsAsg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org I thought the charter of ISMS was to address a problem that could be characterized as: "SNMPv3 is not widely deployed because the lack of centralized authentication and key management is an impediment to ease of use." The solution was to add a new Security Model to SNMPv3, that leveraged existing authentication infrastructure. Now we are hearing that the solution ought to be to invent SNMPv2d? (Assuming that the "d" variant of SNMPv2 has not been previously defined.) How did we get to that point? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 25 15:39:43 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIVKx-0004gs-8L; Fri, 25 Jan 2008 15:39:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIVKv-0004fe-Cx for isms@ietf.org; Fri, 25 Jan 2008 15:39:41 -0500 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JIVKv-0004KI-4u for isms@ietf.org; Fri, 25 Jan 2008 15:39:41 -0500 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa08470; 25 Jan 2008 15:38 EST Date: Fri, 25 Jan 2008 15:38:45 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: "tom.petch" Subject: Re: [Isms] ISMS #1: tmStateReference In-Reply-To: <04c401c85f61$750cd1e0$0601a8c0@pc6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, 25 Jan 2008, tom.petch wrote: > There is no pointer on an outgoing message for which session to use. The > (rather loose) binding is based on a match in the cache for > transportDomain/Address + securityName/Level/Model You've said this before, but I can find no text which supports that assumption. As far as I know, we require that responses go out over the same session as the incoming message, but leave the exact details of how to handle that up to the implementation. Naturally, any implementation would have to take care to get the right session, regardless of what approach is used. That said, I can appreciate your point about not wanting to reuse a session that is no longer active. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 25 18:33:59 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIY3b-0006I8-0E; Fri, 25 Jan 2008 18:33:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIY3Z-0006I2-Ob for isms@ietf.org; Fri, 25 Jan 2008 18:33:57 -0500 Received: from relay.versatel.net ([62.250.3.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JIY3Z-0000CC-4e for isms@ietf.org; Fri, 25 Jan 2008 18:33:57 -0500 Received: (qmail 4866 invoked from network); 25 Jan 2008 23:33:56 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Jan 2008 23:33:56 -0000 From: "Bert Wijnen" To: , "David Harrington" Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Sat, 26 Jan 2008 00:33:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080125173923.GC18150@elstar.local> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org W.r.t. > > 3) changing any support for communities as "naming scope" that can > > encompass multiple devices to support contextNames that are local to a > > specific contextEngineID, > > Since there is no standard way to encode a context name in a community > string, this is grey area on the management application side anyway. > Mmm... does not the SNMP-COMMUNITY-MIB in RFC3584 cater for that? > > etc. etc. etc. > > ??? > > > There is a massive difference in costs between making NMS > > applications that already support SNMPv1/v2c capable of using SSH > > versus making it a requirement to upgrade to SNMPv3 to get SSH > > support. > > I don't really believe this. Perhaps my notion of massive is different > from others. > So why was it that HP did not support SNMPv3 in their NMS? I do not know if this is still the case or not. I do know that most agents were/are multi-lingual (SNMPv1,v2c,v3) but there are not that many NMSes that are SNMPv3 capable as far as I know. Now... I must admit that I have not kept track of that too closely in the last few years. > If the argument is that SNMPv3 is too complex to implement for > management applications, then this discussion probably needs to be > raised in some other forum of the IETF. > Too complex or not is not the major question. The major question is/are - does it actually get implemented? - does it get deployed? Bert > /js _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jan 25 19:54:44 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIZJj-0005LK-S2; Fri, 25 Jan 2008 19:54:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIZJi-0005Kw-7B for isms@ietf.org; Fri, 25 Jan 2008 19:54:42 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIZJh-0002Qv-Sv for isms@ietf.org; Fri, 25 Jan 2008 19:54:42 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=aGE6NvOwU6dpqeiPTXr12+pZXB0UTX1xoDQ9/hTv4GFbRAP4xTryIBURmpeJwEdo; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.189.212] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1JIZJg-0005ZE-Uz for isms@ietf.org; Fri, 25 Jan 2008 19:54:41 -0500 Message-ID: <003001c85fb6$03b5ecc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Fri, 25 Jan 2008 16:54:31 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc891178992cc407f65f54bb60b89dac4ebac68350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.189.212 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi - Just a procedural question - How would having a normative dependency on an experimental (SNMPvc) RFC affect this work process-wise? Or is the real sub-text of this discussion that SNMPv3 should be withdrawn from the standards track? Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jan 26 00:51:32 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIdwu-0000aL-5c; Sat, 26 Jan 2008 00:51:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIdws-0000Zz-9s for isms@ietf.org; Sat, 26 Jan 2008 00:51:26 -0500 Received: from qmta10.westchester.pa.mail.comcast.net ([76.96.62.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIdwr-0000EY-S6 for isms@ietf.org; Sat, 26 Jan 2008 00:51:26 -0500 Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA10.westchester.pa.mail.comcast.net with comcast id hc7P1Y00G0vyq2s5A0NW00; Sat, 26 Jan 2008 05:51:18 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id hhrN1Y0024HwxpC3R00000; Sat, 26 Jan 2008 05:51:25 +0000 X-Authority-Analysis: v=1.0 c=1 a=yzxyBjtJUVUA:10 a=48vgC7mUAAAA:8 a=BBgan1LGVAvRew2i2B4A:9 a=TzABUq2MkuXggvH0sj0A:7 a=Fq7une8lIiZVtAgpEy_mkvM6u20A:4 a=OS7PZEPQ3MUA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Randy Presuhn'" , References: <003001c85fb6$03b5ecc0$6801a8c0@oemcomputer> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Sat, 26 Jan 2008 00:51:22 -0500 Message-ID: <007901c85fdf$7ae4f470$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AchftgrNMJkgtVkiSDKb5atfu+KBKwAIW6Ow In-Reply-To: <003001c85fb6$03b5ecc0$6801a8c0@oemcomputer> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I don't see that there would be any dependency on SNMPv2c, or on SNMPv1, or on SNMPv3. The ISMS documents that describe passing the new tmStateReference parameter through the ASIs would discuss that when a tmStateReference is passed, a secure transport model uses tmStateReference to provide the equivalent of the msgSecurityParameters block for any version of SNMP message. We already have the transport model provide the securityName and securityLevel; we just don't provide the securityModel in tmStateReference. USM requires msgSecurityParameters to be passed in the SNMPv3 message header; TSM requires the same model-independent information be passed in tmStateReference instead. The change needed is to have the process for selecting the security model recognize the potential existence of the tmStateReference, and use its contents in the decision, just as the SNMPv3 MPM currently recognizes the msgSecurityParameters and uses that in its decision. There is no sub-text; a secure transport model and security model should be able to work with any version of SNMP message, if the appropriate parameters are provided. When a secure transport model is used, tmStateReference provides the msgSecurityParameters for SNMPv1, SNMPv2c, SNMPv3, and SNMPv99. If provided, the msgSecurityParameters block from the tmStateReference takes precedence over the parameters derived from an SNMP message header. And since we want RADIUS integration, and are providing that integration at the transport model, not the message version models, some of the msgSecurityParameters, e.g., the required securityModel, might be provided by RADIUS. If a tmStateReference does not exist or does not include the equivalent of msgSecurityParameters, e.g., when using the traditional UDP transport mapping, then the current processing rules apply to get the security parameters from the message header - msgSecurityModel/Name/Level from the SNMPv3 header or, for SNMPv1 or SNMPv2c messages, implicitly determine the securityModel from the message version, securityName from community, and implicitly specify that securityLevel is noAuthNoPriv. dbh > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Friday, January 25, 2008 7:55 PM > To: isms@ietf.org > Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > Hi - > > Just a procedural question - > > How would having a normative dependency on an > experimental (SNMPvc) RFC affect this work > process-wise? > > Or is the real sub-text of this discussion that SNMPv3 > should be withdrawn from the standards track? > > Randy > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jan 28 09:43:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJVCi-0005y4-J2; Mon, 28 Jan 2008 09:43:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJVCh-0005wI-Fs for isms@ietf.org; Mon, 28 Jan 2008 09:43:19 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJVCg-0005aV-R4 for isms@ietf.org; Mon, 28 Jan 2008 09:43:19 -0500 X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1201531387!5269304!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 11462 invoked from network); 28 Jan 2008 14:43:07 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-10.tower-153.messagelabs.com with SMTP; 28 Jan 2008 14:43:07 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id m0SEh6mq021175 for ; Mon, 28 Jan 2008 07:43:06 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m0SEh5nR029324 for ; Mon, 28 Jan 2008 08:43:05 -0600 (CST) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m0SEh4Ri029308 for ; Mon, 28 Jan 2008 08:43:04 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Mon, 28 Jan 2008 09:43:03 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Thread-Index: AchfqsxQrLGEKOyuRja3iPgXdhxrSQCD2p9Q References: <20080125173923.GC18150@elstar.local> From: "Donati Andrew-MGIA0477" To: "Bert Wijnen" , , "David Harrington" X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org =20 While there is nothing wrong with snmpv3 or the new SNMP management = framework,=20 there are at least several vendors I know of=A0who use snmpv2c on their = NMS systems and agents and do not yet have snmpv3 capability. This is not in = reference to legacy NMS systems and legacy internet equipment agents, but about new systems = that use XML and web based southbound interfaces for devices that support current = state of the art internet applications. In addition, it is worth to mention here = that there is a case where a large customer requested to use SNMPv1 traps for alarm = (conditions) and event messages. The reason being is not that the SNMPv2 and v3 = messages have a problem, but the SNMPv1 trap message structure with its numbering schema for = enterprise traps fits perfectly with the their alarm and event application environment. At this point, it may not be a bad idea to poll various vendors and end = users on what version of SNMP they use on their NMS systems and perhaps on some of their = agents. I have a suspicion that there may be more who are using only the community = based model than many of us expected. If the number is significant, it will be just = as important to implement SSH for SNMPv2c and v1 as it is for v3 since requirements = for SSH is very likely to be coming soon from end user customers who currently = use only SNMP v2c capable NMS systems.=20 Andy Donati Motorola -----Original Message----- From: Bert Wijnen [mailto:bertietf@bwijnen.net]=20 Sent: Friday, January 25, 2008 6:34 PM To: j.schoenwaelder@jacobs-university.de; David Harrington Cc: isms@ietf.org Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM W.r.t. > > 3) changing any support for communities as "naming scope" that can=20 > > encompass multiple devices to support contextNames that are local to = > > a specific contextEngineID, >=20 > Since there is no standard way to encode a context name in a community = > string, this is grey area on the management application side anyway. >=20 Mmm... does not the SNMP-COMMUNITY-MIB in RFC3584 cater for that? > > etc. etc. etc. >=20 > ??? >=20 > > There is a massive difference in costs between making NMS=20 > > applications that already support SNMPv1/v2c capable of using SSH=20 > > versus making it a requirement to upgrade to SNMPv3 to get SSH=20 > > support. >=20 > I don't really believe this. Perhaps my notion of massive is different = > from others. >=20 So why was it that HP did not support SNMPv3 in their NMS? I do not know if this is still the case or not. I do know that most agents were/are multi-lingual (SNMPv1,v2c,v3) but = there are not that many NMSes that are SNMPv3 capable as far as I know. = Now... I must admit that I have not kept track of that too closely in = the last few years. > If the argument is that SNMPv3 is too complex to implement for=20 > management applications, then this discussion probably needs to be=20 > raised in some other forum of the IETF. >=20 Too complex or not is not the major question. The major question is/are - does it actually get implemented? - does it get deployed? Bert > /js _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jan 28 13:56:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJZ9O-0003tl-Tn; Mon, 28 Jan 2008 13:56:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJZ9N-0003s0-Bm for isms@ietf.org; Mon, 28 Jan 2008 13:56:09 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJZ9N-000857-0t for isms@ietf.org; Mon, 28 Jan 2008 13:56:09 -0500 X-IronPort-AV: E=Sophos;i="4.25,261,1199682000"; d="scan'208";a="102017636" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 28 Jan 2008 13:56:08 -0500 X-IronPort-AV: E=Sophos;i="4.25,261,1199682000"; d="scan'208";a="147898354" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Jan 2008 13:56:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Mon, 28 Jan 2008 19:55:46 +0100 Message-ID: In-Reply-To: <003001c85fb6$03b5ecc0$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Thread-Index: Achftg0YB/pE3kRqQ0K6hXaIOC7zWQCIcPBg References: <003001c85fb6$03b5ecc0$6801a8c0@oemcomputer> From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org You cannot actually have such a downref.=20 Of course, this is not the only issue that I do not like in this proposal.=20 Dan =20 =20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 > Sent: Saturday, January 26, 2008 2:55 AM > To: isms@ietf.org > Subject: Re: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM >=20 > Hi - >=20 > Just a procedural question - >=20 > How would having a normative dependency on an experimental=20 > (SNMPvc) RFC affect this work process-wise? >=20 > Or is the real sub-text of this discussion that SNMPv3 should=20 > be withdrawn from the standards track? >=20 > Randy >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 > This email was protected during delivery to Avaya with TLS encryption >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jan 28 16:20:21 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbOv-000517-QE; Mon, 28 Jan 2008 16:20:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbOu-00050z-0V for isms@ietf.org; Mon, 28 Jan 2008 16:20:20 -0500 Received: from qmta05.westchester.pa.mail.comcast.net ([76.96.62.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJbOt-00043b-HN for isms@ietf.org; Mon, 28 Jan 2008 16:20:19 -0500 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA05.westchester.pa.mail.comcast.net with comcast id ijPw1Y00416LCl00504t00; Mon, 28 Jan 2008 21:20:19 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id ilLF1Y00b4HwxpC3S00000; Mon, 28 Jan 2008 21:20:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=yzxyBjtJUVUA:10 a=48vgC7mUAAAA:8 a=vKNGjuqHWbvKKpPAln0A:9 a=qa59VM_2lklmqyxd9dsA:7 a=X2iaIZ7cHFdPwcLzCbhoFAoetBQA:4 a=4dyfk4FV-b8A:10 a=lZB815dzVvQA:10 a=OS7PZEPQ3MUA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , References: <003001c85fb6$03b5ecc0$6801a8c0@oemcomputer> Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM Date: Mon, 28 Jan 2008 16:20:15 -0500 Message-ID: <025601c861f3$937a1d60$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Achftg0YB/pE3kRqQ0K6hXaIOC7zWQCIcPBgAAUffOA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi Dan, I am curious as to what other issues you do not like in this proposal. The SNMPv3 architecture was designed to permit various models to be used together in different combinations. I am trying to make it possible to use different security models with different message versions. I think that is very consistent with the SNMPv3 WG intentions of modularity. The one place where the SNMPv3 WG found a need to "bind" models was between the SNMPv3 message format and the named security models, because the security parameters that are needed by the different security models are passed in the SNMPv3 message header. Unfotunately, we also needed to bind SNMPv1 and the SNMPv1 security model directly, and the SNMPv2c message format to the SNMPv2 security model directly, because the security parameters are extracted from the fields of the message headers and we had no way to pass securityModel in the headers. With secure transports, the security parameters are actually provided by the transport layer protocol security - all except the securityModel parameter. The proposal is to make the transport model responsible for identifying the securityModel that will know how to properly process the securityparameters provided. This is equivalent to what the SNMPv3 message header provides now. And by doing this in the transport model, we can use RADIUS to provide during authentication some centralized control over the securityModel runtime decision that is so important to data access authorization. dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Monday, January 28, 2008 1:56 PM > To: Randy Presuhn; isms@ietf.org > Subject: RE: [Isms] ISMS #8: support of v1/v2c transport-authn for ACM > > You cannot actually have such a downref. > > Of course, this is not the only issue that I do not like in this > proposal. > > Dan > > > > > > > -----Original Message----- > > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > > Sent: Saturday, January 26, 2008 2:55 AM > > To: isms@ietf.org > > Subject: Re: [Isms] ISMS #8: support of v1/v2c > transport-authn for ACM > > > > Hi - > > > > Just a procedural question - > > > > How would having a normative dependency on an experimental > > (SNMPvc) RFC affect this work process-wise? > > > > Or is the real sub-text of this discussion that SNMPv3 should > > be withdrawn from the standards track? > > > > Randy > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > This email was protected during delivery to Avaya with TLS > encryption > > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jan 28 17:12:54 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJcDk-0007V8-VQ; Mon, 28 Jan 2008 17:12:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJcDk-0007V3-Aj for isms@ietf.org; Mon, 28 Jan 2008 17:12:52 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJcDi-0007E3-Gp for isms@ietf.org; Mon, 28 Jan 2008 17:12:52 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id B400D8A212; Mon, 28 Jan 2008 23:12:49 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30449-07-2; Mon, 28 Jan 2008 23:12:45 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6AB098A230; Mon, 28 Jan 2008 23:12:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BA2C1492245; Mon, 28 Jan 2008 23:12:41 +0100 (CET) Date: Mon, 28 Jan 2008 23:12:41 +0100 From: Juergen Schoenwaelder To: Jeffrey Hutzelman Subject: Re: [Isms] ISMS #7: properly closing an SSH session Message-ID: <20080128221241.GA4102@elstar.local> Mail-Followup-To: Jeffrey Hutzelman , isms@ietf.org References: <20080123204830.GH13934@elstar.local> <57D0B037A598025732816178@atlantis.pc.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57D0B037A598025732816178@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: isms-bounces@lists.ietf.org On Wed, Jan 23, 2008 at 05:06:52PM -0500, Jeffrey Hutzelman wrote: > --On Wednesday, January 23, 2008 09:48:30 PM +0100 Juergen Schoenwaelder > wrote: > >> Q7.1: Is there a need to document this in the SSHTM specification or >> is this implementation detail? What do other documents using SSH >> do? > > No. The mechanisms for closing SSH sessions are specified by SSH. It is > inappropriate for SSHTM to discuss connection setup at the layer of > specific SSH protocol messages, any more than a TCP transport model would > tell you when to send SYN, ACK, and RST messages to manage a TCP > connection. I am fine to leave the question how to properly close an SSH session to the SSH specifications. My problem while coding was simply that I did not find the answer in the SSH specifications - I found several options and it was not really clear to me which is the right one to use. But then this might be considered a shortcoming of the SSH specifications. So I suggest the answer for Q7.1 is: "It is not appropriate for the SSHTM document to detail how SSH sessions are closed." With that answer, Q7.2 becomes obsolete and issue ISMS #7 can be closed. If anyone on this list likes to object to this resolution of ISMS #7, please speak up now. /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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jan 29 17:02:11 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJyWw-0003AG-Q6; Tue, 29 Jan 2008 17:02:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJyWv-0003A9-7b for isms@ietf.org; Tue, 29 Jan 2008 17:02:09 -0500 Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJyWu-0006ae-LT for isms@ietf.org; Tue, 29 Jan 2008 17:02:09 -0500 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0TM1rtQ015309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2008 17:01:53 -0500 (EST) Date: Tue, 29 Jan 2008 17:01:53 -0500 From: Jeffrey Hutzelman To: "tom.petch" , David Harrington , isms@ietf.org Subject: Re: [Isms] ISMS #5: dual authentication issues Message-ID: <5DC08F7CF52DEDA29C0F1C7E@sirius.fac.cs.cmu.edu> In-Reply-To: <04c501c85f61$75eea660$0601a8c0@pc6> References: <20080123204757.GF13934@elstar.local> <018f01c85e08$a68a2600$0600a8c0@china.huawei.com> <019301c85e0e$dc086570$0600a8c0@china.huawei.com> <04c501c85f61$75eea660$0601a8c0@pc6> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: jhutz@cmu.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --On Friday, January 25, 2008 03:47:42 PM +0100 "tom.petch" wrote: > ----- Original Message ----- > From: "Jeffrey Hutzelman" > To: "David Harrington" ; > Cc: > Sent: Wednesday, January 23, 2008 11:50 PM > Subject: RE: [Isms] ISMS #5: dual authentication issues > > >> --On Wednesday, January 23, 2008 05:25:29 PM -0500 David Harrington >> wrote: >> >> > So you favor adding text that says when using a secure transport >> > model, the security model field in the SNMPv3 message MUST be set to >> > TSM? >> > >> > or is it text that says if you are using a non-transport security >> > model, such as the community security model, then you MUST NOT (SHOULD >> > NOT) use a secure transport model? >> > >> > That would imply the (possibly already existing) module which >> > constructs the message must now know which transport model is being >> > used, and whether it is secure, and error out under some conditions. >> > Would that violate architectural modularity? >> >> That's a good question. Conceptually, I do not oppose a requirement that >> TSM and secure transport models be used together or not at all. From a >> practical standpoint, I don't think it's very difficult for operators to >> understand that, and I would actually expect the tools that configure >> such things to conflate the two, such that you are offered the choice of >> using USM or SSH (or possibly, USM/UDP, USM/TCP, or SSH). However, it >> likely would break modularity and be a significant burden for the >> application to verify that this rule is followed (the application can >> know what transport model is in use, because this is inherent in the >> transport mapping, yes?). >> >> One concern I do have is that when sending a message, we must not use TSM >> without a secure transport model, because that would result in sending an >> unproctected message, possibly when the application thinks it has asked >> for confidentiality. We should make sure this cannot happen. >> >> >> I think we've agreed that we want to be able to use a secure transport >> model with SNMPv1/SNMPv2c, and that doing so probably requires modifying >> the EoP such that when you use a secure transport, you magically get TSM >> instead of the community security model. >> > > Going back to the original question, then dual authentication per se is a > good thing and, in a wider context, is becoming a requirement for high > security systems (eg high finance). No. What is becoming a requirement is two-factor authentication, wherein a user proves his identity to the system using two distinct "factors", such as a physical token plus a PIN or password. This is not the same as a client authenticating to a network service using multiple authentication protocols, which to date I have not heard of anyone requiring. Note that using TSM with SSHTM where initial authentication is to the SSH server, it is possible to obtain two-factor authentication by using SSH userauth methods such as keyboard-interactive, or by combining multiple methods, such as password along with publickey where the corresponding private key is known only to a smartcard. One can also use GSS-krb5 with tickets obtained through a two-factor process. The key property is not the use of multiple protocols, but the use of multiple factors (secrets or physical objects or attributes) by the human user to prove his identity. So no, there is no security reason to run USM-over-SSH or the like; the ability to do so is valuable primarily as an indication that we haven't broken an abstraction we shouldn't. We have discussed supporting SNMPv1/v2c over SSH; in those cases SSH would be the _only_ source of authentication, and TSM the only security model in use; the community security models normally used with these MPM's would be ignored. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jan 29 20:52:57 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK28E-0008UF-3U; Tue, 29 Jan 2008 20:52:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK28B-0008P8-Vt for isms@ietf.org; Tue, 29 Jan 2008 20:52:52 -0500 Received: from qmta07.westchester.pa.mail.comcast.net ([76.96.62.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JK28B-0004Cd-HV for isms@ietf.org; Tue, 29 Jan 2008 20:52:51 -0500 Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA07.westchester.pa.mail.comcast.net with comcast id j8G71Y0090xGWP8050gb00; Wed, 30 Jan 2008 01:52:51 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA12.westchester.pa.mail.comcast.net with comcast id jDsl1Y00T4HwxpC3Y00000; Wed, 30 Jan 2008 01:52:51 +0000 X-Authority-Analysis: v=1.0 c=1 a=w5AnnzxsK2wA:10 a=l7olt-X8lOEVT5DnQ3IA:9 a=vvLqCTaO4lJoXmfXyUwA:7 a=gO6WI3Mv9ox4Cjk8mxyxoKGYX1sA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'tom.petch'" , References: <20080123204757.GF13934@elstar.local> <018f01c85e08$a68a2600$0600a8c0@china.huawei.com> <019301c85e0e$dc086570$0600a8c0@china.huawei.com> <04c501c85f61$75eea660$0601a8c0@pc6> <5DC08F7CF52DEDA29C0F1C7E@sirius.fac.cs.cmu.edu> Subject: RE: [Isms] ISMS #5: dual authentication issues Date: Tue, 29 Jan 2008 20:52:45 -0500 Message-ID: <035f01c862e2$cf7f8170$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AchiwpYCUUg5KJ13QtaZpEmPqre04QAHiQgw In-Reply-To: <5DC08F7CF52DEDA29C0F1C7E@sirius.fac.cs.cmu.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Tuesday, January 29, 2008 5:02 PM > To: tom.petch; David Harrington; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] ISMS #5: dual authentication issues > [...] > > Going back to the original question, then dual > authentication per se is a > > good thing and, in a wider context, is becoming a > requirement for high > > security systems (eg high finance). > > No. What is becoming a requirement is two-factor > authentication, wherein a > user proves his identity to the system using two distinct > "factors", such > as a physical token plus a PIN or password. This is not the > same as a > client authenticating to a network service using multiple > authentication > protocols, which to date I have not heard of anyone requiring. > I knew there was another dual-XXXX name for what Tom was referring to, but couldn't place the dual-factor terminology. > Note that using TSM with SSHTM where initial authentication > is to the SSH > server, it is possible to obtain two-factor authentication by > using SSH > userauth methods such as keyboard-interactive, or by > combining multiple > methods, such as password along with publickey where the > corresponding > private key is known only to a smartcard. One can also use > GSS-krb5 with > tickets obtained through a two-factor process. The key > property is not the > use of multiple protocols, but the use of multiple factors > (secrets or > physical objects or attributes) by the human user to prove > his identity. > > > So no, there is no security reason to run USM-over-SSH or the > like; the > ability to do so is valuable primarily as an indication that > we haven't > broken an abstraction we shouldn't. > We have discussed supporting > SNMPv1/v2c over SSH; in those cases SSH would be the _only_ source of > authentication, and TSM the only security model in use; the community > security models normally used with these MPM's would be ignored. > > -- Jeff > Currently, the SNMPv1/v2c community would be the only source of authentication recognized when doing access control for requests carried by v1/v2c messages, because the Informational RFC3584 hardcodes CSM as the security model for v1/v2c messages. The WG has not reached consensus to support SNMPv1/v2c/v3/v99 over SSH, by allowing selection of TSM rather than CSM as the security model when there is a secure transport. (I am in favor of such a change). dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jan 29 21:02:58 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK2Hx-00044L-Va; Tue, 29 Jan 2008 21:02:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK2Hw-000431-DZ for isms@ietf.org; Tue, 29 Jan 2008 21:02:56 -0500 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JK2Hw-0004Ne-2X for isms@ietf.org; Tue, 29 Jan 2008 21:02:56 -0500 Received: from atlantis.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0U22mgk014370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2008 21:02:49 -0500 (EST) Date: Tue, 29 Jan 2008 21:02:48 -0500 From: Jeffrey Hutzelman To: David Harrington , "'tom.petch'" , isms@ietf.org Subject: RE: [Isms] ISMS #5: dual authentication issues Message-ID: In-Reply-To: <035f01c862e2$cf7f8170$6502a8c0@china.huawei.com> References: <20080123204757.GF13934@elstar.local> <018f01c85e08$a68a2600$0600a8c0@china.huawei.com> <019301c85e0e$dc086570$0600a8c0@china.huawei.com> <04c501c85f61$75eea660$0601a8c0@pc6> <5DC08F7CF52DEDA29C0F1C7E@sirius.fac.cs.cmu.edu> <035f01c862e2$cf7f8170$6502a8c0@china.huawei.com> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: jhutz@cmu.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --On Tuesday, January 29, 2008 08:52:45 PM -0500 David Harrington wrote: > Currently, the SNMPv1/v2c community would be the only source of > authentication recognized when doing access control for requests > carried by v1/v2c messages, because the Informational RFC3584 > hardcodes CSM as the security model for v1/v2c messages. > > The WG has not reached consensus to support SNMPv1/v2c/v3/v99 over > SSH, by allowing selection of TSM rather than CSM as the security > model when there is a secure transport. Right; what I described is what would happen if this approach were adopted. Of course, if we choose not to support v1/v2c over SSH, then the point is moot. We could also choose to permit the use of the SSH transport model with these versions, but _without_ changing the way the security model is selected. The result is that the secure transport would be present, but would not have any effect on security parameters. This is similar to what I would expect with SNMPv3+SSHTM+USM; since TSM is not used the secure transport has no effect on security parameters or access control. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jan 30 05:09:36 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK9st-0007gp-RZ; Wed, 30 Jan 2008 05:09:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK9ss-0007Sc-Bj for isms@ietf.org; Wed, 30 Jan 2008 05:09:34 -0500 Received: from relay.versatel.net ([62.250.3.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JK9sq-0004UM-Ob for isms@ietf.org; Wed, 30 Jan 2008 05:09:34 -0500 Received: (qmail 51707 invoked from network); 30 Jan 2008 10:09:30 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 30 Jan 2008 10:09:30 -0000 From: "Bert Wijnen" To: "David Harrington" , "'Jeffrey Hutzelman'" , "'tom.petch'" , Subject: RE: [Isms] ISMS #5: dual authentication issues Date: Wed, 30 Jan 2008 11:09:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <035f01c862e2$cf7f8170$6502a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org W.r.t. > Currently, the SNMPv1/v2c community would be the only source of > authentication recognized when doing access control for requests > carried by v1/v2c messages, because the Informational RFC3584 > hardcodes CSM as the security model for v1/v2c messages. > > The WG has not reached consensus to support SNMPv1/v2c/v3/v99 over > SSH, by allowing selection of TSM rather than CSM as the security > model when there is a secure transport. > > (I am in favor of such a change). > > dbh > The fact that SNMPv1/v2c use CSM is (I believe) completely described in RFC3584, which is a BCP (dated Aug 2003). Of course, at that time, given the state of SNMP in general, that was more or less the only BCP we could think of. I can imagine, that as soon as we have SNMP (any version) over SSH, that we could update the BCP to indicate that a better parctice (in 2008) would be to use SSH and TSM and fit SNMPv1/v2c into the current SNMP secure environment. So it could be done by opening up RFC3584. Is that so problematic? Anyway, I am also in favor of such a change. Bert _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jan 31 10:25:25 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbI5-00028Z-Ls; Thu, 31 Jan 2008 10:25:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbI3-00028R-OP for isms@ietf.org; Thu, 31 Jan 2008 10:25:24 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKbI3-0006Xt-8c for isms@ietf.org; Thu, 31 Jan 2008 10:25:23 -0500 X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1201793113!9249040!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30365 invoked from network); 31 Jan 2008 15:25:13 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-153.messagelabs.com with SMTP; 31 Jan 2008 15:25:13 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m0VFPCHb007161 for ; Thu, 31 Jan 2008 08:25:12 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m0VFPCKI022121 for ; Thu, 31 Jan 2008 09:25:12 -0600 (CST) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m0VFPBhc022115 for ; Thu, 31 Jan 2008 09:25:11 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] ISMS #5: dual authentication issues Date: Thu, 31 Jan 2008 10:25:10 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] ISMS #5: dual authentication issues Thread-Index: AchjKEBQEivgNcHgRWyCbJRxeFyaoAA89GzQ References: <035f01c862e2$cf7f8170$6502a8c0@china.huawei.com> From: "Donati Andrew-MGIA0477" To: "Bert Wijnen" , "David Harrington" , "Jeffrey Hutzelman" , "tom.petch" , X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org >-----Original Message----- >From: Bert Wijnen [mailto:bertietf@bwijnen.net]=20 >Sent: Wednesday, January 30, 2008 5:10 AM >To: David Harrington; 'Jeffrey Hutzelman'; 'tom.petch'; isms@ietf.org >Subject: RE: [Isms] ISMS #5: dual authentication issues >W.r.t. >> Currently, the SNMPv1/v2c community would be the only source of=20 >> authentication recognized when doing access control for requests=20 >> carried by v1/v2c messages, because the Informational RFC3584=20 >> hardcodes CSM as the security model for v1/v2c messages. >>=20 >> The WG has not reached consensus to support SNMPv1/v2c/v3/v99 over=20 >> SSH, by allowing selection of TSM rather than CSM as the security=20 >> model when there is a secure transport. >>=20 >> (I am in favor of such a change). >>=20 >> dbh >>=20 >The fact that SNMPv1/v2c use CSM is (I believe) completely described in RFC3584, which is a BCP (dated Aug 2003). >Of course, at that time, given the state of SNMP in general, that was more or less the only BCP we could think of. >I can imagine, that as soon as we have SNMP (any version) over SSH, that we could update the BCP to indicate that a >better parctice (in 2008) would be to use SSH and TSM and fit SNMPv1/v2c into the current SNMP secure environment. > >So it could be done by opening up RFC3584.=20 >Is that so problematic? > >Anyway, I am also in favor of such a change. > >Bert I am also in favor of such a change and am in favor of updating the latest version of=20 "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", currently RFC3584. Andy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms