From isms-bounces@lists.ietf.org Wed Aug 01 15:29:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJsW-0003R0-Pu; Wed, 01 Aug 2007 15:29:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJsU-0003Qs-Em for isms@ietf.org; Wed, 01 Aug 2007 15:29:02 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGJsT-00089G-0B for isms@ietf.org; Wed, 01 Aug 2007 15:29:02 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32D7386581 for ; Wed, 1 Aug 2007 21:29:00 +0200 (CEST) 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 30290-10; Wed, 1 Aug 2007 21:28:55 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7A018657F; Wed, 1 Aug 2007 21:28:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 288922F618E; Wed, 1 Aug 2007 21:28:56 +0200 (CEST) Date: Wed, 1 Aug 2007 21:28:56 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070801192855.GA16359@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.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Isms] radius isms document 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 Hi, at the last IETF meeting in Chicago, there was support to accept draft-narayan-isms-sshsm-radius-02.txt as the basis of an ISMS WG document. If someone on this list disagrees, please post a note with an explanation by August 10. Please be also reminded that the WG last call on the core documents is running until August 10th as well; it would be nice if you can reserve some time on your agenda to help reviewing the documents. Thanks, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 02 12:28:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdX0-0003hQ-A1; Thu, 02 Aug 2007 12:28:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdWy-0003br-PX for isms@ietf.org; Thu, 02 Aug 2007 12:28:08 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGdWx-0004TB-9z for isms@ietf.org; Thu, 02 Aug 2007 12:28:08 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F8798655A for ; Thu, 2 Aug 2007 18:28:06 +0200 (CEST) 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 08518-07; Thu, 2 Aug 2007 18:28:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1994E8654C; Thu, 2 Aug 2007 18:28:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6AB862F6AC3; Thu, 2 Aug 2007 18:27:02 +0200 (CEST) Date: Thu, 2 Aug 2007 18:27:02 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070802162702.GA17680@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.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Isms] [bernard_aboba@hotmail.com: Review of draft-nelson-radius-management-authorization-05.txt] 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 Hi, this was just posted to the RADIUS Extension WG and it would be nice if some of you support the adoption of this document as a RADEXT Extension WG work item. /js ----- Forwarded message from Bernard Aboba ----- From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Review of draft-nelson-radius-management-authorization-05.txt Date: Thu, 02 Aug 2007 09:19:39 -0700 The ISMS WG has requested that RADEXT WG take on "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management" as a WG work item. In response to this request, we are requesting reviews of the document, which is found here: http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-05.txt The request for review will last until August 16, 2007. Please indicate whether you would like this document to be taken on as a WG work item. Please respond even if you have no issues with the document; if you have comments, please send the issues to the RADEXT WG mailing list in the format provided on here: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: ----- End forwarded message ----- _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 08 05:48:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIi8B-0000oI-G1; Wed, 08 Aug 2007 05:47:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIi89-0000oC-U8 for isms@ietf.org; Wed, 08 Aug 2007 05:47:05 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIi89-0002D0-ET for isms@ietf.org; Wed, 08 Aug 2007 05:47:05 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l789kl1d019964; Wed, 8 Aug 2007 04:47:00 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 04:46:53 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 11:46:50 +0200 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 Date: Wed, 8 Aug 2007 11:46:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sendMessage and receiveMessage ASIs in draft-ietf-isms-tmsm-09.txt Thread-Index: AcfZoPanR+hlpol8Q46rkEP1yhkvUw== From: "Wijnen, Bert \(Bert\)" To: , X-OriginalArrivalTime: 08 Aug 2007 09:46:50.0414 (UTC) FILETIME=[0B320CE0:01C7D9A1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org Subject: [Isms] sendMessage and receiveMessage ASIs in draft-ietf-isms-tmsm-09.txt 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 For my own understanding, can you confirm that=20 the sendMessage ASI and the receiveMessage ASI would fit in RFC3411 scenario Diagrams (sect 4.6.1 and 4.6.2) and would take the place of the=20 "Send SNMP (Request) Message to Network" "Receive SNMP (Response) Message from Network" respectively? If so, I wonder if it would be good to say so, or to add such a scenario diagram to the I-D. Bert Wijnen=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 08 06:19:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIicF-0007rw-Fb; Wed, 08 Aug 2007 06:18:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIicC-0007rj-E6 for isms@ietf.org; Wed, 08 Aug 2007 06:18:08 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIicB-0004ED-PN for isms@ietf.org; Wed, 08 Aug 2007 06:18:08 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l78AI31B002948; Wed, 8 Aug 2007 05:18:03 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 05:18:03 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 12:18:01 +0200 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 Date: Wed, 8 Aug 2007 12:17:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tmStateReference in draft-ietf-isms-tmsm-09.txt Thread-Index: AcfZoPanR+hlpol8Q46rkEP1yhkvUwAAy9fw From: "Wijnen, Bert \(Bert\)" To: , "David Harrington" X-OriginalArrivalTime: 08 Aug 2007 10:18:01.0039 (UTC) FILETIME=[662CC5F0:01C7D9A5] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: isms@ietf.org Subject: [Isms] tmStateReference in draft-ietf-isms-tmsm-09.txt 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 I am confused by the last 2 paragraphs in sect 6.2 The prepareOutgoingMessage ASI passes tmStateReference from the Message Processing Subsystem to the dispatcher. How or if the Message Processing Subsystem modifies or utilizes the contents of the cache is message-processing-model-specific. This may sound underspecified, but keep in mind that a message processing model might have access to all the information from the cache and from the message, and have no need to call a Security Model to do any processing; an application might choose a Security Model such as USM to authenticate and secure the SNMP message, but also utilize a secure transport such as that provided by the SSH Transport Model to send the message to its destination. specifically the wording "an application...". Applications in our RFC3411 context are CG or CR or NO or NR or such. I am sure that is not intended here. But then, what is an "application" in this sentence above? I am also not sure we should speak about the MPM to "not call a security model". From our architectural point of view, the MPM will ALWAYS call a security model. If an implementation does a shortcut, that is up to them... but should we discuss that here? I am similarly confused by the "an application..." in section 6.4 last paragraph. Bert Wijnen=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 08 10:59:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IImzG-0002sA-ES; Wed, 08 Aug 2007 10:58:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IImzE-0002rk-OE for isms@ietf.org; Wed, 08 Aug 2007 10:58:12 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IImzC-0002VD-Fz for isms@ietf.org; Wed, 08 Aug 2007 10:58:12 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l78EvxMi021709; Wed, 8 Aug 2007 09:58:06 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 09:58:03 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 16:57:58 +0200 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 Date: Wed, 8 Aug 2007 16:57:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: my review of: Thread-Index: AcfZxxChWxAgUTrqQ6Wl8MN1s1N2DA== From: "Wijnen, Bert \(Bert\)" To: "David Harrington" X-OriginalArrivalTime: 08 Aug 2007 14:57:58.0338 (UTC) FILETIME=[82253220:01C7D9CC] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: isms@ietf.org Subject: [Isms] my review of: 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 Just nits I think. - Sect 2.4, 5th line to the appropriate Transport Model through a series of APIs, as s/API/ASI/ !!?? also one but last line in sect 2.4 a series of APIs, as described in "Transport Subsystem for the Simple s/API/ASI/ !!?? - section 6: 6. Overview Maybe change that section title to MIB Module Overview? - ::=3D { snmpModules xxxx } Is there a good reason to put this underneath that snmpModules branch? I do understand we have the snmpUsmMIB (so to be consistent this one should be named snmpTsmMIB) and related MIB modules under snmpModules. So from that point it makes sense. But we have stated (in RFC4181) that an OID is just an OID and MIB modules should go under mib-2.=20 And we have no-where specified IANA guidelines as to how/when to assign new values under snmpModules. I know that some other WG wants to put their MIB modules under a=20 common branch of their own as well... and they are (as we speak) getting push-back from our AD. - tsmInvalidCache OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages dropped because the tmStateReference referred to an invalid cache. This value is not persistent across reboots. " ::=3D { tsmStats 1 } tsmInadequateSecurity OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming messages dropped because the actual securityLevel provided was less than the requested securityLevel. This value is not persistent across reboots. " ::=3D { tsmStats 2 } =20 According to our CLRs, the names/descriptors should express plurality. Not that I cannot live with them being named as is? Just that we as MIB doctors should probably follow our own CLRs. I do not understand why we need to say something about "persistency"? We May want to state that discontinuties only can occur at a reboot or restart of the agent? - I also see: tsmGroups OBJECT IDENTIFIER ::=3D { tsmConformance 1 } tsmCompliances OBJECT IDENTIFIER ::=3D { tsmConformance 2 } While RFC4181 suggests: xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) So first compliances, then groups. - I get somehwat worried when following (In IANA Considerations section): 2. a value, preferably 4, to identify the Transport Security Model, in the Security Models registry at http://www.iana.org/assignments/snmp-number-spaces. This should Because if you go to http://www.iana.org/assignments/smi-numbers and search for "SNMP Management Architecture:" you will find that the number space is listed there as well. So for now I guess IANA should update both locations. But probably it is best if theu only maintain it in one place. The http://www.iana.org/assignments/snmp-number-spaces uses current RFCs as references. The http://www.iana.org/assignments/smi-numbers uses old RFC226x as references. I will report this "duplicate registry" issue to IANA seperately. Bert Wijnen=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 08 11:31:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IInTJ-000205-TH; Wed, 08 Aug 2007 11:29:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IInTH-0001yh-0L for isms@ietf.org; Wed, 08 Aug 2007 11:29:16 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IInTF-00038d-FL for isms@ietf.org; Wed, 08 Aug 2007 11:29:14 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l78FT52v008103 for ; Wed, 8 Aug 2007 10:29:12 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 10:29:05 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 17:29:02 +0200 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 Date: Wed, 8 Aug 2007 17:28:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: my review of: draft-ietf-isms-transport-security-model-05.txt Thread-Index: AcfZxxChWxAgUTrqQ6Wl8MN1s1N2DAACbZow From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 08 Aug 2007 15:29:02.0625 (UTC) FILETIME=[D958D110:01C7D9D0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Subject: [Isms] my review of: draft-ietf-isms-transport-security-model-05.txt 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 Now with proper subject line.=20 Bert Wijnen=20 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com]=20 Sent: Wednesday, August 08, 2007 4:58 PM To: David Harrington Cc: isms@ietf.org Subject: [Isms] my review of: Just nits I think. - Sect 2.4, 5th line to the appropriate Transport Model through a series of APIs, as s/API/ASI/ !!?? also one but last line in sect 2.4 a series of APIs, as described in "Transport Subsystem for the Simple s/API/ASI/ !!?? - section 6: 6. Overview Maybe change that section title to MIB Module Overview? - ::=3D { snmpModules xxxx } Is there a good reason to put this underneath that snmpModules branch? I do understand we have the snmpUsmMIB (so to be consistent this one should be named snmpTsmMIB) and related MIB modules under snmpModules. So from that point it makes sense. But we have stated (in RFC4181) that an OID is just an OID and MIB modules should go under mib-2.=20 And we have no-where specified IANA guidelines as to how/when to assign new values under snmpModules. I know that some other WG wants to put their MIB modules under a common branch of their own as well... and they are (as we speak) getting push-back from our AD. - tsmInvalidCache OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of messages dropped because the tmStateReference referred to an invalid cache. This value is not persistent across reboots. " ::=3D { tsmStats 1 } tsmInadequateSecurity OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming messages dropped because the actual securityLevel provided was less than the requested securityLevel. This value is not persistent across reboots. " ::=3D { tsmStats 2 } =20 According to our CLRs, the names/descriptors should express plurality. Not that I cannot live with them being named as is? Just that we as MIB doctors should probably follow our own CLRs. I do not understand why we need to say something about "persistency"? We May want to state that discontinuties only can occur at a reboot or restart of the agent? - I also see: tsmGroups OBJECT IDENTIFIER ::=3D { tsmConformance 1 } tsmCompliances OBJECT IDENTIFIER ::=3D { tsmConformance 2 } While RFC4181 suggests: xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) So first compliances, then groups. - I get somehwat worried when following (In IANA Considerations section): 2. a value, preferably 4, to identify the Transport Security Model, in the Security Models registry at http://www.iana.org/assignments/snmp-number-spaces. This should Because if you go to http://www.iana.org/assignments/smi-numbers and search for "SNMP Management Architecture:" you will find that the number space is listed there as well. So for now I guess IANA should update both locations. But probably it is best if theu only maintain it in one place. The http://www.iana.org/assignments/snmp-number-spaces uses current RFCs as references. The http://www.iana.org/assignments/smi-numbers uses old RFC226x as references. I will report this "duplicate registry" issue to IANA seperately. Bert Wijnen=20 _______________________________________________ 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 Thu Aug 09 06:19:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ55B-0006P8-BF; Thu, 09 Aug 2007 06:17:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ559-0006P1-8Z for isms@ietf.org; Thu, 09 Aug 2007 06:17:31 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ558-0007iI-IK for isms@ietf.org; Thu, 09 Aug 2007 06:17:30 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l79AHSMf000340; Thu, 9 Aug 2007 05:17:28 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 05:17:28 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 12:17:21 +0200 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 Date: Thu, 9 Aug 2007 12:17:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: my review of: draft-ietf-isms-secshell-08.txt Thread-Index: AcfabnRxPg9G64XgSUeMWJVP7VST/w== From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , X-OriginalArrivalTime: 09 Aug 2007 10:17:21.0839 (UTC) FILETIME=[793913F0:01C7DA6E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: isms@ietf.org Subject: [Isms] my review of: draft-ietf-isms-secshell-08.txt 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 Some of these are NITs, I know that. - I think the abstract should also mention that there is a MIB module defined in this document. - I think the last para of sect 1.2 can/should be removed, or at least the RFC-Editor should be instructed to do so. - Sect 1.4 The work will address ... The work will include ... Maybe better: This document addresses ... This document includes/defines ... - sect 5.1 and 5.1 I assume that SSH_MSG_USERAUTH_REQUEST and SSH_MSG_CHANNEL_DATA are specified somewhere in the SSH RFC(s)? Maybe a citation to such RFC(s) is useful at these points. - top of page 15: 45 Extract any implementation-specific parameters from the LCD 6) Pass the wholeMessage to SSH for encapsulation in an SSH_MSG_CHANNEL_DATA message. what is "45"? Should that be "5)" But the whole first sentence seems to not belong here? - Should we root this MIB module under snmpModules?=20 see my arguments in my review of the MIB module in draft-ietf-isms-transport-security-model-05.txt If we do keep it under snmpModules, then=20 sshtmMIB MODULE-IDENTITY possibly would be better snmpSshtmMIB MODULE-IDENTITY to be consistent with the other MIB modules under snmpModules. - Copyright in MIB module should be IETF Trust, not ISOC - I see: sshtmGroups OBJECT IDENTIFIER ::=3D { sshtmConformance 1 } sshtmCompliances OBJECT IDENTIFIER ::=3D { sshtmConformance 2 } while RFC4181 suggests: xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) i.e. first compliances, then groups. - For SnmpSSHAddress ::=3D TEXTUAL-CONVENTION I read: "Represents either a hostname encoded in ASCII using the IDNA protocol, as specified in RFC3490, followed by a colon ':' (ASCII character 0x3A) and a decimal port number in ASCII, or an IP address followed by a colon ':' (ASCII character 0x3A) and a decimal port number in ASCII. The name SHOULD be fully qualified whenever possible. I am not well versed/experienced in IDNA. But is IDNA a protocol? The title of 3490 reads Internationalizing Domain Names in Applications (IDNA) And are we indeed speaking of a hostname, or of a domain name, or of both? I can't quickly determine that. So I wonder if/hope that we can be clearer here. I also assume (although this is not explicitly stated) that if we speak about an IP address, that it is a dotted decimal for IPv4 and and a colon separated IPv6 address in ASCII? Yes/no? I am concerned that for=20 SnmpUDPAddress ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d" we use a / sign to separate the port from the IPv4 address and here we use a colon (:). I must admit that (RFC3419) also uses : TransportAddressIPv4 ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d:2d" And what do we use for IPv6 addresses/ports? =20 Further I read: When this textual convention is used as a syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the OBJECT-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers." Mmm.. we do not normally enforce (i.e. MUST language) that a SIZE clause must be used. We allo the DESCIRPTION clause to explain that implementers must be aware and cater for OID limitations. So do we really want that MUST language here? Bert Wijnen=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 09 07:58:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ6dW-00046y-QA; Thu, 09 Aug 2007 07:57:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ6dV-00046q-Qx for isms@ietf.org; Thu, 09 Aug 2007 07:57:05 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ6dV-0001Uv-CD for isms@ietf.org; Thu, 09 Aug 2007 07:57:05 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Aug 2007 07:57:04 -0400 X-IronPort-AV: i="4.19,240,1183348800"; d="scan'208"; a="46025290:sNHT7848642" 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 Date: Thu, 9 Aug 2007 13:56:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments - draft-ietf-isms-transport-security-model-05.txt Thread-Index: AcfafE7AgIUCBSdDTem/2fXAFNIpNw== From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [Isms] WGLC comments - draft-ietf-isms-transport-security-model-05.txt 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 1. Is RFC 2828 referred by other security-related documents? I find this document problematic, there is a revision on the table IESG table that has also problems and I decided that I cannot support it because among other inadequate terminology concerning SNMP and management aspects. The way it is mentioned in Section 1.2 may be interpreted that with the right timing this document could be relevant, which is not the case IMO. I would either ignore it, or just mention that the terminology in this document is not intended to be consistent with RFC 2828.=20 2. It would be good to include the comment that MIB objects defined here SHOULD not be referenced in other documents in the MIB module itself, maybe in the DESCRIPTION clause.=20 3. Bert already mentioned the issue of ::=3D { snmpModules xxxx } Actually I believe there is a justification of consistency with the snmpUsmMIB which was defined prior to RFC 4181 if the authors believe that this is important, but I agree that snmpTsmMIB is a better MIB.=20 If you do take this path, I believe that you should clarify in the IANA considerations section that the policy of further assignments of new values under snmpModules is Standards Action. 4. Some abbreviations (MPM, ASI) are being reused from other SNMP documents as RFC 3411 without being expanded at first occurrence or the origin being referred to.=20 Dan _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 09 10:01:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8Yf-0008Dy-SP; Thu, 09 Aug 2007 10:00:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8Ye-0008Dt-8T for isms@ietf.org; Thu, 09 Aug 2007 10:00:12 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ8Yd-00047s-SM for isms@ietf.org; Thu, 09 Aug 2007 10:00:12 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007080914001101100lhkdre>; Thu, 9 Aug 2007 14:00:11 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , References: Subject: RE: [Isms] WGLC comments -draft-ietf-isms-transport-security-model-05.txt Date: Thu, 9 Aug 2007 10:00:08 -0400 Message-ID: <00b601c7da8d$98e7a3f0$6702a8c0@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: AcfafE7AgIUCBSdDTem/2fXAFNIpNwACPyjQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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, comments inline. > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, August 09, 2007 7:56 AM > To: isms@ietf.org > Subject: [Isms] WGLC comments > -draft-ietf-isms-transport-security-model-05.txt > > > 1. Is RFC 2828 referred by other security-related documents? > I find this > document problematic, there is a revision on the table IESG table that > has also problems and I decided that I cannot support it because among > other inadequate terminology concerning SNMP and management > aspects. The > way it is mentioned in Section 1.2 may be interpreted that with the > right timing this document could be relevant, which is not > the case IMO. > I would either ignore it, or just mention that the terminology in this > document is not intended to be consistent with RFC 2828. The issue was raised during WGLC that there is a difference between our use of the word authenticate and the glossary in RFC2828. I think re-defining the English words will not help the IETF write clear and unambiguous specifications. If a document does use the RFC2828(bis) definitions, then that document should clearly specify which words it uses are consistent with the RFC2828(bis) terminology. I think it would be a bad idea to require or even claim consistency with RFC2828(bis), because it will be tremendously hard to verify that every word or phrase covered in RFC2828(bis) is used correctly in the document. It is already hard to verify that MUST/SHOULD/MAY are used correctly, and RFC2828bis has 300 pages of definitions. I will word-smith this section. > > 2. It would be good to include the comment that MIB objects > defined here > SHOULD not be referenced in other documents in the MIB module itself, > maybe in the DESCRIPTION clause. I'll look at how I can add that to the MIB definitions. > > 3. Bert already mentioned the issue of > > ::= { snmpModules xxxx } > > Actually I believe there is a justification of consistency with the > snmpUsmMIB which was defined prior to RFC 4181 if the authors believe > that this is important, but I agree that snmpTsmMIB is a better MIB. > > If you do take this path, I believe that you should clarify > in the IANA > considerations section that the policy of further assignments of new > values under snmpModules is Standards Action. I can live with this either way. > > 4. Some abbreviations (MPM, ASI) are being reused from other SNMP > documents as RFC 3411 without being expanded at first > occurrence or the > origin being referred to. I'll check for this. dbh > > Dan > > _______________________________________________ > 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 Aug 10 05:15:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJQYk-0005aQ-Am; Fri, 10 Aug 2007 05:13:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJQYj-0005aL-Fy for isms@ietf.org; Fri, 10 Aug 2007 05:13:29 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJQYi-0004BJ-9S for isms@ietf.org; Fri, 10 Aug 2007 05:13:28 -0400 Received: from pc6 (1Cust185.tnt15.lnd4.gbr.da.uu.net [62.188.144.185]) by astro.systems.pipex.net (Postfix) with SMTP id A1C5EE0002BF; Fri, 10 Aug 2007 10:13:24 +0100 (BST) Message-ID: <00bf01c7db25$8c8d6ca0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Romascanu, Dan \(Dan\)'" , References: <00b601c7da8d$98e7a3f0$6702a8c0@china.huawei.com> Subject: Re: [Isms] WGLC comments-draft-ietf-isms-transport-security-model-05.txt Date: Fri, 10 Aug 2007 08:40:42 +0200 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: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Harrington" To: "'Romascanu, Dan (Dan)'" ; Sent: Thursday, August 09, 2007 4:00 PM Subject: RE: [Isms] WGLC comments-draft-ietf-isms-transport-security-model-05.txt > > comments inline. > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Thursday, August 09, 2007 7:56 AM > > To: isms@ietf.org > > Subject: [Isms] WGLC comments > > -draft-ietf-isms-transport-security-model-05.txt > > > > > > 1. Is RFC 2828 referred by other security-related documents? > > I find this > > document problematic, there is a revision on the table IESG table > that > > has also problems and I decided that I cannot support it because > among > > other inadequate terminology concerning SNMP and management > > aspects. The > > way it is mentioned in Section 1.2 may be interpreted that with the > > right timing this document could be relevant, which is not > > the case IMO. > > I would either ignore it, or just mention that the terminology in > this > > document is not intended to be consistent with RFC 2828. > > The issue was raised during WGLC that there is a difference between > our use of the word authenticate and the glossary in RFC2828. I think > re-defining the English words will not help the IETF write clear and > unambiguous specifications. > > If a document does use the RFC2828(bis) definitions, then that > document should clearly specify which words it uses are consistent > with the RFC2828(bis) terminology. > > I think it would be a bad idea to require or even claim consistency > with RFC2828(bis), because it will be tremendously hard to verify that > every word or phrase covered in RFC2828(bis) is used correctly in the > document. It is already hard to verify that MUST/SHOULD/MAY are used > correctly, and RFC2828bis has 300 pages of definitions. > > I will word-smith this section. > Dan I raised the issue earlier, that there are two distinct uses I see for authentication, within the IETF and without, the USM use and the TLS./SSH use (and it has been argued, on the TLS list and other, that what TLS provides is not authentication). I have no problem with the current SNMP RFC since RFC3414 makes it clear what you get; with isms using the same language, and with TLS/SSH providing a quite different facility, I think that the elements could mislead someone into thinking that they are getting a security that they are not.. I am happy that the current text clarifies this; I like the definitions of authenticity in RFC2828 - they are in accord with what I see elsewhere. But the current text goes beyond the issue I raised so hopefully there is scope in the middle which will satisfy us both Tom Petch .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 Aug 10 05:15:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJQYm-0005ak-Er; Fri, 10 Aug 2007 05:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJQYl-0005ad-P7 for isms@ietf.org; Fri, 10 Aug 2007 05:13:31 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJQYk-0007Lv-8M for isms@ietf.org; Fri, 10 Aug 2007 05:13:31 -0400 Received: from pc6 (1Cust185.tnt15.lnd4.gbr.da.uu.net [62.188.144.185]) by astro.systems.pipex.net (Postfix) with SMTP id 23D9CE00037E; Fri, 10 Aug 2007 10:13:27 +0100 (BST) Message-ID: <00c701c7db25$8e0f78c0$0601a8c0@pc6> From: "tom.petch" To: "Juergen Quittek" , "ISMS WG" References: Subject: Re: [Isms] Working Group Last Call tmsm-09 Date: Fri, 10 Aug 2007 09:36:34 +0200 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: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 Eeee, reading this does not get any easier a) I would like to see more words on susbsystem/model/mapping since it has been a source of confusion on this list and is likely to be so to a wider audience. I know that RFC3411 explains this point but I read that document several times without getting it. I am looking at para. 2 towards the end. Where it says "This document defines a Transport Subsystem extension" that is ambiguous; an extension to the Transport Subsystem or an extension to the architecture? and later it says "through an SNMP Transport Model [RFC3417]. Such a Transport Model " well no; in the absence of a susbsystem, as now, there can be no model. I suggest the following instead "The current RFC3411 architecture does not encompass transport (although RFC3417 does define transport mappings). This document adds a transport subsystem, based on the third approach, to the architecture, and this enables the use of existing security mechanisms such as TLS [RFC4346] or SSH [RFC4251] within the enhanced RFC3411 architecture. A companion document [I-D.draft-ietf-isms-secshell-08] defines a transport model which is based on SSH while [I-D.ietf-isms-transport-security-model] defines a security model which uses this approach" (I am a believer in stating the obvious when that may not be obvious to someone who has not been following isms for four years:-). b) 3.2.1.1 /is/in/ c) 3.2.1.2 I think that the transport model MUST be aware of the mapping between securityName and transportspecificName else how can it select the right transport? d) ... and that is in step 2 not step 3. e) 3.3.1 is the use of 'agent' here wilful? I notice that the term is banned in 'transport-security-model' f) 3.3.2 would seem to preclude the renegotiation of keys, a recommended practice during a long running session. Suggest a rewording of the two sentences starting 'Cryptographic keys ...' to "Fresh session keys should be established at the beginning of each session in order to provide authentication, integrity and confidentiality, whichever of these services are required." g) 4 /pdutype/pduType/ h) 5.2 'The tmStateReference captured during processing of an incoming message SHOULD include a transport- specific session identifier.' I think that the nature of this identifier MUST be specified, either in the security or transport model. Getting it wrong invalidates the security and it is not obvious what it should; the right answers for TLS and SSH are quite different. i) 'The Transport Subsystem architecture document will reflect the SNMPv3 WG's decision that **architecturally** this is a SHOULD. The decision is security-model-dependent, and the Transport Security Model will make it a MUST.' I am still seeing a 'MUST' in this section. j) 6.2 I am still puzzled by the absence of prepareResponseMessage and cannot see how it works without it Tom Petch ----- Original Message ----- From: "Juergen Quittek" To: "ISMS WG" Sent: Wednesday, July 18, 2007 3:15 PM Subject: [Isms] Working Group Last Call on three documents > Dear all, > > This is the working group last call on all of our three current working > group documents > > - Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > - Transport Security Model for SNMP > draft-ietf-isms-transport-security-model-05.txt > > - Secure Shell Transport Model for SNMP > draft-ietf-isms-secshell-08.txt > > The authors and the chairs think that these document are mature > enough for WGLC. > > The first two already passed a first WGLC, but there were many > comments and changes since then. They should be reviewed once more. > > Because we have the IETF meeting ahead and people are already busy with > reviewing many other drafts, the WGLC will last more than the usual two > weeks. > > Please do review these document and post your comments on this list until > August 10, 2007. > > Please also post to the list if you have read one of the documents and > are fine with it as it is. It is very useful to know how many people > have read the document. > > Thanks, > > Juergen Q. > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 > NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK > Registered in England 2832014 > > > _______________________________________________ > 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 Aug 10 08:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJT8N-0004pd-3m; Fri, 10 Aug 2007 07:58:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJT8L-0004lm-F3 for isms@ietf.org; Fri, 10 Aug 2007 07:58:25 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJT8J-0003S5-Va for isms@ietf.org; Fri, 10 Aug 2007 07:58:25 -0400 Received: from pc6 (1Cust92.tnt102.lnd4.gbr.da.uu.net [213.116.52.92]) by astro.systems.pipex.net (Postfix) with SMTP id 9D756E0004FA; Fri, 10 Aug 2007 12:58:20 +0100 (BST) Message-ID: <037c01c7db3c$9725b520$0601a8c0@pc6> From: "tom.petch" To: "Juergen Quittek" , "ISMS WG" References: Subject: Re: [Isms] Working Group Last Call - securityName Date: Fri, 10 Aug 2007 12:34:11 +0200 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: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 I remain confused about the translation between a transport dependent principal name(TDPM) and the architectural securityName. tmsm requires the Ttransport Model to find a matching session and securityName is part of the key for the match, so the Transport Model must know the securityName; self-evidently, it must also know the corresponding TDPM Why then does transport-security-model say 'When the Transport Security Model is used with a secure Transport Model, the information in the cache is used by the Transport Security Model to translate between the security model-independent securityName and any identity used by the secure transport; ' Why does it need to know? Can it know for the first CR message of a session? I think that the Transport Model must know and that the Security Model need not; if the Security Model were ever to change the mapping, then the Transport Model should probably tear down the session and start again. Tom Petch ----- Original Message ----- From: "Juergen Quittek" To: "ISMS WG" Sent: Wednesday, July 18, 2007 3:15 PM Subject: [Isms] Working Group Last Call on three documents > Dear all, > > This is the working group last call on all of our three current working > group documents > > - Transport Subsystem for the Simple Network Management Protocol (SNMP) > > > - Transport Security Model for SNMP > draft-ietf-isms-transport-security-model-05.txt > > - Secure Shell Transport Model for SNMP > draft-ietf-isms-secshell-08.txt > > The authors and the chairs think that these document are mature > enough for WGLC. > > The first two already passed a first WGLC, but there were many > comments and changes since then. They should be reviewed once more. > > Because we have the IETF meeting ahead and people are already busy with > reviewing many other drafts, the WGLC will last more than the usual two > weeks. > > Please do review these document and post your comments on this list until > August 10, 2007. > > Please also post to the list if you have read one of the documents and > are fine with it as it is. It is very useful to know how many people > have read the document. > > Thanks, > > Juergen Q. > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 > NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK > Registered in England 2832014 > > > _______________________________________________ > 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 Aug 10 08:57:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJU1j-00066a-S4; Fri, 10 Aug 2007 08:55:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJU1i-00066T-N0 for isms@ietf.org; Fri, 10 Aug 2007 08:55:38 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJU1h-0004ne-G2 for isms@ietf.org; Fri, 10 Aug 2007 08:55:38 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <200708101255360140008f2ie>; Fri, 10 Aug 2007 12:55:36 +0000 From: "David Harrington" To: "'tom.petch'" , "'Juergen Quittek'" , "'ISMS WG'" References: <037c01c7db3c$9725b520$0601a8c0@pc6> Subject: RE: [Isms] Working Group Last Call - securityName Date: Fri, 10 Aug 2007 08:55:33 -0400 Message-ID: <016a01c7db4d$bd2fa710$6702a8c0@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: <037c01c7db3c$9725b520$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfbRgKHoA5QVf8CTeOf58fdzNBtoAAARAhg X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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, messaging acm ^ ^ | | msgSecParams securityName | | v v transport security application |<--------------------->|<--------------->| <--tmStateRef--------->|<--securityName->| On incoming messages, I1) transport MAY provide a mapping between the transport-specific identity and a **proposed** securityName, which it puts into the tmStateReference cache. I2) messaging extracts the security information from the message and passes it to the selected security model I3) the security model may extract an identity from the security parameters passed from the messaging model as a *proposed* securityName. I4) the security model decides which proposed securityName becomes the official securityName to be passed on to the application for use in access control I5) if this is an incoming request, then the security model saves the security state information so the response can be sent using the same security paramaters (which would include inforamtion about the secure transport session used). For outgoing messages, O1) the application subsystem specifies the securityName O2) the security determines if this is a response message, and if so, extracts the security/transport info from the security state cache. O3) the security model determines what identity should be put into the message, if any, and what identity should be passed to the transport model, if any. It uses information from the securityState cache when making this decision for responses. The decisions made at each step in the process are model-dependent. It is the responsibility of the security model to determine the value of the securityname that will be used by the application and access control subsystems. The messaging subsystem makes the decision about which security model will be used. The transport and messaging subsystem MAY provide information to the security model to aid in making the decision. What each model knows at each step depends a lot on whether you are talking about an incoming message or an outgping message, and whether the outgoing message is a response. Can you ask your questions again, making it clear whether you are in the flow of an outgoing message or the flow of an incoming message? David Harrington dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, August 10, 2007 6:34 AM > To: Juergen Quittek; ISMS WG > Subject: Re: [Isms] Working Group Last Call - securityName > > I remain confused about the translation between a transport > dependent principal > name(TDPM) and the architectural securityName. > > tmsm requires the Ttransport Model to find a matching session > and securityName > is part of the key for the match, so the Transport Model must know the > securityName; self-evidently, it must also know the corresponding TDPM > > Why then does transport-security-model say > > 'When the Transport Security Model is > used with a secure Transport Model, the information in the cache is > used by the Transport Security Model to translate between the > security model-independent securityName and any identity used by the > secure transport; ' > > Why does it need to know? Can it know for the first CR > message of a session? I > think that the Transport Model must know and that the > Security Model need not; > if the Security Model were ever to change the mapping, then > the Transport Model > should probably tear down the session and start again. > > Tom Petch > > ----- Original Message ----- > From: "Juergen Quittek" > To: "ISMS WG" > Sent: Wednesday, July 18, 2007 3:15 PM > Subject: [Isms] Working Group Last Call on three documents > > > > Dear all, > > > > This is the working group last call on all of our three > current working > > group documents > > > > - Transport Subsystem for the Simple Network Management > Protocol (SNMP) > > > > > > - Transport Security Model for SNMP > > draft-ietf-isms-transport-security-model-05.txt > > > > - Secure Shell Transport Model for SNMP > > draft-ietf-isms-secshell-08.txt > > > > The authors and the chairs think that these document are mature > > enough for WGLC. > > > > The first two already passed a first WGLC, but there were many > > comments and changes since then. They should be reviewed once more. > > > > Because we have the IETF meeting ahead and people are > already busy with > > reviewing many other drafts, the WGLC will last more than > the usual two > > weeks. > > > > Please do review these document and post your comments on > this list until > > August 10, 2007. > > > > Please also post to the list if you have read one of the > documents and > > are fine with it as it is. It is very useful to know how > many people > > have read the document. > > > > Thanks, > > > > Juergen Q. > > -- > > Juergen Quittek quittek@netlab.nec.de Tel: +49 > 6221 4342-115 > > NEC Europe Limited, Network Laboratories Fax: +49 > 6221 4342-155 > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de > > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK > > Registered in England 2832014 > > > > > > _______________________________________________ > > 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 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 10 09:35:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJUcv-0006kr-KD; Fri, 10 Aug 2007 09:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJUcu-0006km-5f for isms@ietf.org; Fri, 10 Aug 2007 09:34:04 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJUcs-0005dY-Vq for isms@ietf.org; Fri, 10 Aug 2007 09:34:04 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc14) with SMTP id <20070810133402014000745ke>; Fri, 10 Aug 2007 13:34:02 +0000 From: "David Harrington" To: "'tom.petch'" , "'Juergen Quittek'" , "'ISMS WG'" References: <037d01c7db3c$97ffe880$0601a8c0@pc6> Subject: RE: [Isms] Working Group Last Call - securityLevel Date: Fri, 10 Aug 2007 09:34:00 -0400 Message-ID: <017301c7db53$1c65ca70$6702a8c0@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: <037d01c7db3c$97ffe880$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfbRgWCZZU5rKOmT6mkBBTuShvRqQACGb4g X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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 Tom, The comparison in 6) compares the securityLevel specified **in the message** (extracted by the messaging model and passed to the security model using the processIncomingMsg service primitive), with that specified by the transport model and passed in the tmStateReference. The value in the message is set based on the request of the application. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, August 10, 2007 6:41 AM > To: Juergen Quittek; ISMS WG > Subject: Re: [Isms] Working Group Last Call - securityLevel > > I remain confused about the securityLevel in the > tmStateReferenced cache > > transport-security-model says > > '2) If there is no securityStateReference, > [**ie Request, Notification] > then find or create an > entry in a Local Configuration Datastore containing the provided > [**destination] > transportDomain, transportAddress, securityName, securityLevel, and > securityModel, create a tmStateReference to reference the entry.' > ie securityLevel is derived from the CR application > > it also says, for an incoming message, > > '6) Compare the value of securityLevel in the cache referenced by > tmStateReference to the value of the securityLevel parameter passed > in the processIncomingMsg service primitive. If the parameter > specifies privacy (Priv), and the cache specifies no > privacy (noPriv) > was provided by the Transport Model, or the parameter specifies > authentication (auth) and the cache specifies no authentication > (noAuth) was provided by the Transport Model, then the > tsmInadequateSecurity counter is incremented, and an error > indication > (unsupportedSecurityLevel) together with the OID and value of the > incremented counter is returned to the calling module.' > > so here securityLevel in the cache is that derived from the > transport not that > derived from the application > > I cannot see how this checks that the transport level > security is not less than > that requested by the application. > > Tom Petch > > > ----- Original Message ----- > From: "Juergen Quittek" > To: "ISMS WG" > Sent: Wednesday, July 18, 2007 3:15 PM > Subject: [Isms] Working Group Last Call on three documents > > > > Dear all, > > > > This is the working group last call on all of our three > current working > > group documents > > > > - Transport Subsystem for the Simple Network Management > Protocol (SNMP) > > > > > > - Transport Security Model for SNMP > > draft-ietf-isms-transport-security-model-05.txt > > > > - Secure Shell Transport Model for SNMP > > draft-ietf-isms-secshell-08.txt > > > > The authors and the chairs think that these document are mature > > enough for WGLC. > > > > The first two already passed a first WGLC, but there were many > > comments and changes since then. They should be reviewed once more. > > > > Because we have the IETF meeting ahead and people are > already busy with > > reviewing many other drafts, the WGLC will last more than > the usual two > > weeks. > > > > Please do review these document and post your comments on > this list until > > August 10, 2007. > > > > Please also post to the list if you have read one of the > documents and > > are fine with it as it is. It is very useful to know how > many people > > have read the document. > > > > Thanks, > > > > Juergen Q. > > -- > > Juergen Quittek quittek@netlab.nec.de Tel: +49 > 6221 4342-115 > > NEC Europe Limited, Network Laboratories Fax: +49 > 6221 4342-155 > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de > > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK > > Registered in England 2832014 > > > > > > _______________________________________________ > > 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 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Aug 11 01:25:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJjRa-0004kU-Gq; Sat, 11 Aug 2007 01:23:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJjRY-0004iL-Uk for isms@ietf.org; Sat, 11 Aug 2007 01:23:20 -0400 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJjRX-0007C0-Ff for isms@ietf.org; Sat, 11 Aug 2007 01:23:20 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id EEBAD399CA1; Fri, 10 Aug 2007 22:24:38 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Fri, 10 Aug 2007 22:24:38 -0700 Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.19 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [Isms] barely a review: secshell-08 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 didn't get as far into it as I had hoped, but I do support the document based on what I've read so far and think it's important work. misc points: introduction: Secure Shell Protocol => Secure Shell Protocol (SSH) [RFC4251?] 1.2: acting as either manager or agent or both => acting in either manager or agent or both roles SNMP applications included in the engine => SNMP application types being implemented (the SNMP applications don't sit in the engine, so the original wording doesn't meet the SNMP architecture). USM => User-Based Security Model (USM) [RFC3414] delete the last paragraph (todo markings) 1.3: design decision*s* => design decision These MIB objects SHOULD NOT be referenced in other documents That one kind of bothers me. Generally in the IETF, we encourage cross-reuse among MIB modules and here you're specifically saying pretend this one doesn't exist if you're working on something else. I'm not really fond of that notion. I do understand the rational for wanting to do it, but I don't think you gain anything in the end and you certainly loose the ability to do some possible future reuse. 1.4: USM typically utilizes => USM utilizes not deploying SNMPv3 at this point in time => not deploying SNMPv3 to minimize the time until deployment is possible => to minimize deployment time 4th paragarph, 1st sentence: does the work properly allow for future SSH extensions to add authentication capabilities (I believe it is supposed to). If so, that should probably be noted in this sentence. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Aug 11 07:05:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJokb-0000B4-DU; Sat, 11 Aug 2007 07:03:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJoka-0008W8-Ru for isms@ietf.org; Sat, 11 Aug 2007 07:03:20 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJokZ-0004Ot-MM for isms@ietf.org; Sat, 11 Aug 2007 07:03:20 -0400 Received: from pc6 (1Cust189.tnt30.lnd3.gbr.da.uu.net [62.188.122.189]) by blaster.systems.pipex.net (Postfix) with SMTP id 92B53E0005EC; Sat, 11 Aug 2007 12:03:15 +0100 (BST) Message-ID: <000f01c7dbfe$0eba1240$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Juergen Quittek'" , "'ISMS WG'" References: <037d01c7db3c$97ffe880$0601a8c0@pc6> <017301c7db53$1c65ca70$6702a8c0@china.huawei.com> Subject: Re: [Isms] Working Group Last Call - securityLevel Date: Sat, 11 Aug 2007 11:52:48 +0200 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: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f 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 Harrington" To: "'tom.petch'" ; "'Juergen Quittek'" ; "'ISMS WG'" Sent: Friday, August 10, 2007 3:34 PM Subject: RE: [Isms] Working Group Last Call - securityLevel > Hi Tom, > > The comparison in 6) compares the securityLevel specified **in the > message** (extracted by the messaging model and passed to the security > model using the processIncomingMsg service primitive), with that > specified by the transport model and passed in the tmStateReference. > > The value in the message is set based on the request of the > application. > Yeees; I see that s5.2 6) uses the value of securityLevel from the cache which has been put there by the transport model but I also see that s4.3 2) has the Transport Security Model place securityLevel in the cache and at that stage, the transport model has not been invoked and so the securityLevel referred to can only be that specifed by the application, it cannot be that from the message. So sometimes the securityLevel in the cache comes up from the transport, sometimes it comes down from the application; yes? Tom Petch > dbh > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Friday, August 10, 2007 6:41 AM > > To: Juergen Quittek; ISMS WG > > Subject: Re: [Isms] Working Group Last Call - securityLevel > > > > I remain confused about the securityLevel in the > > tmStateReferenced cache > > > > transport-security-model says > > > > '2) If there is no securityStateReference, > > [**ie Request, Notification] > > then find or create an > > entry in a Local Configuration Datastore containing the provided > > [**destination] > > transportDomain, transportAddress, securityName, securityLevel, > and > > securityModel, create a tmStateReference to reference the entry.' > > ie securityLevel is derived from the CR application > > > > it also says, for an incoming message, > > > > '6) Compare the value of securityLevel in the cache referenced by > > tmStateReference to the value of the securityLevel parameter > passed > > in the processIncomingMsg service primitive. If the parameter > > specifies privacy (Priv), and the cache specifies no > > privacy (noPriv) > > was provided by the Transport Model, or the parameter specifies > > authentication (auth) and the cache specifies no authentication > > (noAuth) was provided by the Transport Model, then the > > tsmInadequateSecurity counter is incremented, and an error > > indication > > (unsupportedSecurityLevel) together with the OID and value of the > > incremented counter is returned to the calling module.' > > > > so here securityLevel in the cache is that derived from the > > transport not that > > derived from the application > > > > I cannot see how this checks that the transport level > > security is not less than > > that requested by the application. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Juergen Quittek" > > To: "ISMS WG" > > Sent: Wednesday, July 18, 2007 3:15 PM > > Subject: [Isms] Working Group Last Call on three documents > > > > > > > Dear all, > > > > > > This is the working group last call on all of our three > > current working > > > group documents > > > > > > - Transport Subsystem for the Simple Network Management > > Protocol (SNMP) > > > > > > > > > - Transport Security Model for SNMP > > > draft-ietf-isms-transport-security-model-05.txt > > > > > > - Secure Shell Transport Model for SNMP > > > draft-ietf-isms-secshell-08.txt > > > > > > The authors and the chairs think that these document are mature > > > enough for WGLC. > > > > > > The first two already passed a first WGLC, but there were many > > > comments and changes since then. They should be reviewed once > more. > > > > > > Because we have the IETF meeting ahead and people are > > already busy with > > > reviewing many other drafts, the WGLC will last more than > > the usual two > > > weeks. > > > > > > Please do review these document and post your comments on > > this list until > > > August 10, 2007. > > > > > > Please also post to the list if you have read one of the > > documents and > > > are fine with it as it is. It is very useful to know how > > many people > > > have read the document. > > > > > > Thanks, > > > > > > Juergen Q. > > > -- > > > Juergen Quittek quittek@netlab.nec.de Tel: +49 > > 6221 4342-115 > > > NEC Europe Limited, Network Laboratories Fax: +49 > > 6221 4342-155 > > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > > http://www.netlab.nec.de > > > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK > > > Registered in England 2832014 > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 13 05:37:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWKW-0000EK-QG; Mon, 13 Aug 2007 05:35:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWKV-0000E9-Q1 for isms@ietf.org; Mon, 13 Aug 2007 05:35:19 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKWKU-0006P8-Le for isms@ietf.org; Mon, 13 Aug 2007 05:35:19 -0400 Received: from pc6 (1Cust103.tnt3.lnd4.gbr.da.uu.net [62.188.132.103]) by galaxy.systems.pipex.net (Postfix) with SMTP id 8836DE0007B3; Mon, 13 Aug 2007 10:35:12 +0100 (BST) Message-ID: <01af01c7dd84$15202c00$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'Juergen Quittek'" , "'ISMS WG'" References: <037c01c7db3c$9725b520$0601a8c0@pc6> <016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com> Subject: Re: [Isms] Working Group Last Call - securityName Date: Mon, 13 Aug 2007 10:25:09 +0200 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: 140baa79ca42e6b0e2b4504291346186 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 Thanks for the info. The issue for me is the selection of the session for outbound messages. This is based on the model-independent securityName (tmsm s.3.3) so the transport model must know that and so must also know the mapping to any transport dependent principal name. If the first message on a session is inbound, you say that the security model has the final say in the mapping. That is fine but the transport model then needs to be told this prior to an outbound message (or even prior to the next inbound message) and I would not gather this from the text in tmsm eg in s3.2.1.1. So if it is an architectural principle that the security model is responsible for the mapping, then I think that the wording in tmsm needs tightening. If the first message on a session is outbound, then I am less clear how it works. I see a transport dependent principal name as being the province of the transport, not something that the security model can dictate to transport, in which case it is the transport model that is authoritative for the mapping. Or can the security model be authoritative? Either way, I do not see definitive text saying either and I am assuming that it is an architectural principle that one or the other is authoritative for the mapping. (Can the mapping be changed as a result of an inbound response to the outbound message - I hope not) I would like the text about the mapping (in both tmsm and trasnport security model) either to be more vague, saying that this is not something that is specified by the architecture, or else to be more specific, nailing down which subsystem takes responsbility. Tom Petch ----- Original Message ----- From: "David Harrington" To: "'tom.petch'" ; "'Juergen Quittek'" ; "'ISMS WG'" Sent: Friday, August 10, 2007 2:55 PM Subject: RE: [Isms] Working Group Last Call - securityName > Hi, > > messaging acm > ^ ^ > | | > msgSecParams securityName > | | > v v > transport security application > |<--------------------->|<--------------->| > <--tmStateRef--------->|<--securityName->| > > On incoming messages, > I1) transport MAY provide a mapping between the transport-specific > identity and a **proposed** securityName, which it puts into the > tmStateReference cache. > I2) messaging extracts the security information from the message and > passes it to the selected security model > I3) the security model may extract an identity from the security > parameters passed from the messaging model as a *proposed* > securityName. > I4) the security model decides which proposed securityName becomes the > official securityName to be passed on to the application for use in > access control > I5) if this is an incoming request, then the security model saves the > security state information so the response can be sent using the same > security paramaters (which would include inforamtion about the secure > transport session used). > > For outgoing messages, > O1) the application subsystem specifies the securityName > O2) the security determines if this is a response message, and if so, > extracts the security/transport info from the security state cache. > O3) the security model determines what identity should be put into the > message, if any, and what identity should be passed to the transport > model, if any. It uses information from the securityState cache when > making this decision for responses. > > The decisions made at each step in the process are model-dependent. > It is the responsibility of the security model to determine the value > of the securityname that will be used by the application and access > control subsystems. > The messaging subsystem makes the decision about which security model > will be used. > The transport and messaging subsystem MAY provide information to the > security model to aid in making the decision. > > What each model knows at each step depends a lot on whether you are > talking about an incoming message or an outgping message, and whether > the outgoing message is a response. Can you ask your questions again, > making it clear whether you are in the flow of an outgoing message or > the flow of an incoming message? > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Friday, August 10, 2007 6:34 AM > > To: Juergen Quittek; ISMS WG > > Subject: Re: [Isms] Working Group Last Call - securityName > > > > I remain confused about the translation between a transport > > dependent principal > > name(TDPM) and the architectural securityName. > > > > tmsm requires the Ttransport Model to find a matching session > > and securityName > > is part of the key for the match, so the Transport Model must know > the > > securityName; self-evidently, it must also know the corresponding > TDPM > > > > Why then does transport-security-model say > > > > 'When the Transport Security Model is > > used with a secure Transport Model, the information in the cache > is > > used by the Transport Security Model to translate between the > > security model-independent securityName and any identity used by > the > > secure transport; ' > > > > Why does it need to know? Can it know for the first CR > > message of a session? I > > think that the Transport Model must know and that the > > Security Model need not; > > if the Security Model were ever to change the mapping, then > > the Transport Model > > should probably tear down the session and start again. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Juergen Quittek" > > To: "ISMS WG" > > Sent: Wednesday, July 18, 2007 3:15 PM > > Subject: [Isms] Working Group Last Call on three documents > > > > > > > Dear all, > > > > > > This is the working group last call on all of our three > > current working > > > group documents > > > > > > - Transport Subsystem for the Simple Network Management > > Protocol (SNMP) > > > > > > > > > - Transport Security Model for SNMP > > > draft-ietf-isms-transport-security-model-05.txt > > > > > > - Secure Shell Transport Model for SNMP > > > draft-ietf-isms-secshell-08.txt > > > > > > The authors and the chairs think that these document are mature > > > enough for WGLC. > > > > > > The first two already passed a first WGLC, but there were many > > > comments and changes since then. They should be reviewed once > more. > > > > > > Because we have the IETF meeting ahead and people are > > already busy with > > > reviewing many other drafts, the WGLC will last more than > > the usual two > > > weeks. > > > > > > Please do review these document and post your comments on > > this list until > > > August 10, 2007. > > > > > > Please also post to the list if you have read one of the > > documents and > > > are fine with it as it is. It is very useful to know how > > many people > > > have read the document. > > > > > > Thanks, > > > > > > Juergen Q. > > > -- > > > Juergen Quittek quittek@netlab.nec.de Tel: +49 > > 6221 4342-115 > > > NEC Europe Limited, Network Laboratories Fax: +49 > > 6221 4342-155 > > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > > http://www.netlab.nec.de > > > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK > > > Registered in England 2832014 > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 13 11:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKcC1-0002xM-7k; Mon, 13 Aug 2007 11:50:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKcC0-0002xH-H8 for isms@ietf.org; Mon, 13 Aug 2007 11:50:56 -0400 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKcBz-0000fQ-Bi for isms@ietf.org; Mon, 13 Aug 2007 11:50:56 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc16) with SMTP id <20070813155054b1600qlmj0e>; Mon, 13 Aug 2007 15:50:54 +0000 From: "David Harrington" To: "'ISMS WG'" Date: Mon, 13 Aug 2007 11:50:49 -0400 Message-ID: <000001c7ddc1$b8ad72f0$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfdpRS4+kElyPnNSaiWI0yCsxPe4g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Isms] SNMP-SSH-TM-MIB session info 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, SNMP does not have sessions; the only sessions are sessions of the transport protocol. This module counts sessions. We have no way of knowing whether, for example, SSH chooses to close a session without telling us. We can only count how many times we called openSession, and how many times we called closeSession ASIs. We do not know how many sessions the SSH implementation can handle, or how many SSH sessions are currently open. I think we should eliminate the sshtmSessionCurrent and sshtmSessionMaxSupported objects. If people want this information, they should request that the SecSH WG write a MIB module for managing SSH sessions. 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 Mon Aug 13 13:38:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdqC-0002e4-4H; Mon, 13 Aug 2007 13:36:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdqB-0002dz-4F for isms@ietf.org; Mon, 13 Aug 2007 13:36:31 -0400 Received: from alnrmhc15.comcast.net ([206.18.177.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKdq9-0006Dm-T2 for isms@ietf.org; Mon, 13 Aug 2007 13:36:31 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc15) with SMTP id <20070813173628b1500a1vpke>; Mon, 13 Aug 2007 17:36:29 +0000 From: "David Harrington" To: "'tom.petch'" , "'ISMS WG'" References: <037c01c7db3c$9725b520$0601a8c0@pc6> <016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com> <01af01c7dd84$15202c00$0601a8c0@pc6> Subject: RE: [Isms] Working Group Last Call - securityName Date: Mon, 13 Aug 2007 13:36:25 -0400 Message-ID: <000901c7ddd0$79189a20$6702a8c0@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: <01af01c7dd84$15202c00$0601a8c0@pc6> Thread-Index: AcfdjUO907725L7AQ8CWX7AdhyJnDQAC0x/A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad 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 need to answer this in two ways. First, you need to understand the limitations of what we can specify, and then second, I will try make sure you understand how "mappings" are handled. First, you need to understand that we are not modifying the SSH standard. We are providing an SNMP-specific interface to secure transport protocols, and we are not dictating how the implementation must handle sessions in the transport security protocol (or even whether the secure transport uses sessions). We specify that when SNMP says "give me secure transport for , at this transport address", the implementation needs to determine how to actually deliver that mapping given the chosen secure transport. There are multiple SSH implementations, and the SSH WG did not define an API for us to call to get a particular session. So there is some background processing that needs to be done, preesumably via some type of local configuration datastore, that the implementation can use to get a mapping between the secure transport sessions and credentials and the SNMP request parameters. The SSH WG decided not to write a MIB to show conceptually how this transport-specific information is maintained, and the ISMS WG decided not to write a MIB to show this SSH-specific information either. For the second point, see comments inline > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Monday, August 13, 2007 4:25 AM > To: David Harrington; 'Juergen Quittek'; 'ISMS WG' > Subject: Re: [Isms] Working Group Last Call - securityName > > Thanks for the info. The issue for me is the selection of > the session for > outbound messages. This is based on the model-independent > securityName (tmsm > s.3.3) so the transport model must know that and so must also > know the mapping > to any transport dependent principal name. > > If the first message on a session is inbound, you say that > the security model > has the final say in the mapping. You may be onto something, but I cannot tell for sure because you use language loosely. At what step in the Elements of Procedure is information missing that is needed? Where should that information be coming from? It would help immensely if you differentiated the "mapping" you refer to. There are different mappings happening. A secure transport model provides a mapping between the identity authenticated by the transport and the proposed securityName in the tmStateReference. That mapping is always the responsibility of the transport model. This mapping happens with every message, even though the authentication might be done on a transport-session-basis, and therefore should be the same for every message received within a transport session. A messaging model may provide a field in the message to allow the sending application to name a proposed securityName for the remote message-named securityModel. USM does this. It is up to USM to maintain such a mapping, e.g., via the USM-USER-MIB. This happens with every message. It is the responsibility of the securityModel to decide what inputs it will consider in making the determination of securityName to be passed to applications for an incoming message. And this happens for every message. It is the responsibility of the securitymodel to determine which information needs to be passed to the remote securitymodel for processing, for outgoing messages. For USM, the USM security model puts the something in the securityParameters in the SNMPv3 message. For TSM, it identifies which LCD entry should be used, based on securityName, securityLevel, and transport address; the LCD should contain the necessary transport-specific securityName->transport identity mapping. > That is fine but the > transport model then > needs to be told this prior to an outbound message (or even > prior to the next > inbound message) and I would not gather this from the text in > tmsm eg in > s3.2.1.1. So if it is an architectural principle that the > security model is > responsible for the mapping, then I think that the wording in > tmsm needs > tightening. > > If the first message on a session is outbound, then I am less > clear how it > works. If the first message is outbound, then the implementation needs to provide a mechanism for specifying how the initial transport information is determined. We provide some exmaples using the TARGET-MIB et al, but that is one approach to defining an LCD, but the LCD is implementation-dependent. > I see a transport dependent principal name as being > the province of the > transport, not something that the security model can dictate > to transport, in > which case it is the transport model that is authoritative > for the mapping. Or > can the security model be authoritative? Either way, I do > not see definitive > text saying either and I am assuming that it is an > architectural principle that > one or the other is authoritative for the mapping. (Can the > mapping be changed > as a result of an inbound response to the outbound message - > I hope not) > > I would like the text about the mapping (in both tmsm and > trasnport security > model) either to be more vague, saying that this is not > something that is > specified by the architecture, or else to be more specific, > nailing down which > subsystem takes responsbility. > > Tom Petch > > ----- Original Message ----- > From: "David Harrington" > To: "'tom.petch'" ; "'Juergen Quittek'" > ; "'ISMS WG'" > Sent: Friday, August 10, 2007 2:55 PM > Subject: RE: [Isms] Working Group Last Call - securityName > > > > Hi, > > > > messaging acm > > ^ ^ > > | | > > msgSecParams securityName > > | | > > v v > > transport security application > > |<--------------------->|<--------------->| > > <--tmStateRef--------->|<--securityName->| > > > > On incoming messages, > > I1) transport MAY provide a mapping between the transport-specific > > identity and a **proposed** securityName, which it puts into the > > tmStateReference cache. > > I2) messaging extracts the security information from the message and > > passes it to the selected security model > > I3) the security model may extract an identity from the security > > parameters passed from the messaging model as a *proposed* > > securityName. > > I4) the security model decides which proposed securityName > becomes the > > official securityName to be passed on to the application for use in > > access control > > I5) if this is an incoming request, then the security model > saves the > > security state information so the response can be sent > using the same > > security paramaters (which would include inforamtion about > the secure > > transport session used). > > > > For outgoing messages, > > O1) the application subsystem specifies the securityName > > O2) the security determines if this is a response message, > and if so, > > extracts the security/transport info from the security state cache. > > O3) the security model determines what identity should be > put into the > > message, if any, and what identity should be passed to the transport > > model, if any. It uses information from the securityState cache when > > making this decision for responses. > > > > The decisions made at each step in the process are model-dependent. > > It is the responsibility of the security model to determine > the value > > of the securityname that will be used by the application and access > > control subsystems. > > The messaging subsystem makes the decision about which > security model > > will be used. > > The transport and messaging subsystem MAY provide information to the > > security model to aid in making the decision. > > > > What each model knows at each step depends a lot on whether you are > > talking about an incoming message or an outgping message, > and whether > > the outgoing message is a response. Can you ask your > questions again, > > making it clear whether you are in the flow of an outgoing > message or > > the flow of an incoming message? > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > > -----Original Message----- > > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > > Sent: Friday, August 10, 2007 6:34 AM > > > To: Juergen Quittek; ISMS WG > > > Subject: Re: [Isms] Working Group Last Call - securityName > > > > > > I remain confused about the translation between a transport > > > dependent principal > > > name(TDPM) and the architectural securityName. > > > > > > tmsm requires the Ttransport Model to find a matching session > > > and securityName > > > is part of the key for the match, so the Transport Model must know > > the > > > securityName; self-evidently, it must also know the corresponding > > TDPM > > > > > > Why then does transport-security-model say > > > > > > 'When the Transport Security Model is > > > used with a secure Transport Model, the information in > the cache > > is > > > used by the Transport Security Model to translate between the > > > security model-independent securityName and any identity used by > > the > > > secure transport; ' > > > > > > Why does it need to know? Can it know for the first CR > > > message of a session? I > > > think that the Transport Model must know and that the > > > Security Model need not; > > > if the Security Model were ever to change the mapping, then > > > the Transport Model > > > should probably tear down the session and start again. > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Juergen Quittek" > > > To: "ISMS WG" > > > Sent: Wednesday, July 18, 2007 3:15 PM > > > Subject: [Isms] Working Group Last Call on three documents > > > > > > > > > > Dear all, > > > > > > > > This is the working group last call on all of our three > > > current working > > > > group documents > > > > > > > > - Transport Subsystem for the Simple Network Management > > > Protocol (SNMP) > > > > > > > > > > > > - Transport Security Model for SNMP > > > > draft-ietf-isms-transport-security-model-05.txt > > > > > > > > - Secure Shell Transport Model for SNMP > > > > draft-ietf-isms-secshell-08.txt > > > > > > > > The authors and the chairs think that these document are mature > > > > enough for WGLC. > > > > > > > > The first two already passed a first WGLC, but there were many > > > > comments and changes since then. They should be reviewed once > > more. > > > > > > > > Because we have the IETF meeting ahead and people are > > > already busy with > > > > reviewing many other drafts, the WGLC will last more than > > > the usual two > > > > weeks. > > > > > > > > Please do review these document and post your comments on > > > this list until > > > > August 10, 2007. > > > > > > > > Please also post to the list if you have read one of the > > > documents and > > > > are fine with it as it is. It is very useful to know how > > > many people > > > > have read the document. > > > > > > > > Thanks, > > > > > > > > Juergen Q. > > > > -- > > > > Juergen Quittek quittek@netlab.nec.de Tel: +49 > > > 6221 4342-115 > > > > NEC Europe Limited, Network Laboratories Fax: +49 > > > 6221 4342-155 > > > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > > > http://www.netlab.nec.de > > > > Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK > > > > Registered in England 2832014 > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 14 11:02:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKxsb-0001nO-Ck; Tue, 14 Aug 2007 11:00:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKxsa-0001nI-RQ for isms@lists.ietf.org; Tue, 14 Aug 2007 11:00:20 -0400 Received: from mail.elbrysnetworks.com ([64.140.243.164] helo=gumby.elbrysnetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IKxsZ-0003qb-Ck for isms@lists.ietf.org; Tue, 14 Aug 2007 11:00:20 -0400 Received: (qmail 5913 invoked from network); 14 Aug 2007 11:00:34 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 14 Aug 2007 11:00:34 -0400 From: "David B. Nelson" To: Date: Tue, 14 Aug 2007 11:00:37 -0400 Organization: Elbrys Networks, Inc. Message-ID: <006b01c7de83$df4bb030$5d1216ac@xpsuperdvd2> 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: AcfegG7VasSLTHGJRty1ameu2f9k/AAAVXGg X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Isms] FW: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization 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 It would be greatly appreciated if any ISMS WG members who think that the RADIUS NAS Management Authorization draft should be taken up as a WG work item in the RADEXT WG would say so on the RADEXT WG mailing list. That draft supports the RADIUS Usage for SNMP draft we are working on here in ISMS. At IETF-69 in Chicago, the sense of the room was that would be the first choice, although we do have other options. The deadline for responding to the RADEXT WG mailing list (radiusext@ops.ietf.org) with a statement of support for taking up the RADIUS NAS Management Authorization draft in the RADEXT WG is this Thursday. > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Bernard Aboba > Sent: Tuesday, August 14, 2007 10:32 AM > To: radiusext@ops.ietf.org > Subject: REMINDER: RADEXT WG review of draft-nelson-radius-management- > authorization > > The WG review request ends on August 16, 2007. So far we have had only > person express interest - not enough to adopt this document as a WG work > item. Please post to the list if you support taking this on as a WG work > item (even if you have no comments to post). > > > >From: "Wijnen, Bert (Bert)" > >To: , > >CC: , "Bernard Aboba" > > > >Subject: RE: [Isms] [bernard_aboba@hotmail.com: Review o > >fdraft-nelson-radius-management-authorization-05.txt] > >Date: Tue, 14 Aug 2007 11:35:43 +0200 > > > >Some nits: > > > >Sect 4 > > > > The local application of the Management-Policy-Id within the managed > > entity may take the form of (a) one of an enumeration of command > > privilege levels, (b) a mapping into an SNMP View Based Access > > Control Method (VACM) table [RFC3415], or (c) some other set of > > > >Did you intend to writhe "Method", or do you mean "Model"? > >VACM stands for View Based Access Control Model in the SNMP context. > > > >Sect 7.3 > > The Text field is one or more octets, and its contents are > > implementation dependent. It is intended to be human readable and > > MUST NOT affect operation of the protocol. It is recommended that > > the message contain UTF-8 encoded 10646 [RFC2279] characters. > > > >The latest RFC for UTF-8 is RFC3629. > >I guess it is better reference that one. > > > >I can support this work item as a topic for the RADEXT WG. > >Not sure how much I can contribute though, but I will try to review > >revisions of the document > > > >Bert Wijnen > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 14 11:29:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyJD-0005Eb-BN; Tue, 14 Aug 2007 11:27:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKyJC-0005EV-Ll for isms@ietf.org; Tue, 14 Aug 2007 11:27:50 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKyJB-0004dF-47 for isms@ietf.org; Tue, 14 Aug 2007 11:27:50 -0400 Received: from pc6 (1Cust211.tnt1.lnd4.gbr.da.uu.net [62.188.130.211]) by ranger.systems.pipex.net (Postfix) with SMTP id D6C33E000619; Tue, 14 Aug 2007 16:27:45 +0100 (BST) Message-ID: <021701c7de7e$7ebcdaa0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'ISMS WG'" References: <037c01c7db3c$9725b520$0601a8c0@pc6> <016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com> <01af01c7dd84$15202c00$0601a8c0@pc6> <000901c7ddd0$79189a20$6702a8c0@china.huawei.com> Subject: Re: [Isms] Working Group Last Call - securityName Date: Tue, 14 Aug 2007 16:18:36 +0200 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: 827a2a57ca7ab0837847220f447e8d56 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 Harrington" To: "'tom.petch'" ; "'ISMS WG'" Sent: Monday, August 13, 2007 7:36 PM Subject: RE: [Isms] Working Group Last Call - securityName > > I need to answer this in two ways. > First, you need to understand the limitations of what we can specify, > and then second, I will try make sure you understand how "mappings" > are handled. > > First, you need to understand that we are not modifying the SSH > standard. We are providing an SNMP-specific interface to secure > transport protocols, and we are not dictating how the implementation > must handle sessions in the transport security protocol (or even > whether the secure transport uses sessions). We specify that when SNMP > says "give me secure transport for , at > this transport address", the implementation needs to determine how to > actually deliver that mapping given the chosen secure transport. There > are multiple SSH implementations, and the SSH WG did not define an API > for us to call to get a particular session. So there is some > background processing that needs to be done, preesumably via some type > of local configuration datastore, that the implementation can use to > get a mapping between the secure transport sessions and credentials > and the SNMP request parameters. The SSH WG decided not to write a MIB > to show conceptually how this transport-specific information is > maintained, and the ISMS WG decided not to write a MIB to show this > SSH-specific information either. > > For the second point, see comments inline > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Monday, August 13, 2007 4:25 AM > > To: David Harrington; 'Juergen Quittek'; 'ISMS WG' > > Subject: Re: [Isms] Working Group Last Call - securityName > > > > Thanks for the info. The issue for me is the selection of > > the session for > > outbound messages. This is based on the model-independent > > securityName (tmsm > > s.3.3) so the transport model must know that and so must also > > know the mapping > > to any transport dependent principal name. > > > > If the first message on a session is inbound, you say that > > the security model > > has the final say in the mapping. > > You may be onto something, but I cannot tell for sure because you use > language loosely. At what step in the Elements of Procedure is > information missing that is needed? Where should that information be > coming from? It would help immensely if you differentiated the > "mapping" you refer to. There are different mappings happening. > > A secure transport model provides a mapping between the identity > authenticated by the transport and the proposed securityName in the > tmStateReference. That mapping is always the responsibility of the > transport model. This mapping happens with every message, even though > the authentication might be done on a transport-session-basis, and > therefore should be the same for every message received within a > transport session. > > A messaging model may provide a field in the message to allow the > sending application to name a proposed securityName for the remote > message-named securityModel. USM does this. It is up to USM to > maintain such a mapping, e.g., via the USM-USER-MIB. This happens with > every message. > > It is the responsibility of the securityModel to decide what inputs it > will consider in making the determination of securityName to be passed > to applications for an incoming message. And this happens for every > message. > > It is the responsibility of the securitymodel to determine which > information needs to be passed to the remote securitymodel for > processing, for outgoing messages. For USM, the USM security model > puts the something in the securityParameters in the SNMPv3 message. > For TSM, it identifies which LCD entry should be used, based on > securityName, securityLevel, and transport address; the LCD should > contain the necessary transport-specific securityName->transport > identity mapping. > David The mapping that I am concerned with is the one used by the secure transport model to select the transport session over which to send the message. My understanding is that, long ago, we achieved consensus that what the secure transport used, a transport identity eg an SSH user name (although this model is not limited to SSH), need not be identical to the securityName as used in eg access control. So there is a mapping and that is what I am unclear about from the I-Ds. And I am concerned at the architectural level, at the division of labour between the security subsystem and the transport subsystem, as defined in the ASIs, so that we have something that can accommodate fresh models. tmsm 3.2.1.2. Transport Subsystem and the RFC3411 Architecture seems clear enough 1) authenticate the principal, check integrity and timeliness of the message, and decrypt the message. [Transport Model] 2) translate parameters to model-independent parameters (Transport Model) and below it says If a message is secured using a secure transport layer, then the Transport Model should provide the translation from the authenticated identity (e.g., an SSH user name) to the securityName in step 3. I assume that that is step 2 and I do understand that you have chosen only a 'should' and not a 'SHOULD' or a 'MUST' But 3.2.2 gets a whole lot vaguer 'A Security Model may have multiple sources for determining the principal and desired security services, and a particular Security Model may or may not utilize the securityName mapping and securityLevel made available by the Transport Model when deciding the value of the securityName and securityLevel to be passed to the Message Processing Model.' So I used to understand that the transport model generates the securityName that will be used in access control. But your previous e-mail said that the security model had the last word on the mapping and this e-mail talks of proposed securityName so it seems you have two mappings in mind, between securityName used in access control and securityName proposed by transport and between securityName proposed by transport and transport identity. I think that the mapping matters because when a session-oriented secure transport model is passed an outbound message, it has no transport selector and uses securityName, securityLevel, and transport address to select a session; get the wrong session and you have undermined security. I see a need for the mapping(s) to be in place and current for the secure transport model to select the right session for an outbound message lest security be undermined. But look at 3.3.3 'A Transport Model session will have a single transportDomain, transportAddress, securityName and securityLevel associated with it.' ' For Transport Models, securityName should be specified during session setup, and associated with the session identifier.' Note that this says 'session setup' not 'when the first inbound message is processed by the security model'; although again, it is only a 'should'. Or 6.3. 'If one does not exist, the Transport Model might create a cache referenced by tmStateReference. If present, this information might include transportDomain, transportAddress, securityLevel, and securityName, plus model or mechanism-specific details.' This all seems inconsistent with the transport model proposing a securityName and the security model deciding on a different one as you now describe. I have no problem with that being the architecture, it is just that tmsm (and other I-Ds) seem inconsistent about this point. Overall, I cannot assign one meaning to 'securityName' and make sense of the document. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 14 14:06:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0lR-0005SK-Fa; Tue, 14 Aug 2007 14:05:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL0lQ-0005SF-Ql for isms@ietf.org; Tue, 14 Aug 2007 14:05:08 -0400 Received: from mail.elbrysnetworks.com ([64.140.243.164] helo=gumby.elbrysnetworks.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IL0lQ-0005a0-9a for isms@ietf.org; Tue, 14 Aug 2007 14:05:08 -0400 Received: (qmail 8874 invoked from network); 14 Aug 2007 14:05:26 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 14 Aug 2007 14:05:26 -0400 From: "David B. Nelson" To: "'ISMS WG'" References: <037c01c7db3c$9725b520$0601a8c0@pc6><016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com><01af01c7dd84$15202c00$0601a8c0@pc6><000901c7ddd0$79189a20$6702a8c0@china.huawei.com> <021701c7de7e$7ebcdaa0$0601a8c0@pc6> Subject: RE: [Isms] Working Group Last Call - securityName Date: Tue, 14 Aug 2007 14:05:25 -0400 Organization: Elbrys Networks, Inc. Message-ID: <009301c7de9d$b04e4620$5d1216ac@xpsuperdvd2> 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: Acfeh7kN3r/czPFaRSy1A6+Uaunf9wAFBLLA In-Reply-To: <021701c7de7e$7ebcdaa0$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Tom Petch writes... > This all seems inconsistent with the transport model proposing a > securityName and the security model deciding on a different one > as you now describe. Perhaps my understanding of what function securityName serves in the SNMP architecture is fuzzy, so please correct me as required. It would seem to be a model-independent name that various models can use to identify the principal, and perform functions such as finding the right encryption and decryption keys or assigning the right access control rights. Was it originally envisioned in the SNMP architecture that different models (i.e. different subsystem instantiations) would hold a different view of this object for the same SNMP "transaction"? If the intent was to have a consistent, but model-independent name, that would make a lot of sense. I, too, have some unease about the notion of an inconsistent name. If names are used inconsistently, it seems that all sorts of security problems are possible. > Overall, I cannot assign one meaning to 'securityName' and make sense > of the document. Do we in fact have one meaning? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 15 07:39:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILHC9-0001eX-La; Wed, 15 Aug 2007 07:37:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILHC8-0001eS-HK for isms@ietf.org; Wed, 15 Aug 2007 07:37:48 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILHC7-0002FB-5V for isms@ietf.org; Wed, 15 Aug 2007 07:37:48 -0400 Received: from pc6 (1Cust196.tnt2.lnd4.gbr.da.uu.net [62.188.131.196]) by ranger.systems.pipex.net (Postfix) with SMTP id CFF55E000251; Wed, 15 Aug 2007 12:37:43 +0100 (BST) Message-ID: <01e301c7df27$86830300$0601a8c0@pc6> From: "tom.petch" To: "Juergen Quittek" , "ISMS WG" References: <037d01c7db3c$97ffe880$0601a8c0@pc6> Subject: Re: [Isms] Working Group Last Call - securityLevel changes Date: Wed, 15 Aug 2007 10:58:16 +0200 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: cf4fa59384e76e63313391b70cd0dd25 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 There is another related issue on security level, best raised sooner rather than later, namely that a secure transport can renegotiate the Cipher Spec so a secure transport can go from authentication and privacy to authentication only and vice versa, without changing its session identifier. If the secure transport updates the information in the cache referenced by tmStateReference when this happens, as the I-D suggests, and at this time, there is still a message being processed by the security model, then the security model could extract the wrong information from the cache so a message received with authentication and privacy could be discarded because the secure transport is now authentication only, or an invalid message could be let through because the message arrived with authentication only and only later was the secure transport upgraded to authentication and privacy.. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 15 08:54:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILIMV-0008Fy-Ri; Wed, 15 Aug 2007 08:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILIMU-0008Ft-OI for isms@ietf.org; Wed, 15 Aug 2007 08:52:34 -0400 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILIMT-0003t7-H2 for isms@ietf.org; Wed, 15 Aug 2007 08:52:34 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc16) with SMTP id <20070815125232b1600qjmule>; Wed, 15 Aug 2007 12:52:32 +0000 From: "David Harrington" To: "'tom.petch'" , "'ISMS WG'" References: <037d01c7db3c$97ffe880$0601a8c0@pc6> <01e301c7df27$86830300$0601a8c0@pc6> Subject: RE: [Isms] Working Group Last Call - securityLevel changes Date: Wed, 15 Aug 2007 08:52:27 -0400 Message-ID: <017201c7df3b$22b796b0$6702a8c0@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: <01e301c7df27$86830300$0601a8c0@pc6> Thread-Index: AcffMPQYHV9YmlXMQ763AakdiliMcgACZGrw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 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 We don't have control over how the SSH is configured. IIRC, We specify that operators are expected to ensure it is configured for auth and priv. If they don't, there isn't much we can do about it. We also tell them not to configure noAuth, but they can and we cannot do anything about it. The SSH standard does not give us any way to check. I'll make note to double-check our wording. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Wednesday, August 15, 2007 4:58 AM > To: Juergen Quittek; ISMS WG > Subject: Re: [Isms] Working Group Last Call - securityLevel changes > > There is another related issue on security level, best raised > sooner rather than > later, namely that a secure transport can renegotiate the > Cipher Spec so a > secure transport can go from authentication and privacy to > authentication only > and vice versa, without changing its session identifier. > > If the secure transport updates the information in the cache > referenced by > tmStateReference when this happens, as the I-D suggests, and > at this time, there > is still a message being processed by the security model, > then the security > model could extract the wrong information from the cache so a > message received > with authentication and privacy could be discarded because > the secure transport > is now authentication only, or an invalid message could be > let through because > the message arrived with authentication only and only later > was the secure > transport upgraded to authentication and privacy.. > > 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 Aug 17 11:05:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3Mj-0000sz-Ll; Fri, 17 Aug 2007 11:03:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3Mi-0000oz-NZ for isms@ietf.org; Fri, 17 Aug 2007 11:03:56 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM3Mh-0006ZT-G0 for isms@ietf.org; Fri, 17 Aug 2007 11:03:56 -0400 Received: from pc6 (1Cust137.tnt24.lnd4.gbr.da.uu.net [62.188.151.137]) by blaster.systems.pipex.net (Postfix) with SMTP id 5B216E000625; Fri, 17 Aug 2007 16:03:54 +0100 (BST) Message-ID: <042e01c7e0d6$a60950c0$0601a8c0@pc6> From: "tom.petch" To: "David Harrington" , "'ISMS WG'" References: =?iso-8859-1?Q?=3CC2C3DF09.D53B%Quittek@netlab.nec.de=3E=3C037d01c7db3c$9?= =?iso-8859-1?Q?7ffe880$0601a8c0@pc6=3E_=3C01e301c7df27$86830300$0=E0=1D?= =?iso-8859-1?Q?=04_=3C017201c7df3b$22b796b0$6702a8c0@china.huawei.com=3E?= Subject: Re: [Isms] Working Group Last Call - securityLevel changes Date: Fri, 17 Aug 2007 15:57:28 +0200 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: b19722fc8d3865b147c75ae2495625f2 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 Harrington" To: "'tom.petch'" ; "'ISMS WG'" Sent: Wednesday, August 15, 2007 2:52 PM Subject: RE: [Isms] Working Group Last Call - securityLevel changes > We don't have control over how the SSH is configured. IIRC, We specify > that operators are expected to ensure it is configured for auth and > priv. If they don't, there isn't much we can do about it. We also tell > them not to configure noAuth, but they can and we cannot do anything > about it. The SSH standard does not give us any way to check. > > I'll make note to double-check our wording. > The wording in 'draft-ietf-isms-secshell-08' is fine, namely, "While SSH does support turning off confidentiality and integrity, they SHOULD NOT be turned off when used with the SSH Transport Model." (although MUST NOT might be better) What I am saying is that this capability is widely present in secure transports; with the way in which the cache is used, it creates a security loophole in the architecture and so should be flagged as such in tmsm. > > dbh > > -----Original Message----- _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 20 04:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2Tr-0006UX-Hp; Mon, 20 Aug 2007 04:19:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2Tp-0006KD-OT for isms@ietf.org; Mon, 20 Aug 2007 04:19:21 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN2To-0005tj-9E for isms@ietf.org; Mon, 20 Aug 2007 04:19:21 -0400 Received: from pc6 (1Cust129.tnt106.lnd4.gbr.da.uu.net [213.116.60.129]) by ranger.systems.pipex.net (Postfix) with SMTP id 96A79E000857; Mon, 20 Aug 2007 09:19:16 +0100 (BST) Message-ID: <001501c7e2f9$9dbd2020$0601a8c0@pc6> From: "tom.petch" To: "tom.petch" , "David Harrington" , "'ISMS WG'" References: =?iso-8859-1?Q?=3CC2C3DF09.D53B%Quittek@netlab.nec.de=3E=3C037d01c7db3c$9?= =?iso-8859-1?Q?7ffe880$0601a8c0@pc6=3E_=3C01e301c7df27$86830300$0=E0=1D?= =?iso-8859-1?Q?=04_=3C017201c7df3b$22b796b0$6702a8c0@china.huawei.com?= =?iso-8859-1?Q?=3E_=3C042e01c7e0d6$a60950c0$0601a8c0@pc6=3E?= Subject: Re: [Isms] Working Group Last Call - securityLevel changes Date: Mon, 20 Aug 2007 09:05:28 +0200 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: 82c9bddb247d9ba4471160a9a865a5f3 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: "tom.petch" To: "David Harrington" ; "'ISMS WG'" Sent: Friday, August 17, 2007 3:57 PM Subject: Re: [Isms] Working Group Last Call - securityLevel changes > ----- Original Message ----- > From: "David Harrington" > To: "'tom.petch'" ; "'ISMS WG'" > Sent: Wednesday, August 15, 2007 2:52 PM > Subject: RE: [Isms] Working Group Last Call - securityLevel changes > > > > We don't have control over how the SSH is configured. IIRC, We specify > > that operators are expected to ensure it is configured for auth and > > priv. If they don't, there isn't much we can do about it. We also tell > > them not to configure noAuth, but they can and we cannot do anything > > about it. The SSH standard does not give us any way to check. > > > > I'll make note to double-check our wording. > > > > The wording in 'draft-ietf-isms-secshell-08' is fine, namely, > > "While SSH does support turning off confidentiality and integrity, they SHOULD > NOT be turned off when used with the SSH Transport Model." > > (although MUST NOT might be better) > > What I am saying is that this capability is widely present in secure transports; > with the way in which the cache is used, > it creates a security loophole in the architecture and so should be flagged as > such in tmsm. > Just to be more specific, I am suggesting adding wording to tmsm, either what we have in secshell, that security level of the transport SHOULD NOT be changed, or, if that is too restrictive in the architecture, as opposed to a model, then a warning that a change in security level could lead to a security exposure since the security subsystem may not have access to information relevant to the message it is processing. Tom Petch > > > > dbh > > > -----Original Message----- > > > > _______________________________________________ > 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 Tue Aug 21 01:24:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INMC1-0004xU-AB; Tue, 21 Aug 2007 01:22:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INMC0-0004xH-22 for isms@ietf.org; Tue, 21 Aug 2007 01:22:16 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INMBy-0004ET-Og for isms@ietf.org; Tue, 21 Aug 2007 01:22:15 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 20 Aug 2007 22:22:14 -0700 X-IronPort-AV: i="4.19,287,1183359600"; d="scan'208"; a="203557259:sNHT44877015" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l7L5MEBv016299 for ; Mon, 20 Aug 2007 22:22:14 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l7L5MEgB006524 for ; Tue, 21 Aug 2007 05:22:14 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 22:22:13 -0700 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 Date: Mon, 20 Aug 2007 22:22:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More questions on Security name Thread-Index: Acfjsz0k5y18ve4xSVKYzIztTb71Eg== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 21 Aug 2007 05:22:13.0826 (UTC) FILETIME=[3B61BA20:01C7E3B3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1637; t=1187673734; x=1188537734; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20More=20questions=20on=20Security=20name |Sender:=20; bh=jK66ZbJesmw8MrBLIg/C2l67us0Ora6HwrDT886bEL8=; b=rEXVYUWC7/B/LyCaqIGAWR0fmL1m3P2RbXBLfWrhfxHwc7g72ZH3YWlX1sqwxQdOAwisBmY2 QkinvHnS7VrQYo0+9kGsbxNtCv+sEZDidN+q82aLAfrpyF5fDIJL7sfr; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Isms] More questions on Security name 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've been reviewing the working group documents and I am not quite sure how security name is/should used. In USM it appears that there is a single SecurityName representing both sides of a conversation, is this true and is this true of SNMPv3 in general. =20 I'm still a bit confused as to where an why SecurityName is used in various cases. Is the following accurate? A securityName is used in authorization on a command process to make sure that the command generator is authorized (security name applies to command generator). A security name may be used on a notification generator to determine if the notification receiver is authorized to receive a message (security name applies to notification receiver).=20 In SSH, generally there is more than one entity identity involved. One entity is identified by a SSH user authentication (username) and another is identified by SSH server authentication (IP address/domain name). =20 Some of the difficulty around securityName may originate from this. We may need to split up securityName into two pieces, but this seems like it would have some impact on SNMP, although maybe it would always be clear which name is used in particular case. Another option (well really it probably maps to the same thing) is to treat the mutual authentication as a single securityName such as something like joeuser@snmpssh.example.com. This seems like it would affect how authorization is set up in VACM.=20 If other people are as confused as me then perhaps we need to have a section in the document that describes the interaction with authorization.=20 Joe _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 21 02:55:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INNcN-0002U6-Nj; Tue, 21 Aug 2007 02:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INNcM-0002OP-BF for isms@ietf.org; Tue, 21 Aug 2007 02:53:34 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INNcL-0006Fj-21 for isms@ietf.org; Tue, 21 Aug 2007 02:53:34 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7L6qRDM015620; Tue, 21 Aug 2007 01:53:22 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 01:53:03 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 08:53:00 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Isms] More questions on Security name Date: Tue, 21 Aug 2007 08:52:56 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] More questions on Security name Thread-Index: Acfjsz0k5y18ve4xSVKYzIztTb71EgACmncw References: From: "Wijnen, Bert \(Bert\)" To: "Joseph Salowey \(jsalowey\)" , X-OriginalArrivalTime: 21 Aug 2007 06:53:00.0668 (UTC) FILETIME=[E9F3DBC0:01C7E3BF] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Bert Wijnen =20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 > Sent: Tuesday, August 21, 2007 7:22 AM > To: isms@ietf.org > Subject: [Isms] More questions on Security name >=20 > I've been reviewing the working group documents and I am not=20 > quite sure how security name is/should used. >=20 > In USM it appears that there is a single SecurityName=20 > representing both sides of a conversation, is this true and=20 > is this true of SNMPv3 in general. =20 >=20 Yes. But... there is an authoritative side on each conversation. The agent is the authoritative side of the communication for all PPU exchanges except for the INFORM, where the manager is the authoritative side. The importance of the authoritative side is that the shared USM username/password is the one the the=20 authoritative side knows about. Inside the message, the user is represented by msgUserName in UsmSecurityParameters (see RFC3414,=20 sect 2.4) > I'm still a bit confused as to where an why SecurityName is=20 > used in various cases. Is the following accurate? >=20 > A securityName is used in authorization on a command process=20 > to make sure that the command generator is authorized=20 > (security name applies to command generator). Yep. Although I would word it different. The securityName gets mapped into a groupName, and the groupName=20 (together with securityLevel and securityModel) determins (via the VACM tables) of the command generator has access to the object-instances it is trying to access. > A security=20 > name may be used on a notification generator to determine if=20 > the notification receiver is authorized to receive a message=20 > (security name applies to notification receiver).=20 >=20 Nope. The securityName gets mapped into a groupName and together with securityLevel and securityModel, the VACM tables control if=20 all the object-instances included in the notifications can indeed be accessed and if so they will be sent as varBinds in the notification. On the receiving end there is no "access control". > In SSH, generally there is more than one entity identity=20 > involved. One entity is identified by a SSH user=20 > authentication (username) and another is identified by SSH=20 > server authentication (IP address/domain name). =20 >=20 The userName (in the msgUserName in the UsmSecurityParameters, see RFC3414 sect 2.4) gets translated into securtyName (1 to 1,=20 identity function) and then gets used to do the authentication, and privacy en/decription) Specifically, here it is important to know about the authoritative side. As stated above, normally it is the agent, but for INFORM PDUs it is the notofication receiver (running at the manager). > Some of the difficulty around securityName may originate from=20 > this. We may need to split up securityName into two pieces,=20 > but this seems like it would have some impact on SNMP,=20 > although maybe it would always be clear which name is used in=20 > particular case. =20 In SNMP with USM, you basically only have one side that is=20 authoritative (in each communication, that is per exchange of a SNMP PDU pair (request/response), based on a shared=20 msgUserName secret. In case of a TRAPv2-PDU there is just one-way, so no response. I am leaving the REPORT PDUs out of the discussion for now. I think such is OK. > Another option (well really it probably=20 > maps to the same thing) is to treat the mutual authentication=20 > as a single securityName such as something like=20 > joeuser@snmpssh.example.com. This seems like it would affect=20 > how authorization is set up in VACM.=20 >=20 I believe that USM uses the msgUserName/password indeed as a mutual authentication (see description above and let me know if you agree). > If other people are as confused as me then perhaps we need to=20 > have a section in the document that describes the interaction=20 > with authorization.=20 >=20 Hope my comments helped. Bert > Joe >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 21 07:41:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INS52-0002Op-MG; Tue, 21 Aug 2007 07:39:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INS51-0002Oj-G9 for isms@ietf.org; Tue, 21 Aug 2007 07:39:27 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INS50-0002QL-SN for isms@ietf.org; Tue, 21 Aug 2007 07:39:27 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc12) with SMTP id <2007082111392601200dqr73e>; Tue, 21 Aug 2007 11:39:26 +0000 From: "David Harrington" To: "'Joseph Salowey \(jsalowey\)'" , References: Subject: RE: [Isms] More questions on Security name Date: Tue, 21 Aug 2007 07:39:13 -0400 Message-ID: <005201c7e3e7$e5d2b390$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acfjsz0k5y18ve4xSVKYzIztTb71EgAKjUCg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 RFC3411: 3.2.1. Principal A principal is the "who" on whose behalf services are provided or processing takes place. A principal can be, among other things, an individual acting in a particular role; a set of individuals, with each acting in a particular role; an application or a set of applications; and combinations thereof. 3.2.2. securityName A securityName is a human readable string representing a principal. It has a model-independent format, and can be used outside a particular Security Model. >From "Secure Shell Transport Model for SNMP": 4. Verification of principal identity is important for use with the SNMP access control subsystem, to ensure that only authorized principals have access to potentially sensitive data. The SSH user identity will be used to map to an SNMP model-independent securityName for use with SNMP access control. more inline. > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Tuesday, August 21, 2007 1:22 AM > To: isms@ietf.org > Subject: [Isms] More questions on Security name > > I've been reviewing the working group documents and I am not > quite sure > how security name is/should used. > > In USM it appears that there is a single SecurityName > representing both > sides of a conversation, is this true and is this true of SNMPv3 in > general. > > I'm still a bit confused as to where an why SecurityName is used in > various cases. Is the following accurate? > > A securityName is used in authorization on a command process to make > sure that the command generator is authorized (security name > applies to > command generator). A security name may be used on a notification > generator to determine if the notification receiver is authorized to > receive a message (security name applies to notification receiver). A securityName represents an authenticated principal on whose behalf work is done. For SSH-TM, securityName represents the SSH-USER authenticated during user-auth. For USM, securityName represents the usmUser authenticated using USM authentication The command generator, command responder, notification originator, and notification receiver are "applications" that do work on behalf of an authenticated principal. The operation might be to read the data, to write the data, or to send the data in a notification. Authorization is checked by command responders and notification originators. When a request is being processed, the responder or originator checks whether the authenticated principal is permitted to have that command performed on its behalf and whether they are permitted to perform the operation to the specified subset of data. > > In SSH, generally there is more than one entity identity > involved. One > entity is identified by a SSH user authentication (username) > and another > is identified by SSH server authentication (IP address/domain name). Mutual authentication is required by the SSH transport model. For the SSH transport model, securityName represents the authenticated user, never the server. In SNMP authorization, we always check whether the user is authorized to access the data in the MIB database. > > Some of the difficulty around securityName may originate from > this. We > may need to split up securityName into two pieces, but this seems like > it would have some impact on SNMP, although maybe it would always be > clear which name is used in particular case. Another option (well > really it probably maps to the same thing) is to treat the mutual > authentication as a single securityName such as something like > joeuser@snmpssh.example.com. This seems like it would affect how > authorization is set up in VACM. > > If other people are as confused as me then perhaps we need to have a > section in the document that describes the interaction with > authorization. > > Joe > > _______________________________________________ > 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 Aug 22 17:52:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INy5o-0000oX-1r; Wed, 22 Aug 2007 17:50:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INy5m-0000oP-T5 for isms@ietf.org; Wed, 22 Aug 2007 17:50:22 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INy5m-0002bq-5h for isms@ietf.org; Wed, 22 Aug 2007 17:50:22 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l7MLo1C3025142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 17:50:06 -0400 (EDT) Date: Wed, 22 Aug 2007 17:50:01 -0400 From: Jeffrey Hutzelman To: "tom.petch" , David Harrington , "'ISMS WG'" Subject: Re: [Isms] Working Group Last Call - securityName Message-ID: <59165B4D35F9378674A70368@sirius.fac.cs.cmu.edu> In-Reply-To: <021701c7de7e$7ebcdaa0$0601a8c0@pc6> References: <037c01c7db3c$9725b520$0601a8c0@pc6> <016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com> <01af01c7dd84$15202c00$0601a8c0@pc6> <000901c7ddd0$79189a20$6702a8c0@china.huawei.com> <021701c7de7e$7ebcdaa0$0601a8c0@pc6> Originator-Info: login-token=Mulberry:01Oymp/aWRHnGHdCF+bqfZbNKb4CjCXSKontdicak=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: 093efd19b5f651b2707595638f6c4003 Cc: Jeffrey Hutzelman 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, August 14, 2007 04:18:36 PM +0200 "tom.petch" wrote: > tmsm 3.2.1.2. Transport Subsystem and the RFC3411 Architecture > > seems clear enough > > 1) authenticate the principal, check integrity and timeliness of the > message, and decrypt the message. [Transport Model] > 2) translate parameters to model-independent parameters (Transport > Model) > > and below it says > > If a message is secured using a secure transport layer, then the > Transport Model should provide the translation from the authenticated > identity (e.g., an SSH user name) to the securityName in step 3. > But 3.2.2 gets a whole lot vaguer > > 'A Security Model may have multiple > sources for determining the principal and desired security services, > and a particular Security Model may or may not utilize the > securityName mapping and securityLevel made available by the > Transport Model when deciding the value of the securityName and > securityLevel to be passed to the Message Processing Model.' That's not vague at all; it means exactly what it says. The secure transport model proposes a securityName and securityLevel based on the properties of the secure transport. The security model, which sits at a conceptually higher layer in the stack, is free to use that information or ignore it. If you use the SSH transport model, then it is going to derive a securityName from the authenticated SSH username (we've mostly agreed that this derivation is in fact the identity mapping, though it doesn't have to be). If you also use the transport security model, then it is going to go ahead and use the securityName provided by SSH, and that becomes the name used for access control. If you use SSH but use USM as your security model, then USM is going to ignore the securityName provided by SSH, and instead use the one contained in the SNMPv3 message. It's also going to get the securityLevel from the SNMPv3 message, and verify the message using the appropriate USM keys and so on. In other words, USM-over-SSH gives you exactly the same security parameters as USM-over-UDP. > So I used to understand that the transport model generates the > securityName that will be used in access control. If you use TSM, that is effectively true, because TSM is defined to use the securityName proposed by the transport model. If you use some other security model, it generally not be true, because the other security models will use different ways of deciding what name to use. > I think that the mapping matters because when a session-oriented secure > transport model is passed an outbound message, it has no transport > selector and uses securityName, securityLevel, and transport address to > select a session; get the wrong session and you have undermined security. Ah, I see what you're getting at, but I don't think there's a problem. For an incoming message, there are multiple potential sources of security information. One is the transport model, another is the security parameters in the SNMPv3 message, and still another is any private source of information available to the security model (for example, if you had a security model that used public key signatures with certificates, then the sender's certificate might have security name information). Someone has to decide which of these sources of information is used to determine the parameters seen by access control and the application, and architecturally, that someone is the security model. The securityName proposed by the secure transport model is intended to be in the same namespace as the one eventually selected by the securityModel, so if the security model chooses to use that information, it will generally do so by copying. For an outbound message, there is no decision to be made -- the securityName came from the application, and while there might be multiple consumers of that information (the security model, the SNMPv3 message security parameters, and the secure transport model), they all consume the same value, which is the one provided by the application. The issue I think you're driving at is selection of the proper session for an outbound message. The correct handling of this depends on whether the message is a response or not. If the message is a response, then the correct session (assuming the transport is session-oriented) is the session on which arrived the incoming message to which the present message is a response. The way this works is that on an incoming message, the transport model places into the tmStateRef enough information to find the session used, and this information is passed back to it along with the outgoing reply. The session to be used for the reply is located based on this cached data, not the securityName/securityLevel/transport address. For an outgoing message which is not a response, the correct session is one for the specified securityName, securityLevel, and transport address. There is no ambiguity or chance of choosing the "wrong" session, because there is only one securityName inolved, that being the one specified by the application. > I see a need for the mapping(s) to be in place and current for the > secure transport model to select the right session for an outbound > message lest security be undermined. On an incoming message, there certainly is a mapping from the name proposed by the transport model to the one eventually given to the application. However, that mapping is not necessarily reversible -- the security model may choose to ignore the name proposed by the transport model and instead use one from another source; in this case all names proposed by the transport model would map to the same value, namely, the value given by the other source. However, this is not a problem because for a message that is a response, the securityName need not be used to identify the session to be used. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 22 18:04:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyHQ-0006EX-M6; Wed, 22 Aug 2007 18:02:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyHP-0006EP-SU for isms@ietf.org; Wed, 22 Aug 2007 18:02:23 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INyHO-0004KL-L0 for isms@ietf.org; Wed, 22 Aug 2007 18:02:23 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l7MM2HlB025151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 18:02:18 -0400 (EDT) Date: Wed, 22 Aug 2007 18:02:17 -0400 From: Jeffrey Hutzelman To: David Harrington , "'tom.petch'" , "'ISMS WG'" Subject: RE: [Isms] Working Group Last Call - securityLevel changes Message-ID: <4592FB83A7469198D9CCF1F3@sirius.fac.cs.cmu.edu> In-Reply-To: <017201c7df3b$22b796b0$6702a8c0@china.huawei.com> References: <037d01c7db3c$97ffe880$0601a8c0@pc6> <01e301c7df27$86830300$0601a8c0@pc6> <017201c7df3b$22b796b0$6702a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01Wp/0isQHaf6m6mwLjR0k+fERK7Xh023HFCLvkB8=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: 8b30eb7682a596edff707698f4a80f7d Cc: Jeffrey Hutzelman 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, August 15, 2007 08:52:27 AM -0400 David Harrington wrote: > We don't have control over how the SSH is configured. IIRC, We specify > that operators are expected to ensure it is configured for auth and > priv. If they don't, there isn't much we can do about it. We also tell > them not to configure noAuth, but they can and we cannot do anything > about it. The SSH standard does not give us any way to check. The SSH standard does not give you any way to check because any interface between SSH and applications built on top of it is application-specific and out of the scope of the SSH standard. You could certainly impoose requirements on the algorithms in use, and require that implemtnations check that those requirements are met. A compliant SSH-TM implementation would then have to use an SSH implementation that provides a suitable interface. However, I would not recommend doing so, for several reasons. First, the reality is that most SSH implementations do not provide a rich enough interface for this, and so SNMP implementors would be forced to choose between ignoring this requirement or modifying their SSH implementation to allow them to meet it. Second, SSH algorithms don't have properites you can check for this, because SSH doesn't need them. SSH always provides an encrypted, integrity-protected channel; the question is how good the encryption and integrity protection are. Obviously, "null" algorithms exist which go through the motions but don't actually provide any protection. There are also algorithms which attempt to provide protection but are no longer strong enough. And there is no sharp line between these. So, since SSH always provides encryption and integrity protection unless you do something stupid, the securityLevel associated with an SSH session always indicates both properties. If you've configured SSH to use the null encryption algorithm, you still have encryption; it's just really bad. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 22 18:08:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyLx-0001k5-Bz; Wed, 22 Aug 2007 18:07:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyLw-0001k0-0Z for isms@ietf.org; Wed, 22 Aug 2007 18:07:04 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INyLv-0002pe-Jf for isms@ietf.org; Wed, 22 Aug 2007 18:07:03 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l7MM6thM025154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 18:07:00 -0400 (EDT) Date: Wed, 22 Aug 2007 18:06:55 -0400 From: Jeffrey Hutzelman To: "Wijnen, Bert (Bert)" , j.schoenwaelder@jacobs-university.de, David Harrington Subject: Re: [Isms] tmStateReference in draft-ietf-isms-tmsm-09.txt Message-ID: <44AB066FC5148F45AE2DB05F@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01fhTxx+h8ZjvKX2lIsZIhNhWGKPIFSGrriR8stJQ=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: isms@ietf.org, Jeffrey Hutzelman 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, August 08, 2007 12:17:56 PM +0200 "Wijnen, Bert (Bert)" wrote: > > I am confused by the last 2 paragraphs in sect 6.2 > > The prepareOutgoingMessage ASI passes tmStateReference from the > Message Processing Subsystem to the dispatcher. How or if the > Message Processing Subsystem modifies or utilizes the contents of the > cache is message-processing-model-specific. > > This may sound underspecified, but keep in mind that a message > processing model might have access to all the information from the > cache and from the message, and have no need to call a Security Model > to do any processing; an application might choose a Security Model > such as USM to authenticate and secure the SNMP message, but also > utilize a secure transport such as that provided by the SSH Transport > Model to send the message to its destination. > > specifically the wording "an application...". > Applications in our RFC3411 context are CG or CR or NO or NR or such. > I am sure that is not intended here. But then, what is an "application" > in this sentence above? Why not? Is it not these applications which specify a security model/name/level and transport domain and address? If an application selects USM security parameters and an SSH transport address, it has effectively chosen the use of USM and SSH. > I am also not sure we should speak about the MPM to "not call a > security model". From our architectural point of view, the MPM > will ALWAYS call a security model. If an implementation does a > shortcut, that is up to them... but should we discuss that here? I agree. Even if a new MPM were defined in the future, to specify situations when using that MPM in which the security model is not called would seem to violate the architecture. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 22 18:29:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyfd-0004i5-7T; Wed, 22 Aug 2007 18:27:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyfb-0004hw-K8 for isms@ietf.org; Wed, 22 Aug 2007 18:27:23 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INyfb-0003lj-3l for isms@ietf.org; Wed, 22 Aug 2007 18:27:23 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l7MMMFOd025157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 18:22:15 -0400 (EDT) Date: Wed, 22 Aug 2007 18:22:15 -0400 From: Jeffrey Hutzelman To: "Wijnen, Bert (Bert)" , David Harrington , jsalowey@cisco.com Subject: Re: [Isms] my review of: draft-ietf-isms-secshell-08.txt Message-ID: <539D70CF464B36159F3434D8@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01DQAduHdokixZS5U5QH5NJ6RyVOOUNJZ6dUsdQ4A=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: b4a0a5f5992e2a4954405484e7717d8c Cc: isms@ietf.org, Jeffrey Hutzelman 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 Thursday, August 09, 2007 12:17:13 PM +0200 "Wijnen, Bert (Bert)" wrote: > - sect 5.1 and 5.1 > I assume that SSH_MSG_USERAUTH_REQUEST and SSH_MSG_CHANNEL_DATA > are specified somewhere in the SSH RFC(s)? Maybe a citation to > such RFC(s) is useful at these points. Yes; those are SSH protocol messages. It's actually not clear that SSH messages should be referenced explicitly here; instead, we should be talking about SSH at a rather higher layer. For example, SSH user authentication can be a fairly complex negotiation; it doesn't involve sending just one message. Similarly, outside the SSH protocol channels are presented as streams, not sequences of SSH_MSG_CHANNEL_DATA messages, and in particular you can't assume that your messages will be sent in a single channel data message or infer the size of an incoming message from the underlying SSH protocol messages. Similarly, if you are establishing a separate SSH connection for every session, you don't need data from the SSH channel open/confirmation messages, and in fact generally such data will not be available to you as it is buried in the details of the SSH protocol. If you are establishing multiple channels over the same SSH session, then you may need to know which channel is which, but this is almost certainly done using identifiers provided to you by your SSH implementation (perhaps even file descriptors) and not necessarily using SSH protocol data. > - For SnmpSSHAddress ::= TEXTUAL-CONVENTION I read: > > "Represents either a hostname encoded in ASCII > using the IDNA protocol, as specified in RFC3490, followed by > a colon ':' (ASCII character 0x3A) and a decimal port number > in ASCII, or an IP address followed by a colon ':' > (ASCII character 0x3A) and a decimal port number in ASCII. > The name SHOULD be fully qualified whenever possible. > > I am not well versed/experienced in IDNA. But is IDNA a protocol? That is a semantic question, which I'd just as soon not argue here. Perhaps we could say "as specified by IDNA [RFC3490]" ? > The title of 3490 reads > Internationalizing Domain Names in Applications (IDNA) > And are we indeed speaking of a hostname, or of a domain name, or > of both? I can't quickly determine that. So I wonder if/hope that > we can be clearer here. We are talking about a hostname, but hostnames are domain names (however, not all domain names are valid hostnames). > I also assume (although this is not explicitly stated) that if we > speak about an IP address, that it is a dotted decimal for > IPv4 and and a colon separated IPv6 address in ASCII? Yes/no? In fact, I think we are in trouble if, for an IPv6 address, we don't mean a colon-separated address with brackets around it. Otherwise it may become rather difficult to determine where the port starts, or if it is present! -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 22 18:36:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INymu-0005bX-PY; Wed, 22 Aug 2007 18:34:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INymu-0005aN-2C for isms@ietf.org; Wed, 22 Aug 2007 18:34:56 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INymt-0003up-JN for isms@ietf.org; Wed, 22 Aug 2007 18:34:55 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l7MMYlni025160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 18:34:47 -0400 (EDT) Date: Wed, 22 Aug 2007 18:34:47 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Romascanu, Dan (Dan)'" , isms@ietf.org Subject: RE: [Isms] WGLC comments -draft-ietf-isms-transport-security-model-05.txt Message-ID: <16BAB8C5336F57F7054CDF7E@sirius.fac.cs.cmu.edu> In-Reply-To: <00b601c7da8d$98e7a3f0$6702a8c0@china.huawei.com> References: <00b601c7da8d$98e7a3f0$6702a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01WiLHNsSKPKqmbT+3jaD3pfGU/mHhVkDHl/WbkKI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: Jeffrey Hutzelman 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 Thursday, August 09, 2007 10:00:08 AM -0400 David Harrington wrote: > The issue was raised during WGLC that there is a difference between > our use of the word authenticate and the glossary in RFC2828. I think > re-defining the English words will not help the IETF write clear and > unambiguous specifications. Neither will misusing a term of art. The reality is that _every_ technical field (and here I mean "technical" in the broadest sense) has its own jargon and "terms of art" which do not always have the same meaning they do in the mainstream. In security, "authenticate" is one of these terms; the narrower scope described by RFC2828 is the meaning commonly used in the security community and it is SNMP that is unusual here. That said, I agree that for these documents, consistency with other SNMP specifications is generally more important than consistency with terms used in the security community, where the two conflict. However, where there is _not_ a conflict, consistency with security usage is preferable to taking a term which has well-established meaning in that community, using it in a security document in a way which is not consistent with that meaning, and asserting that it is OK not to call out the difference because your meaning is the "mainstream English" meaning. > I think it would be a bad idea to require or even claim consistency > with RFC2828(bis), because it will be tremendously hard to verify that > every word or phrase covered in RFC2828(bis) is used correctly in the > document. It is already hard to verify that MUST/SHOULD/MAY are used > correctly, and RFC2828bis has 300 pages of definitions. Certainly. There is no such requirement, and I don't believe there is general interest within the IETF security community in introducing such a requirement. RFC2828 and its successor attempt to document terms readers find, and to encourage writers to be consistent with common usage (where "common" means within the security community, not the world at large). However, it is not an internet standard, and while the recent document received extensive review and input from members of the security directorate, it reflects the decisions made by its author and _not_ a consensus of the IETF security area. People who want to know more on the state of this might ask the Security Area Directors for more information or clarification. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 22 18:39:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyq2-0005qt-Hj; Wed, 22 Aug 2007 18:38:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyq0-0005qZ-QH for isms@ietf.org; Wed, 22 Aug 2007 18:38:08 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INyq0-0003y9-GP for isms@ietf.org; Wed, 22 Aug 2007 18:38:08 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l7MMc4wA025163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 18:38:04 -0400 (EDT) Date: Wed, 22 Aug 2007 18:38:04 -0400 From: Jeffrey Hutzelman To: David Harrington , "'ISMS WG'" Subject: Re: [Isms] SNMP-SSH-TM-MIB session info Message-ID: In-Reply-To: <000001c7ddc1$b8ad72f0$6702a8c0@china.huawei.com> References: <000001c7ddc1$b8ad72f0$6702a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01uTJskyOa4QcFfeQU7LCcAlCko75AZuUmp5r477I=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: Jeffrey Hutzelman 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 Monday, August 13, 2007 11:50:49 AM -0400 David Harrington wrote: > If people want this information, they should request that the SecSH WG > write a MIB module for managing SSH sessions. Well, the secsh WG no longer exists, so that's not going to happen. However, I agree that capabilities of the SSH implementation are unlikely to be known to the SSH-TM implementation and don't belong here. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 22 18:53:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INz2r-0003w4-Jj; Wed, 22 Aug 2007 18:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INz2p-0003vz-RC for isms@ietf.org; Wed, 22 Aug 2007 18:51:23 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INz2p-00062n-GN for isms@ietf.org; Wed, 22 Aug 2007 18:51:23 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20070822225122b1400piaele>; Wed, 22 Aug 2007 22:51:22 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'tom.petch'" , "'ISMS WG'" References: <037c01c7db3c$9725b520$0601a8c0@pc6> <016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com> <01af01c7dd84$15202c00$0601a8c0@pc6> <000901c7ddd0$79189a20$6702a8c0@china.huawei.com> <021701c7de7e$7ebcdaa0$0601a8c0@pc6> <59165B4D35F9378674A70368@sirius.fac.cs.cmu.edu> Subject: RE: [Isms] Working Group Last Call - securityName Date: Wed, 22 Aug 2007 18:51:17 -0400 Message-ID: <012501c7e50e$f3723700$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcflBm6DAl7PuzGoQTegZMQXAydIIgAAZf+w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <59165B4D35F9378674A70368@sirius.fac.cs.cmu.edu> 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 Thank you Jeff. Your analysis is very thorough, and I believe it is fully accurate. A couple minor comments. > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > > > I think that the mapping matters because when a > session-oriented secure > > transport model is passed an outbound message, it has no transport > > selector and uses securityName, securityLevel, and > transport address to > > select a session; get the wrong session and you have > undermined security. We do have a transport selector; it is the transportDomain parameter that accompanies the transportAddress in the ASIs. For the SSH-TM, it is snmpSSHDomain and the address is of type SnmpSSHAddress. We even have a session-selector because we specify that "SSH sessions are uniquely identified within the SSH Transport Model by the combination of transportAddressType, transportAddress, securityName, and securityLevel associated with each session." [note to self: should this transportAddressType wording be transportDomain?] > For an outbound message, there is no decision to be made -- the > securityName came from the application, and while there might > be multiple > consumers of that information (the security model, the SNMPv3 message > security parameters, and the secure transport model), they > all consume the > same value, which is the one provided by the application. The application is required to provide not only the securityName, but also the securityModel. The securityModel knows how to "reverse the mapping" to send the right parmaters to the other pieces that will process the outgoing message (the message processing model and the transport model). 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 Wed Aug 22 19:18:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INzRN-0000q0-0K; Wed, 22 Aug 2007 19:16:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INzRL-0000pt-BH for isms@ietf.org; Wed, 22 Aug 2007 19:16:43 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INzRK-0004sg-Of for isms@ietf.org; Wed, 22 Aug 2007 19:16:43 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l7MNGX1E025184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 19:16:34 -0400 (EDT) Date: Wed, 22 Aug 2007 19:16:33 -0400 From: Jeffrey Hutzelman To: David Harrington , "'tom.petch'" , "'ISMS WG'" Subject: RE: [Isms] Working Group Last Call - securityName Message-ID: <7958D25293C8B6AA01621659@sirius.fac.cs.cmu.edu> In-Reply-To: <012501c7e50e$f3723700$6702a8c0@china.huawei.com> References: <037c01c7db3c$9725b520$0601a8c0@pc6> <016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com> <01af01c7dd84$15202c00$0601a8c0@pc6> <000901c7ddd0$79189a20$6702a8c0@china.huawei.com> <021701c7de7e$7ebcdaa0$0601a8c0@pc6> <59165B4D35F9378674A70368@sirius.fac.cs.cmu.edu> <012501c7e50e$f3723700$6702a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01vckc8CcxkWQJFJRx8EdMX1Q7UxtE/ZUqPkpV80k=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: b7b9551d71acde901886cc48bfc088a6 Cc: Jeffrey Hutzelman 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, August 22, 2007 06:51:17 PM -0400 David Harrington wrote: >> > I think that the mapping matters because when a >> session-oriented secure >> > transport model is passed an outbound message, it has no transport >> > selector and uses securityName, securityLevel, and >> transport address to >> > select a session; get the wrong session and you have >> undermined security. Note that the above was written by Tom and not me. > We do have a transport selector; it is the transportDomain parameter > that accompanies the transportAddress in the ASIs. For the SSH-TM, it > is snmpSSHDomain and the address is of type SnmpSSHAddress. Sure, but I think he means "transport session selector". > We even have a session-selector because we specify that "SSH sessions > are uniquely identified within the SSH Transport Model by the > combination of transportAddressType, transportAddress, securityName, > and securityLevel associated with each session." Yes, but Tom's point is that that alone doesn't always help you. For a message that is a response, the securityName associated with the message will have been provided by the application, and should be the same as the securityName of the original request. However, in the USM-over-SSH case, this may not be the same as the securityName that the transport model proposed, and if not, there is no way to recover that name. So if you use the transport address and security parameters to find a session, you may end up with the "wrong" session; that is, one whose ssh username agrees with the name provided by USM but which is not the same session the request came in on. I think the simple thing to do here is for the TM to include a real session identifier in the tmStateRef, and use that instead of matching to find the correct session for a reply. However, even if you search for a session by matching transport address and security parameters, having the "wrong" thing happen requires the following: (1) I establish an SSH connection, authenticated as Alice. (2) I send an authentic SNMP request using USM, with USM username Bob. (3) While my request is being processed, I disconnect the SSH session, then establish a new SSH session to the SNMP server _from the same transport endpoint_, and this time authenticate as Bob. (4) The server's response goes to my connection, because it belongs to Bob and has the right transport address. In this situation, something "wrong" has happened, but it has not compromised security, because I proved I was "Bob" when I sent the message, and again when I established the new SSH connecton, and I even still have to know the USM key in order to process the response. What is more likely is that I do (1) and (2), and then the server is confused about where to send the response because there is no ssh session from Bob. >> For an outbound message, there is no decision to be made -- the >> securityName came from the application, and while there might >> be multiple >> consumers of that information (the security model, the SNMPv3 > message >> security parameters, and the secure transport model), they >> all consume the >> same value, which is the one provided by the application. > > The application is required to provide not only the securityName, but > also the securityModel. The securityModel knows how to "reverse the > mapping" to send the right parmaters to the other pieces that will > process the outgoing message (the message processing model and the > transport model). Well, no, not entirely. USM does not know how to regenerate the SSH username that it discarded. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 22 19:36:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INziL-0002ys-0g; Wed, 22 Aug 2007 19:34:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INziK-0002yl-90 for isms@ietf.org; Wed, 22 Aug 2007 19:34:16 -0400 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INziJ-0005Aa-JN for isms@ietf.org; Wed, 22 Aug 2007 19:34:16 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc16) with SMTP id <20070822233414b1600qkcoge>; Wed, 22 Aug 2007 23:34:14 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'tom.petch'" , "'ISMS WG'" References: <037c01c7db3c$9725b520$0601a8c0@pc6> <016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com> <01af01c7dd84$15202c00$0601a8c0@pc6> <000901c7ddd0$79189a20$6702a8c0@china.huawei.com> <021701c7de7e$7ebcdaa0$0601a8c0@pc6> <59165B4D35F9378674A70368@sirius.fac.cs.cmu.edu> <012501c7e50e$f3723700$6702a8c0@china.huawei.com> <7958D25293C8B6AA01621659@sirius.fac.cs.cmu.edu> Subject: RE: [Isms] Working Group Last Call - securityName Date: Wed, 22 Aug 2007 19:34:09 -0400 Message-ID: <012601c7e514$f0945cb0$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcflEn6gkJ2YlJ/1ReSy+lQqCdp31wAAU9UQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <7958D25293C8B6AA01621659@sirius.fac.cs.cmu.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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 Ah! I agree. The security model saves the security state for use with responses, and in the USM over SSH combination, the USM does not know about or save the SSH security state or the mapping from the application/securityCache securityName to the transport mapping securityName. I don't know how to make the "legacy" security models understand about transport security parmeters without rewriting them. The only solution I can see is to force the choice of security model, which means the USM over SSH combination cannot be chosen, which violates the architecture. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Wednesday, August 22, 2007 7:17 PM > To: David Harrington; 'tom.petch'; 'ISMS WG' > Cc: Jeffrey Hutzelman > Subject: RE: [Isms] Working Group Last Call - securityName > > > > On Wednesday, August 22, 2007 06:51:17 PM -0400 David Harrington > wrote: > > >> > I think that the mapping matters because when a > >> session-oriented secure > >> > transport model is passed an outbound message, it has no > transport > >> > selector and uses securityName, securityLevel, and > >> transport address to > >> > select a session; get the wrong session and you have > >> undermined security. > > Note that the above was written by Tom and not me. > > > > > We do have a transport selector; it is the transportDomain parameter > > that accompanies the transportAddress in the ASIs. For the > SSH-TM, it > > is snmpSSHDomain and the address is of type SnmpSSHAddress. > > Sure, but I think he means "transport session selector". > > > We even have a session-selector because we specify that > "SSH sessions > > are uniquely identified within the SSH Transport Model by the > > combination of transportAddressType, transportAddress, securityName, > > and securityLevel associated with each session." > > Yes, but Tom's point is that that alone doesn't always help you. > For a message that is a response, the securityName associated > with the > message will have been provided by the application, and > should be the same > as the securityName of the original request. However, in the > USM-over-SSH > case, this may not be the same as the securityName that the > transport model > proposed, and if not, there is no way to recover that name. > So if you use > the transport address and security parameters to find a > session, you may > end up with the "wrong" session; that is, one whose ssh > username agrees > with the name provided by USM but which is not the same > session the request > came in on. > > I think the simple thing to do here is for the TM to include > a real session > identifier in the tmStateRef, and use that instead of > matching to find the > correct session for a reply. > > However, even if you search for a session by matching > transport address and > security parameters, having the "wrong" thing happen requires > the following: > > (1) I establish an SSH connection, authenticated as Alice. > (2) I send an authentic SNMP request using USM, with USM username Bob. > (3) While my request is being processed, I disconnect the SSH session, > then establish a new SSH session to the SNMP server _from the same > transport endpoint_, and this time authenticate as Bob. > (4) The server's response goes to my connection, because it > belongs to Bob > and has the right transport address. > > In this situation, something "wrong" has happened, but it has not > compromised security, because I proved I was "Bob" when I > sent the message, > and again when I established the new SSH connecton, and I > even still have > to know the USM key in order to process the response. > > What is more likely is that I do (1) and (2), and then the server is > confused about where to send the response because there is no > ssh session > from Bob. > > > > >> For an outbound message, there is no decision to be made -- the > >> securityName came from the application, and while there might > >> be multiple > >> consumers of that information (the security model, the SNMPv3 > > message > >> security parameters, and the secure transport model), they > >> all consume the > >> same value, which is the one provided by the application. > > > > The application is required to provide not only the > securityName, but > > also the securityModel. The securityModel knows how to "reverse the > > mapping" to send the right parmaters to the other pieces that will > > process the outgoing message (the message processing model and the > > transport model). > > Well, no, not entirely. USM does not know how to regenerate the SSH > username that it discarded. > > -- Jeff > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 22 19:53:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INzyy-0004h2-AS; Wed, 22 Aug 2007 19:51:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INzyx-0004gs-CJ for isms@ietf.org; Wed, 22 Aug 2007 19:51:27 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INzyw-0007CM-27 for isms@ietf.org; Wed, 22 Aug 2007 19:51:27 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 22 Aug 2007 16:51:25 -0700 X-IronPort-AV: i="4.19,296,1183359600"; d="scan'208"; a="172395247:sNHT101501280" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7MNpPhY000521; Wed, 22 Aug 2007 16:51:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7MNpPWp022539; Wed, 22 Aug 2007 23:51:25 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 16:51:24 -0700 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] More questions on Security name Date: Wed, 22 Aug 2007 16:51:27 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] More questions on Security name Thread-Index: Acfjsz0k5y18ve4xSVKYzIztTb71EgACmncwAFWmZ9A= From: "Joseph Salowey \(jsalowey\)" To: "Wijnen, Bert \(Bert\)" , X-OriginalArrivalTime: 22 Aug 2007 23:51:24.0957 (UTC) FILETIME=[595C2CD0:01C7E517] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4009; t=1187826685; x=1188690685; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Isms]=20More=20questions=20on=20Security=20name |Sender:=20; bh=ZmXHfHw1J1p0MjyVDXfUisUkmxpxLfM7zt41/ZPHemQ=; b=WXyJjhFIiC0vy2+0i437kY0e668hQ0nTwPThWNSRNVpXPHicbBUJPThyVI+eio6i9TRExp7i inZHliWqZPkeXotpZLjRExGGBIVlbzVLyZTd9BTSy/x55wSx6Di8fJ2zJtb8qf3X8A3wlVj0xW hn1/uXYaxmnEpN6e25Fc5jubw=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 Thanks Bert, This is helpful. Comments inline:=20 > Bert Wijnen =20 >=20 > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > Sent: Tuesday, August 21, 2007 7:22 AM > > To: isms@ietf.org > > Subject: [Isms] More questions on Security name > >=20 >=20 > > A security > > name may be used on a notification generator to determine if the=20 > > notification receiver is authorized to receive a message (security=20 > > name applies to notification receiver). > >=20 > Nope. The securityName gets mapped into a groupName and=20 > together with securityLevel and securityModel, the VACM=20 > tables control if all the object-instances included in the=20 > notifications can indeed be accessed and if so they will be=20 > sent as varBinds in the notification. >=20 > On the receiving end there is no "access control". [Joe] OK, this is where I have been confused. What entity does the security name represent? I seems like it represents the user on the notification receiver. There is no access control on the receiving end, but on the sending end there is access control based on who the message is being sent to. So, when sending a notification you need to authenticate that the receiver is the 'user' you are authorized to send to. Correct? =20 >=20 > > In SSH, generally there is more than one entity identity involved. =20 > > One entity is identified by a SSH user authentication=20 > (username) and=20 > > another is identified by SSH server authentication (IP=20 > address/domain=20 > > name). > >=20 >=20 > The userName (in the msgUserName in the=20 > UsmSecurityParameters, see RFC3414 sect 2.4) gets translated=20 > into securtyName (1 to 1, identity function) and then gets=20 > used to do the authentication, and privacy en/decription)=20 > Specifically, here it is important to know about the=20 > authoritative side. As stated above, normally it is the=20 > agent, but for INFORM PDUs it is the notofication receiver=20 > (running at the manager). >=20 [Joe] OK, this seems consistent with above.=20 > > Some of the difficulty around securityName may originate=20 > from this. =20 > > We may need to split up securityName into two pieces, but=20 > this seems=20 > > like it would have some impact on SNMP, although maybe it=20 > would always=20 > > be clear which name is used in particular case. >=20 > In SNMP with USM, you basically only have one side that is=20 > authoritative (in each communication, that is per exchange of=20 > a SNMP PDU pair (request/response), based on a shared=20 > msgUserName secret. In case of a TRAPv2-PDU there is just=20 > one-way, so no response. >=20 > I am leaving the REPORT PDUs out of the discussion for now. > I think such is OK. >=20 > > Another option (well really it probably maps to the same=20 > thing) is to=20 > > treat the mutual authentication as a single securityName such as=20 > > something like joeuser@snmpssh.example.com. This seems=20 > like it would=20 > > affect how authorization is set up in VACM. > >=20 >=20 > I believe that USM uses the msgUserName/password indeed as a=20 > mutual authentication (see description above and let me know=20 > if you agree). >=20 [Joe] yes, in a way USM uses the msgUserName/password as mutual authentication. More specifically it uses a secret derived from the msgUserName/Password/(and perhaps AuthoritativeEngineID) to perform mutual authentication. =20 > > If other people are as confused as me then perhaps we need=20 > to have a=20 > > section in the document that describes the interaction with=20 > > authorization. > >=20 >=20 > Hope my comments helped. >=20 [Joe] They did, now I need to go back and try and make sense of it all.=20 > Bert > > Joe > >=20 > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 22 20:09:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO0F0-0003Kt-Lm; Wed, 22 Aug 2007 20:08:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO0Ez-0003Ko-RR for isms@ietf.org; Wed, 22 Aug 2007 20:08:01 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO0Ey-0007f3-HX for isms@ietf.org; Wed, 22 Aug 2007 20:08:01 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 22 Aug 2007 17:08:00 -0700 X-IronPort-AV: i="4.19,296,1183359600"; d="scan'208"; a="204793297:sNHT384870159" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7N07x5K002125; Wed, 22 Aug 2007 17:07:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7N07xUg026761; Thu, 23 Aug 2007 00:07:59 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 17:07:59 -0700 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] my review of: draft-ietf-isms-secshell-08.txt Date: Wed, 22 Aug 2007 17:08:01 -0700 Message-ID: In-Reply-To: <539D70CF464B36159F3434D8@sirius.fac.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] my review of: draft-ietf-isms-secshell-08.txt Thread-Index: AcflC50EvsOOSJhES42fdaYXiMLsEAADQlCA From: "Joseph Salowey \(jsalowey\)" To: "Jeffrey Hutzelman" , "Wijnen, Bert \(Bert\)" , "David Harrington" X-OriginalArrivalTime: 23 Aug 2007 00:07:59.0459 (UTC) FILETIME=[AA212330:01C7E519] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3930; t=1187827679; x=1188691679; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Isms]=20my=20review=20of=3A=20draft-ietf-isms-secshe ll-08.txt |Sender:=20; bh=ah73nmhOIYlq1GrEXuw3HhoHYX5IKCevP/du1dNn35g=; b=O//mDXBAcLPgUDp8pGhkKjWMvZFQG+qxfN8+owA3mn67aiCTFAePsMaTXrmg/JP4Gp32VvcZ oY46duRoeTm6FYprLSZ6tmbrgDK0QSLRF694BZTHcOIHlVq7Ep9cfdeA; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 In particular I think we need to be careful of SSH_MSG_USERAUTH_REQUEST. First an empty username may appear in this message and second there is a loophole in the base SSH spec that could allow an authentication mechanism in which the name in the username field is not an authorized name of the authenticated party. =20 =20 > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 > Sent: Wednesday, August 22, 2007 3:22 PM > To: Wijnen, Bert (Bert); David Harrington; Joseph Salowey (jsalowey) > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: Re: [Isms] my review of: draft-ietf-isms-secshell-08.txt >=20 >=20 >=20 > On Thursday, August 09, 2007 12:17:13 PM +0200 "Wijnen, Bert (Bert)"=20 > wrote: >=20 > > - sect 5.1 and 5.1 > > I assume that SSH_MSG_USERAUTH_REQUEST and SSH_MSG_CHANNEL_DATA > > are specified somewhere in the SSH RFC(s)? Maybe a citation to > > such RFC(s) is useful at these points. >=20 > Yes; those are SSH protocol messages. It's actually not=20 > clear that SSH messages should be referenced explicitly here;=20 > instead, we should be talking about SSH at a rather higher=20 > layer. For example, SSH user authentication can be a fairly=20 > complex negotiation; it doesn't involve sending just one=20 > message. Similarly, outside the SSH protocol channels are=20 > presented as streams, not sequences of SSH_MSG_CHANNEL_DATA=20 > messages, and in particular you can't assume that your=20 > messages will be sent in a single channel data message or=20 > infer the size of an incoming message from the underlying SSH=20 > protocol messages. >=20 > Similarly, if you are establishing a separate SSH connection=20 > for every session, you don't need data from the SSH channel=20 > open/confirmation messages, and in fact generally such data=20 > will not be available to you as it is buried in the details=20 > of the SSH protocol. If you are establishing multiple=20 > channels over the same SSH session, then you may need to know=20 > which channel is which, but this is almost certainly done=20 > using identifiers provided to you by your SSH implementation=20 > (perhaps even file descriptors) and not necessarily using SSH=20 > protocol data. >=20 >=20 >=20 > > - For SnmpSSHAddress ::=3D TEXTUAL-CONVENTION I read: > > > > "Represents either a hostname encoded in ASCII > > using the IDNA protocol, as specified in RFC3490,=20 > followed by > > a colon ':' (ASCII character 0x3A) and a decimal port number > > in ASCII, or an IP address followed by a colon ':' > > (ASCII character 0x3A) and a decimal port number in ASCII. > > The name SHOULD be fully qualified whenever possible. > > > > I am not well versed/experienced in IDNA. But is IDNA a protocol? >=20 > That is a semantic question, which I'd just as soon not argue here. > Perhaps we could say "as specified by IDNA [RFC3490]" ? >=20 >=20 > > The title of 3490 reads > > Internationalizing Domain Names in Applications (IDNA) > > And are we indeed speaking of a hostname, or of a domain name, or > > of both? I can't quickly determine that. So I wonder if/hope that > > we can be clearer here. >=20 > We are talking about a hostname, but hostnames are domain=20 > names (however, not all domain names are valid hostnames). >=20 >=20 >=20 > > I also assume (although this is not explicitly stated) that if we > > speak about an IP address, that it is a dotted decimal for > > IPv4 and and a colon separated IPv6 address in ASCII? Yes/no? >=20 > In fact, I think we are in trouble if, for an IPv6 address,=20 > we don't mean a=20 > colon-separated address with brackets around it. Otherwise=20 > it may become=20 > rather difficult to determine where the port starts, or if it=20 > is present! >=20 > -- Jeff >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 22 20:34:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO0cX-0004qs-HZ; Wed, 22 Aug 2007 20:32:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO0cW-0004qn-Bp for isms@ietf.org; Wed, 22 Aug 2007 20:32:20 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IO0cW-0008CS-2e for isms@ietf.org; Wed, 22 Aug 2007 20:32:20 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa13241; 22 Aug 2007 20:32 EDT Date: Wed, 22 Aug 2007 20:32:04 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: David Harrington Subject: RE: [Isms] Working Group Last Call - securityName In-Reply-To: <012601c7e514$f0945cb0$6702a8c0@china.huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'ISMS WG' 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 Wed, 22 Aug 2007, David Harrington wrote: > Ah! I agree. The security model saves the security state for use with > responses, and in the USM over SSH combination, the USM does not know > about or save the SSH security state or the mapping from the > application/securityCache securityName to the transport mapping > securityName. I don't know how to make the "legacy" security models > understand about transport security parmeters without rewriting them. > > The only solution I can see is to force the choice of security model, > which means the USM over SSH combination cannot be chosen, which > violates the architecture. Hrm. Why does it have to be the security model that saves state between request and response? I actually think it would be acceptable to say you can't use the USM over SSH combination if the security parameters don't match. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 02:19:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO60P-0005jW-Ld; Thu, 23 Aug 2007 02:17:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO60O-0005gb-IZ for isms@ietf.org; Thu, 23 Aug 2007 02:17:20 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IO60O-0004pm-5o for isms@ietf.org; Thu, 23 Aug 2007 02:17:20 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20070823061719b1300ee496e>; Thu, 23 Aug 2007 06:17:19 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" References: <012601c7e514$f0945cb0$6702a8c0@china.huawei.com> Subject: RE: [Isms] Working Group Last Call - securityName Date: Thu, 23 Aug 2007 02:17:13 -0400 Message-ID: <013001c7e54d$3fa32f10$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcflHQ7kwP9uxZJnQti723Fy4n3qogALnaIg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 'ISMS WG' 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: Wednesday, August 22, 2007 8:32 PM > To: David Harrington > Cc: 'tom.petch'; 'ISMS WG' > Subject: RE: [Isms] Working Group Last Call - securityName > > Hrm. Why does it have to be the security model that saves > state between > request and response? That's what the architecture demands. The transport model doesn't know what the operation in the incoming message is; it doesn't know if the message contains a request or a response. This is because the message has not yet been parsed by the MPM. The MPM doesn't know what the security parameters are; the securityParmeters in the message are opaque to the MPM; those are only unpacked by the security model. So the security model has to be the one to ave security state. > > I actually think it would be acceptable to say you can't use > the USM over > SSH combination if the security parameters don't match. What security parameters do you want to "match"? These are different protocol parameters at different layers. Can you say that SSH cannot be used over IPsec if the parameters don't match? They are at different layers and use different parameters. The MPM selects which security model to use, but the MPM doesn't know what the security parameters are. And once the MPM has selected the USM, the USM has no way to determine the security parameters related to a secure transport. We've done a good job of hiding information ... ;-) 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 Thu Aug 23 05:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008Gp-VD; Thu, 23 Aug 2007 05:26:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008GT-BE for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO8x5-00015w-3f for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7N9Pk8W009010; Thu, 23 Aug 2007 04:25:56 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 04:25:50 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 11:25:45 +0200 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] Working Group Last Call - securityName Date: Thu, 23 Aug 2007 11:25:45 +0200 Message-ID: In-Reply-To: <013001c7e54d$3fa32f10$6702a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Working Group Last Call - securityName Thread-Index: AcflHQ7kwP9uxZJnQti723Fy4n3qogALnaIgAAZvK6A= References: <012601c7e514$f0945cb0$6702a8c0@china.huawei.com> <013001c7e54d$3fa32f10$6702a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , "Jeffrey Hutzelman" X-OriginalArrivalTime: 23 Aug 2007 09:25:45.0684 (UTC) FILETIME=[958DD140:01C7E567] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ISMS WG 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 Bert Wijnen =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, August 23, 2007 8:17 AM > To: 'Jeffrey Hutzelman' > Cc: 'ISMS WG' > Subject: RE: [Isms] Working Group Last Call - securityName >=20 > Hi,=20 >=20 > > -----Original Message----- > > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > > Sent: Wednesday, August 22, 2007 8:32 PM > > To: David Harrington > > Cc: 'tom.petch'; 'ISMS WG' > > Subject: RE: [Isms] Working Group Last Call - securityName > >=20 > > Hrm. Why does it have to be the security model that saves state=20 > > between request and response? >=20 > That's what the architecture demands.=20 >=20 Mmm... isn't it such that the security model save securityState that it=20 needs later when it needs to process a response.? The trabport model saves tmState that it needs when later processing a response. I do not see the wto conflict or cause trouble. So I do not see why USM over SSH would be a [problem in this respect. > The transport model doesn't know what the operation in the=20 > incoming message is; it doesn't know if the message contains=20 > a request or a response. This is because the message has not=20 > yet been parsed by the MPM. >=20 Does it need to know? > TFrom isms-bounces@lists.ietf.org Thu Aug 23 05:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008Gp-VD; Thu, 23 Aug 2007 05:26:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008GT-BE for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO8x5-00015w-3f for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7N9Pk8W009010; Thu, 23 Aug 2007 04:25:56 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 04:25:50 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 11:25:45 +0200 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] Working Group Last Call - securityName Date: Thu, 23 Aug 2007 11:25:45 +0200 Message-ID: In-Reply-To: <013001c7e54d$3fa32f10$6702a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Working Group Last Call - securityName Thread-Index: AcflHQ7kwP9uxZJnQti723Fy4n3qogALnaIgAAZvK6A= References: <012601c7e514$f0945cb0$6702a8c0@china.huawei.com> <013001c7e54d$3fa32f10$6702a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , "Jeffrey Hutzelman" X-OriginalArrivalTime: 23 Aug 2007 09:25:45.0684 (UTC) FILETIME=[958DD140:01C7E567] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ISMS WG 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 Bert Wijnen =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, August 23, 2007 8:17 AM > To: 'Jeffrey Hutzelman' > Cc: 'ISMS WG' > Subject: RE: [Isms] Working Group Last Call - securityName >=20 > Hi,=20 >=20 > > -----Original Message----- > > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > > Sent: Wednesday, August 22, 2007 8:32 PM > > To: David Harrington > > Cc: 'tom.petch'; 'ISMS WG' > > Subject: RE: [Isms] Working Group Last Call - securityName > >=20 > > Hrm. Why does it have to be the security model that saves state=20 > > between request and response? >=20 > That's what the architecture demands.=20 >=20 Mmm... isn't it such that the security model save securityState that it=20 needs later when it needs to process a response.? The trabport model saves tmState that it needs when later processing a response. I do not see the wto conflict or cause trouble. So I do not see why USM over SSH would be a [problem in this respect. > The transport model doesn't know what the operation in the=20 > incoming message is; it doesn't know if the message contains=20 > a request or a response. This is because the message has not=20 > yet been parsed by the MPM. >=20 Does it need to know? > The MPM doesn't know what the security parameters are; the=20 > securityParmeters in the message are opaque to the MPM; those=20 > are only unpacked by the security model. So the security=20 > model has to be the one to ave security state. >=20 Right, and so for USM over SSH, the only thing it needs to know is that the underlying security was indeed at least as high as the=20 securityLevel (actually, it may not even need that, does it?). > >=20 > > I actually think it would be acceptable to say you can't=20 > use the USM=20 > > over SSH combination if the security parameters don't match. >=20 > What security parameters do you want to "match"? These are=20 > different protocol parameters at different layers. Can you=20 > say that SSH cannot be used over IPsec if the parameters=20 > don't match? They are at different layers and use different=20 > parameters. >=20 > The MPM selects which security model to use, but the MPM=20 > doesn't know what the security parameters are. And once the=20 > MPM has selected the USM, the USM has no way to determine the=20 > security parameters related to a secure transport. We've done=20 > a good job of hiding information ... > ;-) >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 05:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x9-0008HN-3A; Thu, 23 Aug 2007 05:26:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008GY-Ff for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IO8x5-0000s6-Vk for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7N9Pk8S009010; Thu, 23 Aug 2007 04:25:47 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 04:25:46 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 11:25:44 +0200 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] tmStateReference in draft-ietf-isms-tmsm-09.txt Date: Thu, 23 Aug 2007 11:25:44 +0200 Message-ID: In-Reply-To: <44AB066FC5148F45AE2DB05F@sirius.fac.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] tmStateReference in draft-ietf-isms-tmsm-09.txt Thread-Index: AcflCMktbQhusl1oTTeHarx3T1PWkAAWuc/w References: <44AB066FC5148F45AE2DB05F@sirius.fac.cs.cmu.edu> From: "Wijnen, Bert \(Bert\)" To: "Jeffrey Hutzelman" , , "David Harrington" X-OriginalArrivalTime: 23 Aug 2007 09:25:44.0887 (UTC) FILETIME=[95143470:01C7E567] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008Gp-VD; Thu, 23 Aug 2007 05:26:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008GT-BE for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO8x5-00015w-3f for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7N9Pk8W009010; Thu, 23 Aug 2007 04:25:56 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 04:25:50 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 11:25:45 +0200 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] Working Group Last Call - securityName Date: Thu, 23 Aug 2007 11:25:45 +0200 Message-ID: In-Reply-To: <013001c7e54d$3fa32f10$6702a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Working Group Last Call - securityName Thread-Index: AcflHQ7kwP9uxZJnQti723Fy4n3qogALnaIgAAZvK6A= References: <012601c7e514$f0945cb0$6702a8c0@china.huawei.com> <013001c7e54d$3fa32f10$6702a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , "Jeffrey Hutzelman" X-OriginalArrivalTime: 23 Aug 2007 09:25:45.0684 (UTC) FILETIME=[958DD140:01C7E567] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ISMS WG 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 Bert Wijnen =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, August 23, 2007 8:17 AM > To: 'Jeffrey Hutzelman' > Cc: 'ISMS WG' > Subject: RE: [Isms] Working Group Last Call - securityName >=20 > Hi,=20 >=20 > > -----Original Message----- > > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > > Sent: Wednesday, August 22, 2007 8:32 PM > > To: David Harrington > > Cc: 'tom.petch'; 'ISMS WG' > > Subject: RE: [Isms] Working Group Last Call - securityName > >=20 > > Hrm. Why does it have to be the security model that saves state=20 > > between request and response? >=20 > That's what the architecture demands.=20 >=20 Mmm... isn't it such that the security model save securityState that it=20 needs later when it needs to process a response.? The trabport model saves tmState that it needs when later processing a response. I do not see the wto conflict or cause trouble. So I do not see why USM over SSH would be a [problem in this respect. > The transport model doesn't know what the operation in the=20 > incoming message is; it doesn't know if the message contains=20 > a request or a response. This is because the message has not=20 > yet been parsed by the MPM. >=20 Does it need to know? > The MPM doesn't know what the security parameters are; the=20 > securityParmeters in the message are opaque to the MPM; those=20 > are only unpacked by the security model. So the security=20 > model has to be the one to ave security state. >=20 Right, and so for USM over SSH, the only thing it needs to know is that the underlying security was indeed at least as high as the=20 securityLevel (actually, it may not even need that, does it?). > >=20 > > I actually think it would be acceptable to say you can't=20 > use the USM=20 > > over SSH combination if the security parameters don't match. >=20 > What security parameters do you want to "match"? These are=20 > different protocol parameters at different layers. Can you=20 > say that SSH cannot be used over IPsec if the parameters=20 > don't match? They are at different layers and use different=20 > parameters. >=20 > The MPM selects which security model to use, but the MPM=20 > doesn't know what the security parameters are. And once the=20 > MPM has selected the USM, the USM has no way to determine the=20 > security parameters related to a secure transport. We've done=20 > a good job of hiding information ... > ;-) >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 05:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x9-0008HN-3A; Thu, 23 Aug 2007 05:26:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008GY-Ff for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IO8x5-0000s6-Vk for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7N9Pk8S009010; Thu, 23 Aug 2007 04:25:47 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 04:25:46 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 11:25:44 +0200 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] tmStateReference in draft-ietf-isms-tmsm-09.txt Date: Thu, 23 Aug 2007 11:25:44 +0200 Message-ID: In-Reply-To: <44AB066FC5148F45AE2DB05F@sirius.fac.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] tmStateReference in draft-ietf-isms-tmsm-09.txt Thread-Index: AcflCMktbQhusl1oTTeHarx3T1PWkAAWuc/w References: <44AB066FC5148F45AE2DB05F@sirius.fac.cs.cmu.edu> From: "Wijnen, Bert \(Bert\)" To: "Jeffrey Hutzelman" , , "David Harrington" X-OriginalArrivalTime: 23 Aug 2007 09:25:44.0887 (UTC) FILETIME=[95143470:01C7E567] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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: securityParmeters in the message are opaque to the MPM; those=20 > are only unpacked by the security model. So the security=20 > model has to be the one to ave security state. >=20 Right, and so for USM over SSH, the only thing it needs to know is that the underlying security was indeed at least as high as the=20 securityLevel (actually, it may not even need that, does it?). > >=20 > > I actually think it would be acceptable to say you can't=20 > use the USM=20 > > over SSH combination if the security parameters don't match. >=20 > What security parameters do you want to "match"? These are=20 > different protocol parameters at different layers. Can you=20 > say that SSH cannot be used over IPsec if the parameters=20 > don't match? They are at different layers and use different=20 > parameters. >=20 > The MPM selects which security model to use, but the MPM=20 > doesn't know what the security parameters are. And once the=20 > MPM has selected the USM, the USM has no way to determine the=20 > security parameters related to a secure transport. We've done=20 > a good job of hiding information ... > ;-) >=20 > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 05:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x9-0008HN-3A; Thu, 23 Aug 2007 05:26:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008GY-Ff for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IO8x5-0000s6-Vk for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7N9Pk8S009010; Thu, 23 Aug 2007 04:25:47 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 04:25:46 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 11:25:44 +0200 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] tmStateReference in draft-ietf-isms-tmsm-09.txt Date: Thu, 23 Aug 2007 11:25:44 +0200 Message-ID: In-Reply-To: <44AB066FC5148F45AE2DB05F@sirius.fac.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] tmStateReference in draft-ietf-isms-tmsm-09.txt Thread-Index: AcflCMktbQhusl1oTTeHarx3T1PWkAAWuc/w References: <44AB066FC5148F45AE2DB05F@sirius.fac.cs.cmu.edu> From: "Wijnen, Bert \(Bert\)" To: "Jeffrey Hutzelman" , , "David Harrington" X-OriginalArrivalTime: 23 Aug 2007 09:25:44.0887 (UTC) FILETIME=[95143470:01C7E567] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Inline Bert Wijnen =20 > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 > Sent: Thursday, August 23, 2007 12:07 AM > To: Wijnen, Bert (Bert);=20 > j.schoenwaelder@jacobs-university.de; David Harrington > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: Re: [Isms] tmStateReference in draft-ietf-isms-tmsm-09.txt=20 >=20 >=20 >=20 > On Wednesday, August 08, 2007 12:17:56 PM +0200 "Wijnen, Bert (Bert)"=20 > wrote: >=20 > > > > I am confused by the last 2 paragraphs in sect 6.2 > > > > The prepareOutgoingMessage ASI passes tmStateReference from the > > Message Processing Subsystem to the dispatcher. How or if the > > Message Processing Subsystem modifies or utilizes the contents of the > > cache is message-processing-model-specific. > > > > This may sound underspecified, but keep in mind that a message > > processing model might have access to all the information from the > > cache and from the message, and have no need to call a Security Model > > to do any processing; an application might choose a Security Model > > such as USM to authenticate and secure the SNMP message, but also > > utilize a secure transport such as that provided by the SSH Transport > > Model to send the message to its destination. > > > > specifically the wording "an application...". > > Applications in our RFC3411 context are CG or CR or NO or NR or such. > > I am sure that is not intended here. But then, what is an "application" > > in this sentence above? >=20 > Why not? Is it not these applications which specify a=20 > security model/name/level and transport domain and address? =20 > If an application selects USM security parameters and an SSH=20 > transport address, it has effectively chosen the use of USM and SSH. >=20 Mmm... I am less concerned now.. but still have an uneasy feeling. Need to go lookup details before I can put words around it... or maybe if I do my concerns go away. >=20 > > I am also not sure we should speak about the MPM to "not call a=20 > > security model". From our architectural point of view, the MPM will=20 > > ALWAYS call a security model. If an implementation does a shortcut,=20 > > that is up to them... but should we discuss that here? >=20 > I agree. Even if a new MPM were defined in the future, to=20 > specify situations when using that MPM in which the security=20 > model is not called would seem to violate the architecture. >=20 ack Bert > -- Jeff >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 05:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x9-0008HY-71; Thu, 23 Aug 2007 05:26:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008Gd-Q1 for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IO8x5-0000s4-Vi for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7N9Pk8Y009010; Thu, 23 Aug 2007 04:26:02 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 04:25:48 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 11:25:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-clasg/pipermail/isms> List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Inline Bert Wijnen =20 > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 > Sent: Thursday, August 23, 2007 12:07 AM > To: Wijnen, Bert (Bert);=20 > j.schoenwaelder@jacobs-university.de; David Harrington > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: Re: [Isms] tmStateReference in draft-ietf-isms-tmsm-09.txt=20 >=20 >=20 >=20 > On Wednesday, August 08, 2007 12:17:56 PM +0200 "Wijnen, Bert (Bert)"=20 > wrote: >=20 > > > > I am confused by the last 2 paragraphs in sect 6.2 > > > > The prepareOutgoingMessage ASI passes tmStateReference from the > > Message Processing Subsystem to the dispatcher. How or if the > > Message Processing Subsystem modifies or utilizes the contents of the > > cache is message-processing-model-specific. > > > > This may sound underspecified, but keep in mind that a message > > processing model might have access to all the information from the > > cache and from the message, and have no need to call a Security Model > > to do any processing; an application might choose a Security Model > > such as USM to authenticate and secure the SNMP message, but also > > utilize a secure transport such as that provided by the SSH Transport > > Model to send the message to its destination. > > > > specifically the wording "an application...". > > Applications in our RFC3411 context are CG or CR or NO or NR or such. > > I am sure that is not intended here. But then, what is an "application" > > in this sentence above? >=20 > Why not? Is it not these applications which specify a=20 > security model/name/level and transport domain and address? =20 > If an application selects USM security parameters and an SSH=20 > transport address, it has effectively chosen the use of USM and SSH. >=20 Mmm... I am less concerned now.. but still have an uneasy feeling. Need to go lookup details before I can put words around it... or maybe if I do my concerns go away. >=20 > > I am also not sure we should speak about the MPM to "not call a=20 > > security model". From our architectural point of view, the MPM will=20 > > ALWAYS call a security model. If an implementation does a shortcut,=20 > > that is up to them... but should we discuss that here? >=20 > I agree. Even if a new MPM were defined in the future, to=20 > specify situations when using that MPM in which the security=20 > model is not called would seem to violate the architecture. >=20 ack Bert > -- Jeff >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 05:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x9-0008HY-71; Thu, 23 Aug 2007 05:26:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008Gd-Q1 for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IO8x5-0000s4-Vi for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7N9Pk8Y009010; Thu, 23 Aug 2007 04:26:02 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 04:25:48 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 11:25:44 +0200 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] More questions on Security name Date: Thu, 23 Aug 2007 11:25:36 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] More questions on Security name Thread-Index: Acfjsz0k5y18ve4xSVKYzIztTb71EgACmncwAFWmZ9AAFGfSYA== References: From: "Wijnen, Bert \(Bert\)" To: "Joseph Salowey \(jsalowey\)" , X-OriginalArrivalTime: 23 Aug 2007 09:25:44.0277 (UTC) FILETIME=[94B72050:01C7E567] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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 Bert Wijnen =20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 > Sent: Thursday, August 23, 2007 1:51 AM > To: Wijnen, Bert (Bert); isms@ietf.org > Subject: RE: [Isms] More questions on Security name >=20 > Thanks Bert, >=20 > This is helpful. Comments inline:=20 >=20 >=20 > > Bert Wijnen > >=20 > > > -----Original Message----- > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > Sent: Tuesday, August 21, 2007 7:22 AM > > > To: isms@ietf.org > > > Subject: [Isms] More questions on Security name > > >=20 >=20 > >=20 > >=20 > > > A security > > > name may be used on a notification generator to determine if the=20 > > > notification receiver is authorized to receive a message=20 > (security=20 > > > name applies to notification receiver). > > >=20 > > Nope. The securityName gets mapped into a groupName and=20 > together with=20 > > securityLevel and securityModel, the VACM tables control if all the=20 > > object-instances included in the notifications can indeed=20 > be accessed=20 > > and if so they will be sent as varBinds in the notification. > >=20 > > On the receiving end there is no "access control". >=20 > [Joe] OK, this is where I have been confused. What entity=20 > does the security name represent? I seems like it represents=20 > the user on the notification receiver. There is no access=20 > control on the receiving end, but on the sending end there is=20 > access control based on who the message is being sent to. =20 > So, when sending a notification you need to authenticate that=20 > the receiver is the 'user' you are authorized to send to. Correct? =20 >=20 I think so. However "authorzied to send to"... you can send whatever you want, if the keys don't match, the receiver won't be able to decrypt (for authPriv messages). And authentication would fail too, and so the message would get dropped. But the data of=20 course did get to the destination, and if unencruptes, trhen they can read. So access control checks if the data can indeed be send to the destination based on securityName, securityModel, securityLevel. For notifications it is important to understand we have 2 types: - TRAPv2 (traps, unconfirmed notifications). They get sent from agent to manager and we have no idea if they ever arrive, we do not get a response. - INFORM (confirmed notification). They get sent from agent to manager, and we DO get a response so we know if the notification gg/pipermail/isms> List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Inline Bert Wijnen =20 > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 > Sent: Thursday, August 23, 2007 12:07 AM > To: Wijnen, Bert (Bert);=20 > j.schoenwaelder@jacobs-university.de; David Harrington > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: Re: [Isms] tmStateReference in draft-ietf-isms-tmsm-09.txt=20 >=20 >=20 >=20 > On Wednesday, August 08, 2007 12:17:56 PM +0200 "Wijnen, Bert (Bert)"=20 > wrote: >=20 > > > > I am confused by the last 2 paragraphs in sect 6.2 > > > > The prepareOutgoingMessage ASI passes tmStateReference from the > > Message Processing Subsystem to the dispatcher. How or if the > > Message Processing Subsystem modifies or utilizes the contents of the > > cache is message-processing-model-specific. > > > > This may sound underspecified, but keep in mind that a message > > processing model might have access to all the information from the > > cache and from the message, and have no need to call a Security Model > > to do any processing; an application might choose a Security Model > > such as USM to authenticate and secure the SNMP message, but also > > utilize a secure transport such as that provided by the SSH Transport > > Model to send the message to its destination. > > > > specifically the wording "an application...". > > Applications in our RFC3411 context are CG or CR or NO or NR or such. > > I am sure that is not intended here. But then, what is an "application" > > in this sentence above? >=20 > Why not? Is it not these applications which specify a=20 > security model/name/level and transport domain and address? =20 > If an application selects USM security parameters and an SSH=20 > transport address, it has effectively chosen the use of USM and SSH. >=20 Mmm... I am less concerned now.. but still have an uneasy feeling. Need to go lookup details before I can put words around it... or maybe if I do my concerns go away. >=20 > > I am also not sure we should speak about the MPM to "not call a=20 > > security model". From our architectural point of view, the MPM will=20 > > ALWAYS call a security model. If an implementation does a shortcut,=20 > > that is up to them... but should we discuss that here? >=20 > I agree. Even if a new MPM were defined in the future, to=20 > specify situations when using that MPM in which the security=20 > model is not called would seem to violate the architecture. >=20 ack Bert > -- Jeff >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 05:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x9-0008HY-71; Thu, 23 Aug 2007 05:26:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008Gd-Q1 for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IO8x5-0000s4-Vi for isms@ietf.org; Thu, 23 Aug 2007 05:26:08 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7N9Pk8Y009010; Thu, 23 Aug 2007 04:26:02 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 04:25:48 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 11:25:44 +0200 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] More questions on Security name Date: Thu, 23 Aug 2007 11:25:36 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] More questions on Security name Thread-Index: Acfjsz0k5y18ve4xSVKYzIztTb71EgACmncwAFWmZ9AAFGfSYA== References: From: "Wijnen, Bert \(Bert\)" To: "Joseph Salowey \(jsalowey\)" , X-OriginalArrivalTime: 23 Aug 2007 09:25:44.0277 (UTC) FILETIME=[94B72050:01C7E567] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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 Bert Wijnen =20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 > Sent: Thursday, August 23, 2007 1:51 AM > To: Wijnen, Bert (Bert); isms@ietf.org > Subject: RE: [Isms] More questions on Security name >=20 > Thanks Bert, >=20 > This is helpful. Comments inline:=20 >=20 >=20 > > Bert Wijnen > >=20 > > > -----Original Message----- > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > Sent: Tuesday, August 21, 2007 7:22 AM > > > To: isms@ietf.org > > > Subject: [Isms] More questions on Security name > > >=20 >=20 > >=20 > >=20 > > > A security > > > name may be used on a notification generator to determine if the=20 > > > notification receiver is authorized to receive a message=20 > (security=20 > > > name applies to notification receiver). > > >=20 > > Nope. The securityName gets mapped into a groupName and=20 > together with=20 > > securityLevel and securityModel, the VACM tables control if all the=20 > > object-instances included in the notifications can indeed=20 > be accessed=20 > > and if so they will be sent as varBinds in the notification. > >=20 > > On the receiving end there is no "access control". >=20 > [Joe] OK, this is where I have been confused. What entity=20 > does the security name represent? I seems like it represents=20 > the user on the notification receiver. There is no access=20 > control on the receiving end, but on the sending end there is=20 > access control based on who the message is being sent to. =20 > So, when sending a notification you need to authenticate that=20 > the receiver is the 'user' you are authorized to send to. Correct? =20 >=20 I think so. However "authorzied to send to"... you can send whatever you want, if the keys don't match, the receiver won't be able to decrypt (for authPriv messages). And authentication would fail too, and so the message would get dropped. But the data of=20 course did get to the destination, and if unencruptes, trhen they can read. So access control checks if the data can indeed be send to the destination based on securityName, securityModel, securityLevel. For notifications it is important to understand we have 2 types: - TRAPv2 (traps, unconfirmed notifications). They get sent from agent to manager and we have no idea if they ever arrive, we do not get a response. - INFORM (confirmed notification). They get sent from agent to manager, and we DO get a response so we know if the notification got deleivered (at least delivered to the SNMP engine). In both cases, access control (that is checking if the object instances=20 in the notification are accessible for the specific securityName, securityModel and securityLevel. If not, the process stops. If yes, the process continues. For a TRAPv2, that is it. if access control says "OK send it", then the trap (with data) gets sent and that is all we know. We have no idea what gets done at the manager side. At the manager side, the only thing that happens is that it checks (based on the securityName) the authentication and decodes the encrypted message. If the securityName/password(key in fact) is not in sync, the message gets dropped. If we ever find out (not specifie dhow we can=20 find this out) we must assume that the key at the agent is correct and so to fix it we need to fix the key at the manager (or generate new keys to get them in sync). For an INFORM, the process is basically the same. But now the manager sends=20 a response. And if the passwords do not match, then the manager sends a REPORT PDU and so we know it did not work. In this case, the assumption is that the password/key at the manager side is correct (authoritative) and so the key on the agent needs to be changed (or new shared key needs to be generated). > >=20 > > > In SSH, generally there is more than one entity identity involved. > > > One entity is identified by a SSH user authentication > > (username) and > > > another is identified by SSH server authentication (IP > > address/domain > > > name). > > >=20 > >=20 > > The userName (in the msgUserName in the UsmSecurityParameters, see=20 > > RFC3414 sect 2.4) gets translated into securtyName (1 to 1, identity > > function) and then gets used to do the authentication, and privacy=20 > > en/decription) Specifically, here it is important to know about the=20 > > authoritative side. As stated above, normally it is the agent, but for=20 > > INFORM PDUs it is the notofication receiver (running at the manager). > >=20 >=20 > [Joe] OK, this seems consistent with above.=20 >=20 > > > Some of the difficulty around securityName may originate > > from this. =20 > > > We may need to split up securityName into two pieces, but > > this seems > > > like it would have some impact on SNMP, although maybe it > > would always > > > be clear which name is used in particular case. > >=20 > > In SNMP with USM, you basically only have one side that is=20 > > authoritative (in each communication, that is per exchange=20 > of a SNMP=20 > > PDU pair (request/response), based on a shared msgUserName=20 > secret. In=20 > > case of a TRAPv2-PDU there is just one-way, so no response. > >=20 > > I am leaving the REPORT PDUs out of the discussion for now. > > I think such is OK. > >=20 > > > Another option (well really it probably maps to the same > > thing) is to > > > treat the mutual authentication as a single securityName such as=20 > > > something like joeuser@snmpssh.example.com. This seems > > like it would > > > affect how authorization is set up in VACM. > > >=20 > >=20 > > I believe that USM uses the msgUserName/password indeed as a mutual=20 > > authentication (see description above and let me know if you agree). > >=20 > [Joe] yes, in a way USM uses the msgUserName/password as=20 > mutual authentication. More specifically it uses a secret=20 > derived from the msgUserName/Password/(and perhaps=20 > AuthoritativeEngineID) to perform mutual authentication. =20 yep. The authoritativeEnginID is used to localize the keys so that they are separate for every authoritative engine (mostly agents). That way, if one agent gets comrpomised, the keys don't give you access to other agents. >=20 > > > If other people are as confused as me then perhaps we need > > to have a > > > section in the document that describes the interaction with=20 > > > authorization. > > >=20 > >=20 > > Hope my comments helped. > >=20 > [Joe] They did, now I need to go back and try and make sense=20 > of it all.=20 >=20 Have fun ;-) Bert > > Bert > > > Joe > > >=20 > > > _______________________ses:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] More questions on Security name Date: Thu, 23 Aug 2007 11:25:36 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] More questions on Security name Thread-Index: Acfjsz0k5y18ve4xSVKYzIztTb71EgACmncwAFWmZ9AAFGfSYA== References: From: "Wijnen, Bert \(Bert\)" To: "Joseph Salowey \(jsalowey\)" , X-OriginalArrivalTime: 23 Aug 2007 09:25:44.0277 (UTC) FILETIME=[94B72050:01C7E567] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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 Bert Wijnen =20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 > Sent: Thursday, August 23, 2007 1:51 AM > To: Wijnen, Bert (Bert); isms@ietf.org > Subject: RE: [Isms] More questions on Security name >=20 > Thanks Bert, >=20 > This is helpful. Comments inline:=20 >=20 >=20 > > Bert Wijnen > >=20 > > > -----Original Message----- > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > Sent: Tuesday, August 21, 2007 7:22 AM > > > To: isms@ietf.org > > > Subject: [Isms] More questions on Security name > > >=20 >=20 > >=20 > >=20 > > > A security > > > name may be used on a notification generator to determine if the=20 > > > notification receiver is authorized to receive a message=20 > (security=20 > > > name applies to notification receiver). > > >=20 > > Nope. The securityName gets mapped into a groupName and=20 > together with=20 > > securityLevel and securityModel, the VACM tables control if all the=20 > > object-instances included in the notifications can indeed=20 > be accessed=20 > > and if so they will be sent as varBinds in the notification. > >=20 > > On the receiving end there is no "access control". >=20 > [Joe] OK, this is where I have been confused. What entity=20 > does the security name represent? I seems like it represents=20 > the user on the notification receiver. There is no access=20 > control on the receiving end, but on the sending end there is=20 > access control based on who the message is being sent to. =20 > So, when sending a notification you need to authenticate that=20 > the receiver is the 'user' you are authorized to send to. Correct? =20 >=20 I think so. However "authorzied to send to"... you can send whatever you want, if the keys don't match, the receiver won't be able to decrypt (for authPriv messages). And authentication would fail too, and so the message would get dropped. But the data of=20 course did get to the destination, and if unencruptes, trhen they can read. So access control checks if the data can indeed be send to the destination based on securityName, securityModel, securityLevel. For notifications it is important to understand we have 2 types: - TRAPv2 (traps, unconfirmed notifications). They get sent from agent to manager and we have no idea if they ever arrive, we do not get a response. - INFORM (confirmed notification). They get sent from agent to manager, and we DO get a response so we know if the notification got deleivered (at least delivered to the SNMP engine). In both cases, access control (that is checking if the object instances=20 in the notification are accessible for the specific securityName, securityModel and securityLevel. If not, the process stops. If yes, the process continues. For a TRAPv2, that is it. if access control says "OK send it", then the trap (with data) gets sent and that is all we know. We have no idea what gets done at the manager side. At the manager side, the only thing that happens is that it checks (based on the securityName) the authentication and decodes the encrypted message. If the securityName/password(key in fact) is not in sync, the message gets dropped. If we ever find out (not specifie dhow we can=20 find this out) we must assume that the key at the agent is correct and so to fix it we need to fix the key at the manager (or generate new keys to get them in sync). For an INFORM, the process is basically the same. But now the manager sends=20 a response. And if the passwords do not match, then the manager sends a REPORT PDU and so we know it did not work. In this case, the assumption is that the password/key at the manager side is correct (authoritative) and so the key on the agent needs to be changed (or new shared key needs to be generated). > >=20 > > > In SSH, generally there is more than one entity identity involved. > > > One entity is identified by a SSH user authentication > > (username) and > > > another is identified by SSH server authentication (IP > > address/domain > > > name). > > >=20 > >=20 > > The userName (in the msgUserName in the UsmSecurityParameters, see=20 > > RFC3414 sect 2.4) gets translated into securtyName (1 to 1, identity > > function) and then gets used to do the authentication, and privacy=20 > > en/decription) Specifically, here it is important to know about the=20 > > authoritative side. As stated above, normally it is the agent, but for=20 > > INFORM PDUs it is the notofication receiver (running at the manager). > >=20 >=20 > [Joe] OK, this seems consistent with above.=20 >=20 > > > Some of the difficulty around securityName may originate > > from this. =20 > > > We may need to split up securityName into two pieces, but > > this seems > > > like it would have some impact on SNMP, although maybe it > > would always > > > be clear which name is used in particular case. > >=20 > > In SNMP with USM, you basically only have one side that is=20 > > authoritative (in each communication, that is per exchange=20 > of a SNMP=20 > > PDU pair (request/response), based on a shared msgUserName=20 > secret. In=20 > > case of a TRAPv2-PDU there is just one-way, so no response. > >=20 > > I am leaving the REPORT PDUs out of the discussion for now. > > I think such is OK. > >=20 > > > Another option (well really it probably maps to the same > > thing) is to > > > treat the mutual authentication as a single securityName such as=20 > > > something like joeuser@snmpssh.example.com. This seems > > like it would > > > affect how authorization is set up in VACM. > > >=20 > >=20 > > I believe that USM uses the msgUserName/password indeed as a mutual=20 > > authentication (see description above and let me know if you agree). > >=20 > [Joe] yes, in a way USM uses the msgUserName/password as=20 > mutual authentication. More specifically it uses a secret=20 > derived from the msgUserName/Password/(and perhaps=20 > AuthoritativeEngineID) to perform mutual authentication. =20 yep. The authoritativeEnginID is used to localize the keys so that they are separate for every authoritative engine (mostly agents). That way, if one agent gets comrpomised, the keys don't give you access to other agents. >=20 > > > If other people are as confused as me then perhaps we need > > to have a > > > section in the document that describes the interaction with=20 > > > authorization. > > >=20 > >=20 > > Hope my comments helped. > >=20 > [Joe] They did, now I need to go back and try and make sense=20 > of it all.=20 >=20 Have fun ;-) Bert > > Bert > > > Joe > > >=20 > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > >=20 > >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms ot deleivered (at least delivered to the SNMP engine). In both cases, access control (that is checking if the object instances=20 in the notification are accessible for the specific securityName, securityModel and securityLevel. If not, the process stops. If yes, the process continues. For a TRAPv2, that is it. if access control says "OK send it", then the trap (with data) gets sent and that is all we know. We have no idea what gets done at the manager side. At the manager side, the only thing that happens is that it checks (based on the securityName) the authentication and decodes the encrypted message. If the securityName/password(key in fact) is not in sync, the message gets dropped. If we ever find out (not specifie dhow we can=20 find this out) we must assume that the key at the agent is correct and so to fix it we need to fix the key at the manager (or generate new keys to get them in sync). For an INFORM, the process is basically the same. But now the manager sends=20 a response. And if the passwords do not match, then the manager sends a REPORT PDU and so we know it did not work. In this case, the assumption is that the password/key at the manager side is correct (authoritative) and so the key on the agent needs to be changed (or new shared key needs to be generated). > >=20 > > > In SSH, generally there is more than one entity identity involved. > > > One entity is identified by a SSH user authentication > > (username) and > > > another is identified by SSH server authentication (IP > > address/domain > > > name). > > >=20 > >=20 > > The userName (in the msgUserName in the UsmSecurityParameters, see=20 > > RFC3414 sect 2.4) gets translated into securtyName (1 to 1, identity > > function) and then gets used to do the authentication, and privacy=20 > > en/decription) Specifically, here it is important to know about the=20 > > authoritative side. As stated above, normally it is the agent, but for=20 > > INFORM PDUs it is the notofication receiver (running at the manager). > >=20 >=20 > [Joe] OK, this seems consistent with above.=20 >=20 > > > Some of the difficulty around securityName may originate > > from this. =20 > > > We may need to split up securityName into two pieces, but > > this seems > > > like it would have some impact on SNMP, although maybe it > > would always > > > be clear which name is used in particular case. > >=20 > > In SNMP with USM, you basically only have one side that is=20 > > authoritative (in each communication, that is per exchange=20 > of a SNMP=20 > > PDU pair (request/response), based on a shared msgUserName=20 > secret. In=20 > > case of a TRAPv2-PDU there is just one-way, so no response. > >=20 > > I am leaving the REPORT PDUs out of the discussion for now. > > I think such is OK. > >=20 > > > Another option (well really it probably maps to the same > > thing) is to > > > treat the mutual authentication as a single securityName such as=20 > > > something like joeuser@snmpssh.example.com. This seems > > like it would > > > affect how authorization is set up in VACM. > > >=20 > >=20 > > I believe that USM uses the msgUserName/password indeed as a mutual=20 > > authentication (see description above and let me know if you agree). > >=20 > [Joe] yes, in a way USM uses the msgUserName/password as=20 > mutual authentication. More specifically it uses a secret=20 > derived from the msgUserName/Password/(and perhaps=20 > AuthoritativeEngineID) to perform mutual authentication. =20 yep. The authoritativeEnginID is used to localize the keys so that they are separate for every authoritative engine (mostly agents). That way, if one agent gets comrpomised, the keys don't give you access to other agents. >=20 > > > If other people are as confused as me then perhaps we need > > to have a > > > section in the document that describes the interaction with=20 > > > authorization. > > >=20 > >=20 > > Hope my comments helped. > >=20 > [Joe] They did, now I need to go back and try and make sense=20 > of it all.=20 >=20 Have fun ;-) Bert > > Bert > > > Joe > > >=20 > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > >=20 > >=20 >=20 _______________________________________________ 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 > > >=20 > >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 05:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x6-0008Ge-RQ; Thu, 23 Aug 2007 05:26:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8x5-0008GO-H9 for isms@ietf.org; Thu, 23 Aug 2007 05:26:07 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO8x4-00015u-7u for isms@ietf.org; Thu, 23 Aug 2007 05:26:07 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l7N9Pk8U009010; Thu, 23 Aug 2007 04:25:54 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 04:25:49 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 11:25:45 +0200 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] my review of: draft-ietf-isms-secshell-08.txt Date: Thu, 23 Aug 2007 11:25:44 +0200 Message-ID: In-Reply-To: <539D70CF464B36159F3434D8@sirius.fac.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] my review of: draft-ietf-isms-secshell-08.txt Thread-Index: AcflC50REyWoSnK7Quq/bxm2LKW+bgAWJEVA References: <539D70CF464B36159F3434D8@sirius.fac.cs.cmu.edu> From: "Wijnen, Bert \(Bert\)" To: "Jeffrey Hutzelman" , "David Harrington" , X-OriginalArrivalTime: 23 Aug 2007 09:25:45.0387 (UTC) FILETIME=[95607FB0:01C7E567] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 Inline Bert Wijnen =20 > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 > Sent: Thursday, August 23, 2007 12:22 AM > To: Wijnen, Bert (Bert); David Harrington; jsalowey@cisco.com > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: Re: [Isms] my review of: draft-ietf-isms-secshell-08.txt >=20 >=20 >=20 > On Thursday, August 09, 2007 12:17:13 PM +0200 "Wijnen, Bert (Bert)"=20 > wrote: >=20 > > - sect 5.1 and 5.1 > > I assume that SSH_MSG_USERAUTH_REQUEST and SSH_MSG_CHANNEL_DATA > > are specified somewhere in the SSH RFC(s)? Maybe a citation to > > such RFC(s) is useful at these points. >=20 > Yes; those are SSH protocol messages. It's actually not=20 > clear that SSH messages should be referenced explicitly here;=20 > instead, we should be talking about SSH at a rather higher=20 > layer. For example, SSH user authentication can be a fairly=20 > complex negotiation; it doesn't involve sending just one=20 > message. Similarly, outside the SSH protocol channels are=20 > presented as streams, not sequences of SSH_MSG_CHANNEL_DATA=20 > messages, and in particular you can't assume that your=20 > messages will be sent in a single channel data message or=20 > infer the size of an incoming message from the underlying SSH=20 > protocol messages. >=20 > Similarly, if you are establishing a separate SSH connection=20 > for every session, you don't need data from the SSH channel=20 > open/confirmation messages, and in fact generally such data=20 > will not be available to you as it is buried in the details=20 > of the SSH protocol. If you are establishing multiple=20 > channels over the same SSH session, then you may need to know=20 > which channel is which, but this is almost certainly done=20 > using identifiers provided to you by your SSH implementation=20 > (perhaps even file descriptors) and not necessarily using SSH=20 > protocol data. >=20 OK, so some clarification seems to make sense then. >=20 >=20 > > - For SnmpSSHAddress ::=3D TEXTUAL-CONVENTION I read: > > > > "Represents either a hostname encoded in ASCII > > using the IDNA protocol, as specified in RFC3490, followed by > > a colon ':' (ASCII character 0x3A) and a decimal port number > > in ASCII, or an IP address followed by a colon ':' > > (ASCII character 0x3A) and a decimal port number in ASCII. > > The name SHOULD be fully qualified whenever possible. > > > > I am not well versed/experienced in IDNA. But is IDNA a protocol? >=20 > That is a semantic question, which I'd just as soon not argue here. > Perhaps we could say "as specified by IDNA [RFC3490]" ? >=20 that would be better I think >=20 > > The title of 3490 reads > > Internationalizing Domain Names in Applications (IDNA) > > And are we indeed speaking of a hostname, or of a domain name, or > > of both? I can't quickly determine that. So I wonder if/hope that > > we can be clearer here. >=20 > We are talking about a hostname, but hostnames are domain=20 > names (however, not all domain names are valid hostnames). >=20 So we mean a FQDN that represents a hostname? So just "myhostname" would not be OK, it would have to be "myhostname@example.com"? I guess we want to be somehwat more specific then. And don't we nee dto specify when we expect such a name to be resolved into an IP address? >=20 >=20 > > I also assume (although this is not explicitly stated) that if we > > speak about an IP address, that it is a dotted decimal for > > IPv4 and and a colon separated IPv6 address in ASCII? Yes/no? >=20 > In fact, I think we are in trouble if, for an IPv6 address, we don't mean a=20 > colon-separated address with brackets around it. Otherwise it may become=20 > rather difficult to determine where the port starts, or if it=20 > is present! >=20 So let us be somewhat more explicit as to how then addresses are formatted. Bert > -- Jeff >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 08:04:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBOj-0004iy-3J; Thu, 23 Aug 2007 08:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBOg-0004gx-Tu for isms@ietf.org; Thu, 23 Aug 2007 08:02:46 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOBOf-0003xY-T5 for isms@ietf.org; Thu, 23 Aug 2007 08:02:46 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc13) with SMTP id <20070823120244b1300edoroe>; Thu, 23 Aug 2007 12:02:45 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , "'Joseph Salowey \(jsalowey\)'" , References: Subject: RE: [Isms] More questions on Security name Date: Thu, 23 Aug 2007 08:02:37 -0400 Message-ID: <015401c7e57d$7fed4f80$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acfjsz0k5y18ve4xSVKYzIztTb71EgACmncwAFWmZ9AAFGfSYAAEsSvQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 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 Joe and Bert are discussing two potentially different scenarios. Joe is asking questions that may be architectural or may be SSH-specific. Bert is answering from a USM standpoint. The USM-specific way is not an accurate reflectoion of the architectural requirements. For example, the WG decided that "authoritative" is USM-specific, not architectural. It is important to keep the distinction between one model's approach and the architectural requirements. The issue of whether we need to authenticate the "user" who will recieve notifications over an SSH transport has been discussed multiple times already. It was included in the presentation at IETF67. We held a teleconference to discuss the issue. The issue is that, while USM establishes a symmetric security relationship using shared passwords, SSH has an asymmetric security relationship; it authenticates a server on one side, and a user on the other side, and these differ in granularity. If the chair is aware of consensus on how to authenticate the "user" that is the notification receiver, then please speak up. As I recall, no solution was found to this issue. I think we reached consensus that 1) if a client had already established a connection, so we have a relevant securityname, then that connection could be reused for notiications. 2) if a notification needs to be sent, and no SSH connection exists, then the transport model will try to create a connection. How the credentials are supplied, and how the connectionis created is implementation-specific. The slides from IETF67 present three options for doing this, which may or may not work. 3) if a notification needs to be sent, and no SSH connection exists, then the agent can use USM to send the notification. This is implementation-specific. That's my understanding of where we stand on this issue. dbh > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > Sent: Thursday, August 23, 2007 5:26 AM > To: Joseph Salowey (jsalowey); isms@ietf.org > Subject: RE: [Isms] More questions on Security name > > Inline > > Bert Wijnen > > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > Sent: Thursday, August 23, 2007 1:51 AM > > To: Wijnen, Bert (Bert); isms@ietf.org > > Subject: RE: [Isms] More questions on Security name > > > > Thanks Bert, > > > > This is helpful. Comments inline: > > > > > > > Bert Wijnen > > > > > > > -----Original Message----- > > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > > Sent: Tuesday, August 21, 2007 7:22 AM > > > > To: isms@ietf.org > > > > Subject: [Isms] More questions on Security name > > > > > > > > > > > > > > > > > A security > > > > name may be used on a notification generator to > determine if the > > > > notification receiver is authorized to receive a message > > (security > > > > name applies to notification receiver). > > > > > > > Nope. The securityName gets mapped into a groupName and > > together with > > > securityLevel and securityModel, the VACM tables control > if all the > > > object-instances included in the notifications can indeed > > be accessed > > > and if so they will be sent as varBinds in the notification. > > > > > > On the receiving end there is no "access control". > > > > [Joe] OK, this is where I have been confused. What entity > > does the security name represent? I seems like it represents > > the user on the notification receiver. There is no access > > control on the receiving end, but on the sending end there is > > access control based on who the message is being sent to. > > So, when sending a notification you need to authenticate that > > the receiver is the 'user' you are authorized to send to. > Correct? > > > > I think so. However "authorzied to send to"... you can send > whatever you want, if the keys don't match, the receiver > won't be able to decrypt (for authPriv messages). And authentication > would fail too, and so the message would get dropped. But the data of > course did get to the destination, and if unencruptes, trhen they can > read. > > So access control checks if the data can indeed be send to the > destination > based on securityName, securityModel, securityLevel. > > > For notifications it is important to understand we have 2 types: > - TRAPv2 (traps, unconfirmed notifications). They get sent > from agent to manager and we have no idea if they ever arrive, we > do not get a response. > - INFORM (confirmed notification). They get sent from agent > to manager, and we DO get a response so we know if the notification > got deleivered (at least delivered to the SNMP engine). > > In both cases, access control (that is checking if the object > instances > in the notification are accessible for the specific securityName, > securityModel > and securityLevel. If not, the process stops. If yes, the process > continues. > > For a TRAPv2, that is it. if access control says "OK send > it", then the > trap > (with data) gets sent and that is all we know. We have no > idea what gets > done at the manager side. At the manager side, the only thing that > happens is > that it checks (based on the securityName) the authentication and > decodes > the encrypted message. If the securityName/password(key in > fact) is not > in > sync, the message gets dropped. If we ever find out (not specifie dhow > we can > find this out) we must assume that the key at the agent is correct and > so to > fix it we need to fix the key at the manager (or generate new keys to > get > them in sync). > > For an INFORM, the process is basically the same. But now the manager > sends > a response. And if the passwords do not match, then the > manager sends a > REPORT PDU and so we know it did not work. In this case, the > assumption > is > that the password/key at the manager side is correct > (authoritative) and > so the key on the agent needs to be changed (or new shared > key needs to > be generated). > > > > > > > > > In SSH, generally there is more than one entity > identity involved. > > > > > One entity is identified by a SSH user authentication > > > (username) and > > > > another is identified by SSH server authentication (IP > > > address/domain > > > > name). > > > > > > > > > > The userName (in the msgUserName in the > UsmSecurityParameters, see > > > RFC3414 sect 2.4) gets translated into securtyName (1 to > 1, identity > > > > function) and then gets used to do the authentication, > and privacy > > > en/decription) Specifically, here it is important to know > about the > > > authoritative side. As stated above, normally it is the agent, but > for > > > INFORM PDUs it is the notofication receiver (running at the > manager). > > > > > > > [Joe] OK, this seems consistent with above. > > > > > > Some of the difficulty around securityName may originate > > > from this. > > > > We may need to split up securityName into two pieces, but > > > this seems > > > > like it would have some impact on SNMP, although maybe it > > > would always > > > > be clear which name is used in particular case. > > > > > > In SNMP with USM, you basically only have one side that is > > > authoritative (in each communication, that is per exchange > > of a SNMP > > > PDU pair (request/response), based on a shared msgUserName > > secret. In > > > case of a TRAPv2-PDU there is just one-way, so no response. > > > > > > I am leaving the REPORT PDUs out of the discussion for now. > > > I think such is OK. > > > > > > > Another option (well really it probably maps to the same > > > thing) is to > > > > treat the mutual authentication as a single > securityName such as > > > > something like joeuser@snmpssh.example.com. This seems > > > like it would > > > > affect how authorization is set up in VACM. > > > > > > > > > > I believe that USM uses the msgUserName/password indeed > as a mutual > > > authentication (see description above and let me know if > you agree). > > > > > [Joe] yes, in a way USM uses the msgUserName/password as > > mutual authentication. More specifically it uses a secret > > derived from the msgUserName/Password/(and perhaps > > AuthoritativeEngineID) to perform mutual authentication. > > yep. The authoritativeEnginID is used to localize the keys so that > they are separate for every authoritative engine (mostly agents). > That way, if one agent gets comrpomised, the keys don't give you > access to other agents. > > > > > > If other people are as confused as me then perhaps we need > > > to have a > > > > section in the document that describes the interaction with > > > > authorization. > > > > > > > > > > Hope my comments helped. > > > > > [Joe] They did, now I need to go back and try and make sense > > of it all. > > > > Have fun ;-) > Bert > > > Bert > > > > Joe > > > > > > > > _______________________________________________ > > > > 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 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 09:02:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOCJ1-0003kB-RF; Thu, 23 Aug 2007 09:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOCJ0-0003k5-SP for isms@ietf.org; Thu, 23 Aug 2007 09:00:58 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOCIz-0004y6-H8 for isms@ietf.org; Thu, 23 Aug 2007 09:00:58 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l7ND0dtK007565; Thu, 23 Aug 2007 08:00:51 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 08:00:32 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 15:00:30 +0200 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] More questions on Security name Date: Thu, 23 Aug 2007 14:55:48 +0200 Message-ID: In-Reply-To: <015401c7e57d$7fed4f80$6702a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] More questions on Security name Thread-Index: Acfjsz0k5y18ve4xSVKYzIztTb71EgACmncwAFWmZ9AAFGfSYAAEsSvQAAJl3YA= References: <015401c7e57d$7fed4f80$6702a8c0@china.huawei.com> From: "Wijnen, Bert \(Bert\)" To: "David Harrington" , "Joseph Salowey \(jsalowey\)" , X-OriginalArrivalTime: 23 Aug 2007 13:00:30.0076 (UTC) FILETIME=[954003C0:01C7E585] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 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 Bert Wijnen =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Thursday, August 23, 2007 2:03 PM > To: Wijnen, Bert (Bert); 'Joseph Salowey (jsalowey)'; isms@ietf.org > Subject: RE: [Isms] More questions on Security name >=20 > Hi, >=20 > I think Joe and Bert are discussing two potentially different scenarios. > Joe is asking questions that may be architectural or may be SSH-specific. > Bert is answering from a USM standpoint. >=20 > The USM-specific way is not an accurate reflectoion of the architectural requirements. > For example, the WG decided that "authoritative" is USM-specific, not architectural. > It is important to keep the distinction between one model's approach and the architectural requirements. >=20 You are correct. My appology.=20 Now to my defense, I believe Joe was asking if he understood USM correctly. For example he asked: > In USM it appears that there is a single SecurityName representing=20 > both sides of a conversation, is this true and is this true of SNMPv3=20 > in general. >=20 And I jumped on my USM explanation, forgetting the "is this true of SNMPv3 in general". I think we need to look architectural for "SNMPv3 in general". So the authoritative part of my comments should be ignore in terms of architectural impact. Again, I wish those who argued so vehemently in favor of making the receiving end of an INFORM authoritative were participating. There was (I believe, but do not recall details) more to it than just=20 USM. But in our current archtecture and documents, indeed the architecture does not speak of authoritative sides. Only USM does. > The issue of whether we need to authenticate the "user" who=20 > will recieve notifications over an SSH transport has been=20 > discussed multiple times already. It was included in the=20 > presentation at IETF67. > We held a teleconference to discuss the issue. The issue is=20 > that, while USM establishes a symmetric security relationship=20 > using shared passwords, SSH has an asymmetric security=20 > relationship; it authenticates a server on one side, and a=20 > user on the other side, and these differ in granularity. So I guess that the server is (for most PDUs) the agent and the user is the principal at the manager side? But such may not be true for notifications, right? > If=20 > the chair is aware of consensus on how to authenticate the=20 > "user" that is the notification receiver, then please speak up.=20 >=20 > As I recall, no solution was found to this issue. I think we=20 > reached consensus that > 1) if a client had already established a connection, so we=20 > have a relevant securityname, then that connection could be=20 > reused for notiications.=20 So that sounds as if we assume the same "user" on both ends in this case. > 2) if a notification needs to be sent, and no SSH connection=20 > exists, then the transport model will try to create a=20 > connection. How the credentials are supplied, and how the=20 > connectionis created is implementation-specific. The slides=20 > from IETF67 present three options for doing this, which may=20 > or may not work. Do we state anywhere that this case is implementation specific and that we have no pre-scribed details/approach? That seems the least we can do. > 3) if a notification needs to be sent, and no SSH connection=20 > exists, then the agent can use USM to send the notification.=20 > This is implementation-specific. >=20 Yep, that can always be done. It would eliminate a lot of the reasons why we are working on an SSH based solution... but oh well. > That's my understanding of where we stand on this issue. >=20 So I am not clear then if we have consensus on the issue. Chair? Bert > dbh > =20 >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > Sent: Thursday, August 23, 2007 5:26 AM > > To: Joseph Salowey (jsalowey); isms@ietf.org > > Subject: RE: [Isms] More questions on Security name > >=20 > > Inline > >=20 > > Bert Wijnen > >=20 > > > -----Original Message----- > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > Sent: Thursday, August 23, 2007 1:51 AM > > > To: Wijnen, Bert (Bert); isms@ietf.org > > > Subject: RE: [Isms] More questions on Security name > > >=20 > > > Thanks Bert, > > >=20 > > > This is helpful. Comments inline:=20 > > >=20 > > >=20 > > > > Bert Wijnen > > > >=20 > > > > > -----Original Message----- > > > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > > > Sent: Tuesday, August 21, 2007 7:22 AM > > > > > To: isms@ietf.org > > > > > Subject: [Isms] More questions on Security name > > > > >=20 > > >=20 > > > > > >=20 > > > >=20 > > > > > A security > > > > > name may be used on a notification generator to > > determine if the > > > > > notification receiver is authorized to receive a message > > > (security > > > > > name applies to notification receiver). > > > > >=20 > > > > Nope. The securityName gets mapped into a groupName and > > > together with > > > > securityLevel and securityModel, the VACM tables control > > if all the > > > > object-instances included in the notifications can indeed > > > be accessed > > > > and if so they will be sent as varBinds in the notification. > > > >=20 > > > > On the receiving end there is no "access control". > > >=20 > > > [Joe] OK, this is where I have been confused. What=20 > entity does the=20 > > > security name represent? I seems like it represents the=20 > user on the=20 > > > notification receiver. There is no access control on the=20 > receiving=20 > > > end, but on the sending end there is access control based=20 > on who the=20 > > > message is being sent to. > > > So, when sending a notification you need to authenticate that the=20 > > > receiver is the 'user' you are authorized to send to. > > Correct? =20 > > >=20 > >=20 > > I think so. However "authorzied to send to"... you can send=20 > whatever=20 > > you want, if the keys don't match, the receiver won't be able to=20 > > decrypt (for authPriv messages). And authentication would fail too,=20 > > and so the message would get dropped. But the data > of=20 > > course did get to the destination, and if unencruptes, trhen they > can > > read. > >=20 > > So access control checks if the data can indeed be send to the=20 > > destination based on securityName, securityModel, securityLevel. > >=20 > >=20 > > For notifications it is important to understand we have 2 types: > > - TRAPv2 (traps, unconfirmed notifications). They get sent > > from agent to manager and we have no idea if they ever arrive, we > > do not get a response. > > - INFORM (confirmed notification). They get sent from agent > > to manager, and we DO get a response so we know if the > notification > > got deleivered (at least delivered to the SNMP engine). > >=20 > > In both cases, access control (that is checking if the object=20 > > instances in the notification are accessible for the specific=20 > > securityName, securityModel and securityLevel. If not, the process=20 > > stops. If yes, the process continues. > >=20 > > For a TRAPv2, that is it. if access control says "OK send it", then=20 > > the trap (with data) gets sent and that is all we know. We have no=20 > > idea what gets done at the manager side. At the manager=20 > side, the only=20 > > thing that happens is that it checks (based on the=20 > securityName) the=20 > > authentication and decodes the encrypted message. If the=20 > > securityName/password(key in > > fact) is not > > in > > sync, the message gets dropped. If we ever find out (not specifie > dhow > > we can > > find this out) we must assume that the key at the agent is correct > and > > so to > > fix it we need to fix the key at the manager (or generate new keys > to > > get > > them in sync). > >=20 > > For an INFORM, the process is basically the same. But now the > manager > > sends > > a response. And if the passwords do not match, then the=20 > manager sends=20 > > a REPORT PDU and so we know it did not work. In this case, the=20 > > assumption is that the password/key at the manager side is correct > > (authoritative) and > > so the key on the agent needs to be changed (or new shared=20 > key needs=20 > > to be generated). > >=20 > >=20 > > > >=20 > > > > > In SSH, generally there is more than one entity > > identity involved. > >=20 > > > > > One entity is identified by a SSH user authentication > > > > (username) and > > > > > another is identified by SSH server authentication (IP > > > > address/domain > > > > > name). > > > > >=20 > > > >=20 > > > > The userName (in the msgUserName in the > > UsmSecurityParameters, see > > > > RFC3414 sect 2.4) gets translated into securtyName (1 to > > 1, identity > >=20 > > > > function) and then gets used to do the authentication, > > and privacy > > > > en/decription) Specifically, here it is important to know > > about the > > > > authoritative side. As stated above, normally it is the agent, > but > > for > > > > INFORM PDUs it is the notofication receiver (running at the > > manager). > > > >=20 > > >=20 > > > [Joe] OK, this seems consistent with above.=20 > > >=20 > > > > > Some of the difficulty around securityName may originate > > > > from this. =20 > > > > > We may need to split up securityName into two pieces, but > > > > this seems > > > > > like it would have some impact on SNMP, although maybe it > > > > would always > > > > > be clear which name is used in particular case. > > > >=20 > > > > In SNMP with USM, you basically only have one side that is=20 > > > > authoritative (in each communication, that is per exchange > > > of a SNMP > > > > PDU pair (request/response), based on a shared msgUserName > > > secret. In > > > > case of a TRAPv2-PDU there is just one-way, so no response. > > > >=20 > > > > I am leaving the REPORT PDUs out of the discussion for now. > > > > I think such is OK. > > > >=20 > > > > > Another option (well really it probably maps to the same > > > > thing) is to > > > > > treat the mutual authentication as a single > > securityName such as > > > > > something like joeuser@snmpssh.example.com. This seems > > > > like it would > > > > > affect how authorization is set up in VACM. > > > > >=20 > > > >=20 > > > > I believe that USM uses the msgUserName/password indeed > > as a mutual > > > > authentication (see description above and let me know if > > you agree). > > > >=20 > > > [Joe] yes, in a way USM uses the msgUserName/password as mutual=20 > > > authentication. More specifically it uses a secret=20 > derived from the=20 > > > msgUserName/Password/(and perhaps > > > AuthoritativeEngineID) to perform mutual authentication. =20 > >=20 > > yep. The authoritativeEnginID is used to localize the keys so that=20 > > they are separate for every authoritative engine (mostly agents). > > That way, if one agent gets comrpomised, the keys don't give you=20 > > access to other agents. > > >=20 > > > > > If other people are as confused as me then perhaps we need > > > > to have a > > > > > section in the document that describes the interaction with=20 > > > > > authorization. > > > > >=20 > > > >=20 > > > > Hope my comments helped. > > > >=20 > > > [Joe] They did, now I need to go back and try and make=20 > sense of it=20 > > > all. > > >=20 > >=20 > > Have fun ;-) > > Bert > > > > Bert > > > > > Joe > > > > >=20 > > > > > _______________________________________________ > > > > > Isms mailing list > > > > > Isms@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > >=20 > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > >=20 >=20 >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 10:42:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IODrg-0004kR-Gm; Thu, 23 Aug 2007 10:40:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IODrf-0004kK-RU for isms@ietf.org; Thu, 23 Aug 2007 10:40:51 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IODrf-0007bW-IK for isms@ietf.org; Thu, 23 Aug 2007 10:40:51 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa15785; 23 Aug 2007 10:40 EDT Date: Thu, 23 Aug 2007 10:40:23 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: David Harrington Subject: RE: [Isms] Working Group Last Call - securityName In-Reply-To: <013001c7e54d$3fa32f10$6702a8c0@china.huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 'ISMS WG' 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 Thu, 23 Aug 2007, David Harrington wrote: > The MPM doesn't know what the security parameters are; the > securityParmeters in the message are opaque to the MPM; those are only > unpacked by the security model. So the security model has to be the > one to ave security state. Sure, but information about what session was used isn't security state; it's transport state. > > > > I actually think it would be acceptable to say you can't use > > the USM over > > SSH combination if the security parameters don't match. > > What security parameters do you want to "match"? I mean, the securityName and securityLevel derived from ssh must be the same as those used by USM. If that is true, then the procedure as currently written will find the correct session for the response, if there is one. If not, it won't, because at least for ssh, you can't _have_ more than one incoming session with the same transport address. And by "can't use", I don't mean an explicit prohibition, just that it won't work. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 10:42:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IODrl-0004lk-Kl; Thu, 23 Aug 2007 10:40:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IODrk-0004le-Eg for isms@ietf.org; Thu, 23 Aug 2007 10:40:56 -0400 Received: from alnrmhc14.comcast.net ([206.18.177.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IODrj-0007bj-0A for isms@ietf.org; Thu, 23 Aug 2007 10:40:56 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20070823144054b1400phvvte>; Thu, 23 Aug 2007 14:40:54 +0000 From: "David Harrington" To: "'Wijnen, Bert \(Bert\)'" , "'Joseph Salowey \(jsalowey\)'" , References: <015401c7e57d$7fed4f80$6702a8c0@china.huawei.com> Subject: RE: [Isms] More questions on Security name Date: Thu, 23 Aug 2007 10:40:48 -0400 Message-ID: <015c01c7e593$98d5f360$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acfjsz0k5y18ve4xSVKYzIztTb71EgACmncwAFWmZ9AAFGfSYAAEsSvQAAJl3YAAAofIoA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 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. > So the authoritative part of my comments should be ignore in terms of > architectural impact. > Again, I wish those who argued so vehemently in favor of making the > receiving end of an INFORM authoritative were participating. > There was (I believe, but do not recall details) more to it than just > USM. But in our current archtecture and documents, indeed the > architecture > does not speak of authoritative sides. Only USM does. I think there may have been a number of motivations for the authoritative difference. The main one in my mind is the use of clocks to detect timeliness, to help prevent replay. There are certain attacks that can be launched using replay, and causing the re-synchronization of clocks. It is important to check timeliness using the correct clock, and it is important to sync using the right clock. > > > The issue of whether we need to authenticate the "user" who > > will recieve notifications over an SSH transport has been > > discussed multiple times already. It was included in the > > presentation at IETF67. > > We held a teleconference to discuss the issue. The issue is > > that, while USM establishes a symmetric security relationship > > using shared passwords, SSH has an asymmetric security > > relationship; it authenticates a server on one side, and a > > user on the other side, and these differ in granularity. > > So I guess that the server is (for most PDUs) the agent and > the user is the principal at the manager side? > > But such may not be true for notifications, right? Abstractly, the clock "authoritative" issue is kind of like server versus client authentication. You want to make sure the attacker doesn't get to "authenticate" himself. In SSH for R/R traffic, the agent is the server, and the manager is the client, and the manager-client must prove he is authentic before the agent-server permits access to the data. But in the notification situation, if the agent gets to be the SSH client, then the agent-client is proving to itself it is authentic? (i.e., the agent has the user credentials to prove it is authentic); this isn't useful because the agent already has access to the data. We never authenticate the manager's "user identity" to determine if they are allowed to receive the potentially sensitive data. Now, we can approach it that for notifications, the manager-client needs to prove authenticity. But if no connection has been established, the agent-server needs to initiate the connection and force user-auth. I think that is unnatural SSH. > > > If > > the chair is aware of consensus on how to authenticate the > > "user" that is the notification receiver, then please speak up. > > > > As I recall, no solution was found to this issue. I think we > > reached consensus that > > 1) if a client had already established a connection, so we > > have a relevant securityname, then that connection could be > > reused for notiications. > > So that sounds as if we assume the same "user" on both ends in this > case. No. The user is on one side only. In option #1, the manager-client end represents the user, and if we have an established connection, the manager-client must have created it for R/R traffic and already proved itself authentic to the agent-server using SSH user-auth. The server-agent can now reuse that existing connection as an authenticated connection to the user that is the target for the notification. If no connection exists, then the manager-agent cannot create one to send notifications. (The option#1 scenario is like Netconf notifications; the client must initiate the subscription; it is never initiated by the server.) > > > 2) if a notification needs to be sent, and no SSH connection > > exists, then the transport model will try to create a > > connection. How the credentials are supplied, and how the > > connectionis created is implementation-specific. The slides > > from IETF67 present three options for doing this, which may > > or may not work. > > Do we state anywhere that this case is implementation specific and > that we have no pre-scribed details/approach? That seems the least > we can do. I am not sure allowing this is good security. We, the experts in SNMP requirements for security, have not figured out how to accomplish this. I am not certain we want to permit any implementation-specific approach to be used here, since it could compromise the security of the whole system. Creating the conection from the agent can be done three ways: 1) the agent-server can try to initiate a connection to a manager-client, which may o rmay not be legal SSH 2) the agent-client can establish a connection to a manager server, but the "user" is on the wrong side for authorization to be useful; and this means the client credentials need to be kept on the agent side somehow, which would defeat the purpose of ISMS. 3) a call-home mechanism is used, where the agent-server contacts the manager-client and says "call me", and then the manager-client-user authenticates itself, a connection is established, and then we can follow option#1 and reuse that connection for notifications. > > > 3) if a notification needs to be sent, and no SSH connection > > exists, then the agent can use USM to send the notification. > > This is implementation-specific. We could develop a "call-home" notification that the SNMP agent can send to the SNMP manager using USM (or even v1/v2c trivial security), to cause the manager-client to create an SSH connection to the agent-server, which could subsequently be used for notifications over SSH. (Actually, the call-home notification could specify in varbinds which transportDomain/address/securityName/level and which securityModel, needs a connection, so it could be used for TLS or other transports, and for other security models. I'm not sure I feel comfortable reusing connections assuming correct authentication given that we have no way to check what SSH authn was actually done (i.e. it could be null set up by an attacker). And, of course, a call-home over v1/v2c could be used for DoS. dbh > > > Yep, that can always be done. > It would eliminate a lot of the reasons why we are working on an > SSH based solution... but oh well. > > > That's my understanding of where we stand on this issue. > > > > So I am not clear then if we have consensus on the issue. > > Chair? > > Bert > > dbh > > > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > > Sent: Thursday, August 23, 2007 5:26 AM > > > To: Joseph Salowey (jsalowey); isms@ietf.org > > > Subject: RE: [Isms] More questions on Security name > > > > > > Inline > > > > > > Bert Wijnen > > > > > > > -----Original Message----- > > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > > Sent: Thursday, August 23, 2007 1:51 AM > > > > To: Wijnen, Bert (Bert); isms@ietf.org > > > > Subject: RE: [Isms] More questions on Security name > > > > > > > > Thanks Bert, > > > > > > > > This is helpful. Comments inline: > > > > > > > > > > > > > Bert Wijnen > > > > > > > > > > > -----Original Message----- > > > > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > > > > Sent: Tuesday, August 21, 2007 7:22 AM > > > > > > To: isms@ietf.org > > > > > > Subject: [Isms] More questions on Security name > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A security > > > > > > name may be used on a notification generator to > > > determine if the > > > > > > notification receiver is authorized to receive a message > > > > (security > > > > > > name applies to notification receiver). > > > > > > > > > > > Nope. The securityName gets mapped into a groupName and > > > > together with > > > > > securityLevel and securityModel, the VACM tables control > > > if all the > > > > > object-instances included in the notifications can indeed > > > > be accessed > > > > > and if so they will be sent as varBinds in the notification. > > > > > > > > > > On the receiving end there is no "access control". > > > > > > > > [Joe] OK, this is where I have been confused. What > > entity does the > > > > security name represent? I seems like it represents the > > user on the > > > > notification receiver. There is no access control on the > > receiving > > > > end, but on the sending end there is access control based > > on who the > > > > message is being sent to. > > > > So, when sending a notification you need to > authenticate that the > > > > receiver is the 'user' you are authorized to send to. > > > Correct? > > > > > > > > > > I think so. However "authorzied to send to"... you can send > > whatever > > > you want, if the keys don't match, the receiver won't be able to > > > decrypt (for authPriv messages). And authentication would > fail too, > > > and so the message would get dropped. But the data > > of > > > course did get to the destination, and if unencruptes, trhen they > > can > > > read. > > > > > > So access control checks if the data can indeed be send to the > > > destination based on securityName, securityModel, securityLevel. > > > > > > > > > For notifications it is important to understand we have 2 types: > > > - TRAPv2 (traps, unconfirmed notifications). They get sent > > > from agent to manager and we have no idea if they ever > arrive, we > > > do not get a response. > > > - INFORM (confirmed notification). They get sent from agent > > > to manager, and we DO get a response so we know if the > > notification > > > got deleivered (at least delivered to the SNMP engine). > > > > > > In both cases, access control (that is checking if the object > > > instances in the notification are accessible for the specific > > > securityName, securityModel and securityLevel. If not, > the process > > > stops. If yes, the process continues. > > > > > > For a TRAPv2, that is it. if access control says "OK send > it", then > > > the trap (with data) gets sent and that is all we know. > We have no > > > idea what gets done at the manager side. At the manager > > side, the only > > > thing that happens is that it checks (based on the > > securityName) the > > > authentication and decodes the encrypted message. If the > > > securityName/password(key in > > > fact) is not > > > in > > > sync, the message gets dropped. If we ever find out (not specifie > > dhow > > > we can > > > find this out) we must assume that the key at the agent is correct > > and > > > so to > > > fix it we need to fix the key at the manager (or generate new keys > > to > > > get > > > them in sync). > > > > > > For an INFORM, the process is basically the same. But now the > > manager > > > sends > > > a response. And if the passwords do not match, then the > > manager sends > > > a REPORT PDU and so we know it did not work. In this case, the > > > assumption is that the password/key at the manager side is correct > > > (authoritative) and > > > so the key on the agent needs to be changed (or new shared > > key needs > > > to be generated). > > > > > > > > > > > > > > > > > In SSH, generally there is more than one entity > > > identity involved. > > > > > > > > > One entity is identified by a SSH user authentication > > > > > (username) and > > > > > > another is identified by SSH server authentication (IP > > > > > address/domain > > > > > > name). > > > > > > > > > > > > > > > > The userName (in the msgUserName in the > > > UsmSecurityParameters, see > > > > > RFC3414 sect 2.4) gets translated into securtyName (1 to > > > 1, identity > > > > > > > > function) and then gets used to do the authentication, > > > and privacy > > > > > en/decription) Specifically, here it is important to know > > > about the > > > > > authoritative side. As stated above, normally it is the agent, > > but > > > for > > > > > INFORM PDUs it is the notofication receiver (running at the > > > manager). > > > > > > > > > > > > > [Joe] OK, this seems consistent with above. > > > > > > > > > > Some of the difficulty around securityName may originate > > > > > from this. > > > > > > We may need to split up securityName into two pieces, but > > > > > this seems > > > > > > like it would have some impact on SNMP, although maybe it > > > > > would always > > > > > > be clear which name is used in particular case. > > > > > > > > > > In SNMP with USM, you basically only have one side that is > > > > > authoritative (in each communication, that is per exchange > > > > of a SNMP > > > > > PDU pair (request/response), based on a shared msgUserName > > > > secret. In > > > > > case of a TRAPv2-PDU there is just one-way, so no response. > > > > > > > > > > I am leaving the REPORT PDUs out of the discussion for now. > > > > > I think such is OK. > > > > > > > > > > > Another option (well really it probably maps to the same > > > > > thing) is to > > > > > > treat the mutual authentication as a single > > > securityName such as > > > > > > something like joeuser@snmpssh.example.com. This seems > > > > > like it would > > > > > > affect how authorization is set up in VACM. > > > > > > > > > > > > > > > > I believe that USM uses the msgUserName/password indeed > > > as a mutual > > > > > authentication (see description above and let me know if > > > you agree). > > > > > > > > > [Joe] yes, in a way USM uses the msgUserName/password as mutual > > > > authentication. More specifically it uses a secret > > derived from the > > > > msgUserName/Password/(and perhaps > > > > AuthoritativeEngineID) to perform mutual authentication. > > > > > > yep. The authoritativeEnginID is used to localize the > keys so that > > > they are separate for every authoritative engine (mostly agents). > > > That way, if one agent gets comrpomised, the keys don't give you > > > access to other agents. > > > > > > > > > > If other people are as confused as me then perhaps we need > > > > > to have a > > > > > > section in the document that describes the interaction with > > > > > > authorization. > > > > > > > > > > > > > > > > Hope my comments helped. > > > > > > > > > [Joe] They did, now I need to go back and try and make > > sense of it > > > > all. > > > > > > > > > > Have fun ;-) > > > Bert > > > > > Bert > > > > > > Joe > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 10:48:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IODxm-00059m-05; Thu, 23 Aug 2007 10:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IODxk-000593-Mb for isms@ietf.org; Thu, 23 Aug 2007 10:47:08 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IODxk-0007lX-DX for isms@ietf.org; Thu, 23 Aug 2007 10:47:08 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa15789; 23 Aug 2007 10:43 EDT Date: Thu, 23 Aug 2007 10:43:01 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "Wijnen, Bert (Bert)" Subject: RE: [Isms] my review of: draft-ietf-isms-secshell-08.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Thu, 23 Aug 2007, Wijnen, Bert (Bert) wrote: > So we mean a FQDN that represents a hostname? > So just "myhostname" would not be OK, it would have to be > "myhostname@example.com"? > I guess we want to be somehwat more specific then. No; it would be "myhostname.example.com", which is both a hostname and a domain name. > And don't we nee dto specify when we expect such a name to be resolved > into > an IP address? I don't think so; that problem is specifically left to SSH, because SSH actually needs to know the hostname in order to do things like checking that you have the right keys. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 23 20:05:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOMeh-0006vQ-Lb; Thu, 23 Aug 2007 20:04:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOMeh-0006vL-3S for isms@ietf.org; Thu, 23 Aug 2007 20:04:03 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOMef-0001fM-KO for isms@ietf.org; Thu, 23 Aug 2007 20:04:03 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 23 Aug 2007 17:04:00 -0700 X-IronPort-AV: i="4.19,302,1183359600"; d="scan'208"; a="516665637:sNHT3499673934" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7O03xun031777; Thu, 23 Aug 2007 17:03:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7O03jlH014270; Fri, 24 Aug 2007 00:03:59 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 17:03:51 -0700 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] More questions on Security name Date: Thu, 23 Aug 2007 17:03:53 -0700 Message-ID: In-Reply-To: <015c01c7e593$98d5f360$6702a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] More questions on Security name Thread-Index: Acfjsz0k5y18ve4xSVKYzIztTb71EgACmncwAFWmZ9AAFGfSYAAEsSvQAAJl3YAAAofIoAAUz6UQ From: "Joseph Salowey \(jsalowey\)" To: "David Harrington" , "Wijnen, Bert \(Bert\)" , X-OriginalArrivalTime: 24 Aug 2007 00:03:51.0960 (UTC) FILETIME=[41058980:01C7E5E2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12567; t=1187913839; x=1188777839; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Isms]=20More=20questions=20on=20Security=20name |Sender:=20; bh=YFtXjVTj2jJqodRwVPFVkan/ueXkLmWyH7rmq3zW4VA=; b=hJ5Ax7PIOgvem/qA44NcUw3EtfmiEGp+QNxf4n2deVMiMf4dMkc3wGI1sO/yNJisCVCqut6L 215l2kiwb8tVDPqpVK5YH5tqzj3+3l1FuF9HGYijgxYW5txEtogk+D3VnFOXcXPKgHQRhYr1Ll PzEX8ObJUiK5G0bNwpmK9cGS0=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c 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 =20 > Creating the conection from the agent can be done three ways: > 1) the agent-server can try to initiate a connection to a=20 > manager-client, which may o rmay not be legal SSH [Joe] If the agent runs a client and the manager a server then this is OK, however I don't believe that SSH allows the server to initiate user authentication so you have the same problem as before. =20 > 2) the agent-client can establish a connection to a manager=20 > server, but the "user" is on the wrong side for authorization=20 > to be useful; and this means the client credentials need to=20 > be kept on the agent side somehow, which would defeat the=20 > purpose of ISMS. [Joe] I agree that this isn't really an acceptable option.=20 > 3) a call-home mechanism is used, where the agent-server=20 > contacts the manager-client and says "call me", and then the=20 > manager-client-user authenticates itself, a connection is=20 > established, and then we can follow option#1 and reuse that=20 > connection for notifications. >=20 [Joe] I think this is the only one of the above options that would work. >=20 > >=20 > > > 3) if a notification needs to be sent, and no SSH=20 > connection exists,=20 > > > then the agent can use USM to send the notification. > > > This is implementation-specific. >=20 > We could develop a "call-home" notification that the SNMP=20 > agent can send to the SNMP manager using USM (or even v1/v2c=20 > trivial security), to cause the manager-client to create an=20 > SSH connection to the agent-server, which could subsequently=20 > be used for notifications over SSH. (Actually, the call-home=20 > notification could specify in varbinds which=20 > transportDomain/address/securityName/level and which=20 > securityModel, needs a connection, so it could be used for=20 > TLS or other transports, and for other security models.=20 >=20 > I'm not sure I feel comfortable reusing connections assuming=20 > correct authentication given that we have no way to check=20 > what SSH authn was actually done (i.e. it could be null set=20 > up by an attacker). >=20 > And, of course, a call-home over v1/v2c could be used for DoS. >=20 [Joe] I think call home functionality would be useful here, however there are details that need to be worked out. Another option may be to change the way the security name is created. Instead of just placing the authenticated username in the securityName you can put the authenticated username and server name, for example: joe@sshsnmp.example.com or joe@123.123.123.123. The SSHSM would only fill in this values if they where truly authenticated. Then your group mappings would need to be based on the combined user@server securityName instead of just username. This is not so neat because then you transport address becomes part of the security name, but I think it might work. =20 > dbh >=20 > > >=20 > > Yep, that can always be done. > > It would eliminate a lot of the reasons why we are working=20 > on an SSH=20 > > based solution... but oh well. > >=20 > > > That's my understanding of where we stand on this issue. > > >=20 > >=20 > > So I am not clear then if we have consensus on the issue. > >=20 > > Chair? > >=20 > > Bert > > > dbh > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@alcatel-lucent.com] > > > > Sent: Thursday, August 23, 2007 5:26 AM > > > > To: Joseph Salowey (jsalowey); isms@ietf.org > > > > Subject: RE: [Isms] More questions on Security name > > > >=20 > > > > Inline > > > >=20 > > > > Bert Wijnen > > > >=20 > > > > > -----Original Message----- > > > > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > > > > Sent: Thursday, August 23, 2007 1:51 AM > > > > > To: Wijnen, Bert (Bert); isms@ietf.org > > > > > Subject: RE: [Isms] More questions on Security name > > > > >=20 > > > > > Thanks Bert, > > > > >=20 > > > > > This is helpful. Comments inline:=20 > > > > >=20 > > > > >=20 > > > > > > Bert Wijnen > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Joseph Salowey (jsalowey) > [mailto:jsalowey@cisco.com] > > > > > > > Sent: Tuesday, August 21, 2007 7:22 AM > > > > > > > To: isms@ietf.org > > > > > > > Subject: [Isms] More questions on Security name > > > > > > >=20 > > > > >=20 > > > > > > > > > >=20 > > > > > >=20 > > > > > > > A security > > > > > > > name may be used on a notification generator to > > > > determine if the > > > > > > > notification receiver is authorized to receive a message > > > > > (security > > > > > > > name applies to notification receiver). > > > > > > >=20 > > > > > > Nope. The securityName gets mapped into a groupName and > > > > > together with > > > > > > securityLevel and securityModel, the VACM tables control > > > > if all the > > > > > > object-instances included in the notifications can indeed > > > > > be accessed > > > > > > and if so they will be sent as varBinds in the notification. > > > > > >=20 > > > > > > On the receiving end there is no "access control". > > > > >=20 > > > > > [Joe] OK, this is where I have been confused. What > > > entity does the > > > > > security name represent? I seems like it represents the > > > user on the > > > > > notification receiver. There is no access control on the > > > receiving > > > > > end, but on the sending end there is access control based > > > on who the > > > > > message is being sent to. > > > > > So, when sending a notification you need to > > authenticate that the > > > > > receiver is the 'user' you are authorized to send to. > > > > Correct? =20 > > > > >=20 > > > >=20 > > > > I think so. However "authorzied to send to"... you can send > > > whatever > > > > you want, if the keys don't match, the receiver won't be able to >=20 > > > > decrypt (for authPriv messages). And authentication would=20 > > fail too,=20 > > > > and so the message would get dropped. But the data > > > of=20 > > > > course did get to the destination, and if unencruptes, trhen > they > > > can > > > > read. > > > >=20 > > > > So access control checks if the data can indeed be send to the=20 > > > > destination based on securityName, securityModel, securityLevel. > > > >=20 > > > >=20 > > > > For notifications it is important to understand we have 2 types: > > > > - TRAPv2 (traps, unconfirmed notifications). They get sent > > > > from agent to manager and we have no idea if they ever=20 > > arrive, we > > > > do not get a response. > > > > - INFORM (confirmed notification). They get sent from agent > > > > to manager, and we DO get a response so we know if the > > > notification > > > > got deleivered (at least delivered to the SNMP engine). > > > >=20 > > > > In both cases, access control (that is checking if the object=20 > > > > instances in the notification are accessible for the specific=20 > > > > securityName, securityModel and securityLevel. If not,=20 > > the process=20 > > > > stops. If yes, the process continues. > > > >=20 > > > > For a TRAPv2, that is it. if access control says "OK send=20 > > it", then=20 > > > > the trap (with data) gets sent and that is all we know.=20 > > We have no=20 > > > > idea what gets done at the manager side. At the manager=20 > > > side, the only=20 > > > > thing that happens is that it checks (based on the=20 > > > securityName) the=20 > > > > authentication and decodes the encrypted message. If the=20 > > > > securityName/password(key in > > > > fact) is not > > > > in > > > > sync, the message gets dropped. If we ever find out (not > specifie > > > dhow > > > > we can > > > > find this out) we must assume that the key at the agent is > correct > > > and > > > > so to > > > > fix it we need to fix the key at the manager (or generate new > keys > > > to > > > > get > > > > them in sync). > > > >=20 > > > > For an INFORM, the process is basically the same. But now the > > > manager > > > > sends > > > > a response. And if the passwords do not match, then the=20 > > > manager sends=20 > > > > a REPORT PDU and so we know it did not work. In this case, the=20 > > > > assumption is that the password/key at the manager side is > correct > > > > (authoritative) and > > > > so the key on the agent needs to be changed (or new shared=20 > > > key needs=20 > > > > to be generated). > > > >=20 > > > >=20 > > > > > >=20 > > > > > > > In SSH, generally there is more than one entity > > > > identity involved. > > > >=20 > > > > > > > One entity is identified by a SSH user authentication > > > > > > (username) and > > > > > > > another is identified by SSH server authentication (IP > > > > > > address/domain > > > > > > > name). > > > > > > >=20 > > > > > >=20 > > > > > > The userName (in the msgUserName in the > > > > UsmSecurityParameters, see > > > > > > RFC3414 sect 2.4) gets translated into securtyName (1 to > > > > 1, identity > > > >=20 > > > > > > function) and then gets used to do the authentication, > > > > and privacy > > > > > > en/decription) Specifically, here it is important to know > > > > about the > > > > > > authoritative side. As stated above, normally it is the > agent, > > > but > > > > for > > > > > > INFORM PDUs it is the notofication receiver (running at the > > > > manager). > > > > > >=20 > > > > >=20 > > > > > [Joe] OK, this seems consistent with above.=20 > > > > >=20 > > > > > > > Some of the difficulty around securityName may originate > > > > > > from this. =20 > > > > > > > We may need to split up securityName into two pieces, but > > > > > > this seems > > > > > > > like it would have some impact on SNMP, although maybe it > > > > > > would always > > > > > > > be clear which name is used in particular case. > > > > > >=20 > > > > > > In SNMP with USM, you basically only have one side that is=20 > > > > > > authoritative (in each communication, that is per exchange > > > > > of a SNMP > > > > > > PDU pair (request/response), based on a shared msgUserName > > > > > secret. In > > > > > > case of a TRAPv2-PDU there is just one-way, so no response. > > > > > >=20 > > > > > > I am leaving the REPORT PDUs out of the discussion for now. > > > > > > I think such is OK. > > > > > >=20 > > > > > > > Another option (well really it probably maps to the same > > > > > > thing) is to > > > > > > > treat the mutual authentication as a single > > > > securityName such as > > > > > > > something like joeuser@snmpssh.example.com. This seems > > > > > > like it would > > > > > > > affect how authorization is set up in VACM. > > > > > > >=20 > > > > > >=20 > > > > > > I believe that USM uses the msgUserName/password indeed > > > > as a mutual > > > > > > authentication (see description above and let me know if > > > > you agree). > > > > > >=20 > > > > > [Joe] yes, in a way USM uses the msgUserName/password as > mutual=20 > > > > > authentication. More specifically it uses a secret=20 > > > derived from the=20 > > > > > msgUserName/Password/(and perhaps > > > > > AuthoritativeEngineID) to perform mutual authentication. =20 > > > >=20 > > > > yep. The authoritativeEnginID is used to localize the=20 > > keys so that=20 > > > > they are separate for every authoritative engine (mostly > agents). > > > > That way, if one agent gets comrpomised, the keys don't give you >=20 > > > > access to other agents. > > > > >=20 > > > > > > > If other people are as confused as me then perhaps we need > > > > > > to have a > > > > > > > section in the document that describes the interaction > with=20 > > > > > > > authorization. > > > > > > >=20 > > > > > >=20 > > > > > > Hope my comments helped. > > > > > >=20 > > > > > [Joe] They did, now I need to go back and try and make=20 > > > sense of it=20 > > > > > all. > > > > >=20 > > > >=20 > > > > Have fun ;-) > > > > Bert > > > > > > Bert > > > > > > > Joe > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > Isms mailing list > > > > > > > Isms@lists.ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Isms mailing list > > > > Isms@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isms > > > >=20 > > >=20 > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 24 07:57:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOXm0-0003z1-DP; Fri, 24 Aug 2007 07:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOXlz-0003yw-HU for isms@ietf.org; Fri, 24 Aug 2007 07:56:19 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOXly-0006ws-2c for isms@ietf.org; Fri, 24 Aug 2007 07:56:19 -0400 Received: from pc6 (1Cust203.tnt110.lnd4.gbr.da.uu.net [62.188.174.203]) by galaxy.systems.pipex.net (Postfix) with SMTP id DE969E000799; Fri, 24 Aug 2007 12:56:15 +0100 (BST) Message-ID: <00e501c7e63c$92ed4d00$0601a8c0@pc6> From: "tom.petch" To: "Jeffrey Hutzelman" , "David Harrington" , "'ISMS WG'" References: <037c01c7db3c$9725b520$0601a8c0@pc6> <016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com> <01af01c7dd84$15202c00$0601a8c0@pc6> <000901c7ddd0$79189a20$6702a8c0@china.huawei.com> <021701c7de7e$7ebcdaa0$0601a8c0@pc6> <59165B4D35F9378674A70368@sirius.fac.cs.cmu.edu> Subject: Re: [Isms] Working Group Last Call - securityName Date: Fri, 24 Aug 2007 12:48:19 +0200 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: d0bdc596f8dd1c226c458f0b4df27a88 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 Catching up, inline Tom Petch ----- Original Message ----- From: "Jeffrey Hutzelman" To: "tom.petch" ; "David Harrington" ; "'ISMS WG'" Cc: "Jeffrey Hutzelman" Sent: Wednesday, August 22, 2007 11:50 PM Subject: Re: [Isms] Working Group Last Call - securityName > > On Tuesday, August 14, 2007 04:18:36 PM +0200 "tom.petch" > wrote: > > > tmsm 3.2.1.2. Transport Subsystem and the RFC3411 Architecture > > > > seems clear enough > > > > 1) authenticate the principal, check integrity and timeliness of the > > message, and decrypt the message. [Transport Model] > > 2) translate parameters to model-independent parameters (Transport > > Model) > > > > and below it says > > > > If a message is secured using a secure transport layer, then the > > Transport Model should provide the translation from the authenticated > > identity (e.g., an SSH user name) to the securityName in step 3. > > > > But 3.2.2 gets a whole lot vaguer > > > > 'A Security Model may have multiple > > sources for determining the principal and desired security services, > > and a particular Security Model may or may not utilize the > > securityName mapping and securityLevel made available by the > > Transport Model when deciding the value of the securityName and > > securityLevel to be passed to the Message Processing Model.' > > That's not vague at all; it means exactly what it says. You are quite right; the words are clear and exact; it was my understanding that got vaguer at this point because those words seem to contradict what is said in 3.2.1.2. I read, and read, 3.2.1.2 as saying that the Transport Model translates between a transport level identifier and the (one and only) securityName. I now understand that the securityModel can use a different value for securityName, based on the information it has. For me, 3.2.1.2 does not say that so I think the wording in 3.2.1.2 should be changed to be clearer. So step 2 (referred to as step 3) translates an identity (and it will not necessarity be authenticated, depends on the transport model) to a
proposed
securityName. Then step 5 must in addition translate the proposed securityName into the securityName. (The wording in 3.2.2 changed in -09, introducing this proposed wording, something which I did not take it on board; it spelt out the provisional nature of the work of the transport model and I think that that change needs refelecting in other paragraphs). And, as I have said on previous occasions, I would like distinct, defined terms for these different object (classes). I note that SSHTM defines tmsSecurityName (which I think should be tmSecurityName) and I think this topic would be clearer if tmsm used that term too. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 24 08:39:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOYQC-0000nL-IP; Fri, 24 Aug 2007 08:37:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOYQB-0000nF-8R for isms@ietf.org; Fri, 24 Aug 2007 08:37:51 -0400 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOYQA-0002EM-Mk for isms@ietf.org; Fri, 24 Aug 2007 08:37:50 -0400 Received: from newton603 (c-24-61-11-96.hsd1.nh.comcast.net[24.61.11.96]) by comcast.net (alnrmhc15) with SMTP id <20070824123749b1500a3b8de>; Fri, 24 Aug 2007 12:37:50 +0000 From: "David B. Nelson" To: Date: Fri, 24 Aug 2007 08:37:57 -0400 Message-ID: <01ee01c7e64b$99dfdfb0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfmS5lEoHppAUSiRZa+o4BWqf47Aw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: isms@ietf.org Subject: [Isms] Formal review of draft-ietf-radext-management-authorization-00.txt 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 Now that the draft "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management" has been accepted as a RADEXT WG work item, and has been published in the Internet Drafts repository at http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati on-00.txt, please formally review the document to determine if it is ready for WGLC. Please send comments to this list using the format described in the RADEXT Issues tracker: http://www.drizzle.com/~aboba/RADEXT/. This review period will last until September 14, 2007. At that time issues raised on the list will be resolved. Once all issues are addressed we will start WGLC on the document. This notice is being copied to the ISMS WG list, as this document is a normative dependency for the "RADIUS Usage for SNMP Transport Models" draft being worked on in the ISMS WG. A summary of changes from draft-nelson-radius-management-authorization-05.txt is listed below, and includes resolution of all comments received during the pre-WG work item review: "SNMP View Based Access Control Method (VACM)" --> "SNMP View Based Access Control Model (VACM)" Spelling corrections. "UTF-8 encoded 10646 [RFC2279]" --> "UTF-8 encoded 10646 [RFC3629]" Addition to IANA Considerations Section: "Assignment of additional values for attributes defined in this document are to be processed as described in [RFC3575]." Break References Section into Normative and Informative. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 24 09:34:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOZHB-000495-7Q; Fri, 24 Aug 2007 09:32:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOZHA-00048w-Ke for isms@ietf.org; Fri, 24 Aug 2007 09:32:36 -0400 Received: from alnrmhc14.comcast.net ([204.127.225.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOZH9-0000uQ-Dk for isms@ietf.org; Fri, 24 Aug 2007 09:32:36 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc14) with SMTP id <20070824133234b1400pfr17e>; Fri, 24 Aug 2007 13:32:34 +0000 From: "David Harrington" To: "'tom.petch'" , "'Jeffrey Hutzelman'" , "'ISMS WG'" References: <037c01c7db3c$9725b520$0601a8c0@pc6> <016a01c7db4d$bd2fa710$6702a8c0@china.huawei.com> <01af01c7dd84$15202c00$0601a8c0@pc6> <000901c7ddd0$79189a20$6702a8c0@china.huawei.com> <021701c7de7e$7ebcdaa0$0601a8c0@pc6> <59165B4D35F9378674A70368@sirius.fac.cs.cmu.edu> <00e501c7e63c$92ed4d00$0601a8c0@pc6> Subject: RE: [Isms] Working Group Last Call - securityName Date: Fri, 24 Aug 2007 09:32:27 -0400 Message-ID: <020201c7e653$37290e20$6702a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfmRccNQvkTV26ASSWC11kD7hfKEwADFbug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <00e501c7e63c$92ed4d00$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 > > > > > tmsm 3.2.1.2. Transport Subsystem and the RFC3411 Architecture > > > > > > seems clear enough > > > > > > 1) authenticate the principal, check integrity and > timeliness of the > > > message, and decrypt the message. [Transport Model] > > > 2) translate parameters to model-independent > parameters (Transport > > > Model) > > > [...] > You are quite right; the words are clear and exact; it was my > understanding that > got vaguer at this point because those words seem to > contradict what is said in > 3.2.1.2. I read, and read, 3.2.1.2 as saying that the Transport Model > translates between a transport level identifier and the (one and only) > securityName. I now understand that the securityModel can > use a different > value for securityName, based on the information it has. For > me, 3.2.1.2 does > not say that so I think the wording in 3.2.1.2 should be > changed to be clearer. 3.2.1.1 says: (Note that these lists are simplified for illustrative purposes, and do not represent all details of processing. Transport Models must provide the detailed elements of procedure.) But, I will wordsmsith this to try to make it less ambiguous. 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 Aug 24 12:44:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOcEz-0008U6-E2; Fri, 24 Aug 2007 12:42:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOcEy-0008Pu-2G for isms@ietf.org; Fri, 24 Aug 2007 12:42:32 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IOcEw-0006N1-T3 for isms@ietf.org; Fri, 24 Aug 2007 12:42:32 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa18174; 24 Aug 2007 12:41 EDT Date: Fri, 24 Aug 2007 12:41:47 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "tom.petch" Subject: Re: [Isms] Working Group Last Call - securityName In-Reply-To: <00e501c7e63c$92ed4d00$0601a8c0@pc6> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'ISMS WG' 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, 24 Aug 2007, tom.petch wrote: > So step 2 (referred to as step 3) translates an identity (and it will not > necessarity be authenticated, depends on the transport model) to a >
proposed
securityName. Then step 5 must in addition translate the > proposed securityName into the securityName. I think the intent is that a secure transport model will propose a security name based on some authenticated identity, and any other transport model will not propose one at all. After all, the security model has to decide whether to use that name without knowing the details of the transport model, and it can only do that if it can assume that any proposed name will come from some authenticated identity. I also believe the intent is not so much that the security model will "translate" the name as that it will either use it as-is or not at all. I don't think it's intended that the SM would apply an arbitrary mapping. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 24 14:35:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOdyV-0001DW-AN; Fri, 24 Aug 2007 14:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOdyU-0001DQ-Cj for isms@ietf.org; Fri, 24 Aug 2007 14:33:38 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOdyS-0002I1-TO for isms@ietf.org; Fri, 24 Aug 2007 14:33:38 -0400 Received: from pc6 (1Cust148.tnt9.lnd4.gbr.da.uu.net [62.188.138.148]) by ranger.systems.pipex.net (Postfix) with SMTP id E5264E000376; Fri, 24 Aug 2007 19:33:27 +0100 (BST) Message-ID: <023201c7e674$1194aea0$0601a8c0@pc6> From: "tom.petch" To: "Jeffrey Hutzelman" , "David Harrington" , "'Romascanu, Dan (Dan)'" , References: <00b601c7da8d$98e7a3f0$6702a8c0@china.huawei.com> <16BAB8C5336F57F7054CDF7E@sirius.fac.cs.cmu.edu> Subject: Re: [Isms] WGLCcomments -draft-ietf-isms-transport-security-model-05.txt Date: Fri, 24 Aug 2007 18:16:00 +0200 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: d185fa790257f526fedfd5d01ed9c976 Cc: Jeffrey Hutzelman 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 Tom Petch ----- Original Message ----- From: "Jeffrey Hutzelman" To: "David Harrington" ; "'Romascanu, Dan (Dan)'" ; Cc: "Jeffrey Hutzelman" Sent: Thursday, August 23, 2007 12:34 AM Subject: RE: [Isms] WGLCcomments -draft-ietf-isms-transport-security-model-05.txt > > On Thursday, August 09, 2007 10:00:08 AM -0400 David Harrington > wrote: > > > The issue was raised during WGLC that there is a difference between > > our use of the word authenticate and the glossary in RFC2828. I think > > re-defining the English words will not help the IETF write clear and > > unambiguous specifications. > > Neither will misusing a term of art. The reality is that _every_ technical > field (and here I mean "technical" in the broadest sense) has its own > jargon and "terms of art" which do not always have the same meaning they do > in the mainstream. In security, "authenticate" is one of these terms; the > narrower scope described by RFC2828 is the meaning commonly used in the > security community and it is SNMP that is unusual here. > > That said, I agree that for these documents, consistency with other SNMP > specifications is generally more important than consistency with terms used > in the security community, where the two conflict. However, where there is > _not_ a conflict, consistency with security usage is preferable to taking a > term which has well-established meaning in that community, using it in a > security document in a way which is not consistent with that meaning, and > asserting that it is OK not to call out the difference because your meaning > is the "mainstream English" meaning. > > > > I think it would be a bad idea to require or even claim consistency > > with RFC2828(bis), because it will be tremendously hard to verify that > > every word or phrase covered in RFC2828(bis) is used correctly in the > > document. It is already hard to verify that MUST/SHOULD/MAY are used > > correctly, and RFC2828bis has 300 pages of definitions. > > Certainly. There is no such requirement, and I don't believe there is > general interest within the IETF security community in introducing such a > requirement. RFC2828 and its successor attempt to document terms readers > find, and to encourage writers to be consistent with common usage (where > "common" means within the security community, not the world at large). > However, it is not an internet standard, and while the recent document > received extensive review and input from members of the security > directorate, it reflects the decisions made by its author and _not_ a > consensus of the IETF security area. > > People who want to know more on the state of this might ask the Security > Area Directors for more information or clarification. > I raised the issue of the use of the term authentication in the isms I-D because a security AD ticked me off for being sloppy in my use of the term, for failing to distinguish between the two kinds. This has, perhaps, made me picky over the subject, hence my WGLC comment on the isms I-D, where I see the use of the term as being not as precise as mine was. I quoted RFC2828/RFC4949 in support of my case when perhaps I should have quoted the security AD's e-mail that ticked me off. I do fully (?) understand all the different categories of RFC, the reviews that they have or have not been subjected to and the status of FYI 36 compared to STD0062. I had not appreciated - until very recently - that there was resistance to FYI 36. Whatever, I am content with the outcome. 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 Aug 24 15:12:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOeYF-0003jS-GN; Fri, 24 Aug 2007 15:10:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOeYE-0003j2-Ns for isms@ietf.org; Fri, 24 Aug 2007 15:10:34 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOeYD-0003C8-Fq for isms@ietf.org; Fri, 24 Aug 2007 15:10:34 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l7OJAOp1026226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 15:10:25 -0400 (EDT) Date: Fri, 24 Aug 2007 15:10:24 -0400 From: Jeffrey Hutzelman To: "tom.petch" , David Harrington , "'Romascanu, Dan (Dan)'" , isms@ietf.org Subject: Re: [Isms] WGLCcomments -draft-ietf-isms-transport-security-model-05.txt Message-ID: In-Reply-To: <023201c7e674$1194aea0$0601a8c0@pc6> References: <00b601c7da8d$98e7a3f0$6702a8c0@china.huawei.com> <16BAB8C5336F57F7054CDF7E@sirius.fac.cs.cmu.edu> <023201c7e674$1194aea0$0601a8c0@pc6> Originator-Info: login-token=Mulberry:01tJzSAR4ER3UA50qC5xoCcEsOCSw70EshEQBm6hw=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: 7d33c50f3756db14428398e2bdedd581 Cc: Jeffrey Hutzelman 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, August 24, 2007 06:16:00 PM +0200 "tom.petch" wrote: > I do fully (?) > understand all the different categories of RFC, the reviews that they > have or have not been subjected to and the status of FYI 36 compared to > STD0062. I never meant to imply otherwise. I was just providing some background on this particular document, which could have represented a strong consensus of the security community and still be published in exactly the same way. But in fact, it was not undertaken as a group effort and while the author solicted and received lots of input, he didn't agree with every comment, did not ask for a consensus, and did not represent the document as reflecting such a consensus. Which, BTW, I think is a fine thing -- actually achieving community consensus on such a large glossary would be quite difficult. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 27 18:34:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPn8A-0000lM-B6; Mon, 27 Aug 2007 18:32:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPn89-0000lG-8u for isms@ietf.org; Mon, 27 Aug 2007 18:32:21 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPn87-0008Br-Vm for isms@ietf.org; Mon, 27 Aug 2007 18:32:21 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l7RMW7Fi028216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 18:32:08 -0400 (EDT) Date: Mon, 27 Aug 2007 18:32:07 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Wijnen, Bert (Bert)'" , "'Joseph Salowey (jsalowey)'" , isms@ietf.org Subject: RE: [Isms] More questions on Security name Message-ID: <7BE8AE0B34C905DEB7E8EE51@sirius.fac.cs.cmu.edu> In-Reply-To: <015c01c7e593$98d5f360$6702a8c0@china.huawei.com> References: <015401c7e57d$7fed4f80$6702a8c0@china.huawei.com> <015c01c7e593$98d5f360$6702a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01//TPWWlcRM1LP0faMnL/yJZmBoSGKEhsaf2+NXQ=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Jeffrey Hutzelman 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 Thursday, August 23, 2007 10:40:48 AM -0400 David Harrington wrote: > 2) the agent-client can establish a connection to a manager server, > but the "user" is on the wrong side for authorization to be useful; > and this means the client credentials need to be kept on the agent > side somehow, which would defeat the purpose of ISMS. This approach is actually not entirely useless. In particular, I would expect one common operational practice to be to set up a small number of "collector" systems to receive and log notifications, and possible do something about them. In that scenario, it makes reasonable sense for such a collector to act as an SSH server, and accept connections from devices which act as SSH clients and notification senders. Such connections could be authenticated using any of a number of methods which would not defeat the goals of using existing infrastructure and avoiding the need to provision pairwise keys on every device. For example... - If devices are accepting SSH connections for R/R authenticated using GSS-krb5 and SSH's GSS-API key exchange and user auth methods, then they already have Kerberos principals and keys which can be reused to authenticate outgoing connections for notifications. - If devices are accepting SSH connections for R/R and using one of SSH's public-key-based host key algorithms, they already have a public key pair which can be reused to authenticate outgoing connections. - Obviously, outgoing connections can be authenticated using a password. - And so on... The tricky part here is that the notification originator needs to know (1) what the transport address is of the server (2) the server's identity, for authentication (3) its own identity and credentials In USM, (2) and (3) are summed up in a single securityName and password, which can be used in either direction between a pair of servers. But in other systems, including SSH, they may be distinct. For requests, we resolved this by effecitvely folding (2) into the transport address, and assuming that the securityName is really describing the client's identity. For responses, we still assume that securityName describes the client's identity (that is, the identity of the requestor), but that works out because we require reuse of an existing incoming conection from that requestor. When we get to talking about notifications, it still works to fold (1) and (2) into the transport address, because that is still the address of the agent we want to contact. However, we run into trouble with (3) because SSH needs to know the username of the notification originator, while the architecture seems to assume here that securityName is the name of the notification receiver. In USM that doesn't matter, because the securityName actually names the pair. But for SSH it does; my name is _not_ the same as your name. Obviously it is possible for an implementation to work around this by providing an implementation-specific way to specify the username to be used, or by ignoring the architecture and declaring that for a notification, the username actually describes the NO and not the NR. I imagine there are other possibilities as well. This problem is not unique to SSH; rather, the lack of it is unique (or nearly so) to USM. IMHO that means there is a problem either with the architecture or with our understanding of it, and that problem needs to be solved before a clean solution to authenticating outgoing notifications is possible. However, I would like to see that problem solved, because otherwise I don't see how we can have interoperable transport of notifications using the specifications we are developing, and requiring the use of USM for notifications _does_ defeat the purpose of ISMS. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 27 18:39:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPnD9-0006nm-1c; Mon, 27 Aug 2007 18:37:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPnD7-0006gM-HD for isms@ietf.org; Mon, 27 Aug 2007 18:37:29 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPnD7-00049v-4J for isms@ietf.org; Mon, 27 Aug 2007 18:37:29 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l7RMbJsc028219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 18:37:19 -0400 (EDT) Date: Mon, 27 Aug 2007 18:37:19 -0400 From: Jeffrey Hutzelman To: "Joseph Salowey (jsalowey)" , David Harrington , "Wijnen, Bert (Bert)" , isms@ietf.org Subject: RE: [Isms] More questions on Security name Message-ID: In-Reply-To: References: Originator-Info: login-token=Mulberry:017q9pnVgX3hE6+uEeIS2ZDIUhoMh14+JbJJcCJC8=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (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: 52e1467c2184c31006318542db5614d5 Cc: Jeffrey Hutzelman 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 Thursday, August 23, 2007 05:03:53 PM -0700 "Joseph Salowey (jsalowey)" wrote: >> 3) a call-home mechanism is used, where the agent-server >> contacts the manager-client and says "call me", and then the >> manager-client-user authenticates itself, a connection is >> established, and then we can follow option#1 and reuse that >> connection for notifications. >> > [Joe] I think this is the only one of the above options that would work. That works for the manager-client case, but I expect we've mostly got that covered, because notifications to such a thing are only meaningful while it is still running, in which case it can keep a connection open. I'm much more concerned about the central-collector case. > [Joe] I think call home functionality would be useful here, however > there are details that need to be worked out. Another option may be to > change the way the security name is created. Instead of just placing > the authenticated username in the securityName you can put the > authenticated username and server name, for example: > joe@sshsnmp.example.com or joe@123.123.123.123. The SSHSM would only > fill in this values if they where truly authenticated. Then your group > mappings would need to be based on the combined user@server securityName > instead of just username. This is not so neat because then you > transport address becomes part of the security name, but I think it > might work. Ew. I haven't thought about this enough yet to be able to say whether I think it's a good idea, but my first instinct is to say "Ew". -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 28 15:54:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ77Q-0003oB-9C; Tue, 28 Aug 2007 15:52:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ77P-0003o0-7P for isms@ietf.org; Tue, 28 Aug 2007 15:52:55 -0400 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ77N-0007Va-J4 for isms@ietf.org; Tue, 28 Aug 2007 15:52:55 -0400 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id B64FF82410 for ; Tue, 28 Aug 2007 21:52:52 +0200 (CEST) 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 16763-02; Tue, 28 Aug 2007 21:52:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA63579C5C; Tue, 28 Aug 2007 21:52:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5627E3116ED; Tue, 28 Aug 2007 21:52:43 +0200 (CEST) Date: Tue, 28 Aug 2007 21:52:43 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20070828195243.GB12461@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Subject: [Isms] ietf69 wg meeting minutes 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 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached please find the minutes from the meeting in Chicago. Let me know is something needs to be changed. I will upload the minutes to the proceedings server tomorrow or so. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms-minutes-ietf69.txt" ======================================================= Integrated Security Model for SNMP WG (isms) IETF 69 Chicago Thursday, July 26, 2007, 1510-1610 Taken by Juergen Schoenwaelder ======================================================= Chairs: Juergen Schoenwaelder Juergen Quittek Agenda: 1) Agenda bashing, WG status 2) Discussion of transport subsystem draft 3) Discussion of transport security model draft 4) Discussion of SSH transport model draft 5) Discussion of RADIUS draft 6) Wrap up Documents: - Transport Subsystem for the Simple Network Management Protocol (SNMP) - Transport Security Model for SNMP - Secure Shell Transport Model for SNMP - RADIUS Usage for SNMP SSH Security Model - RADIUS NAS-Management Authorization - Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) - SNMP Context EngineID Discovery Actors: JQ = Juergen Quittek DH = David Harrington DN = David Nelson SH = Sam Hartmanns JH = Jeffrey Hutzelman JS = Joseph Salowey WH = Wes Hardacker ... Summary: The WG has three current WG documents, the Transport Subsystem for SNMP , the Transport Security Model for SNMP , and the Secure Shell Transport Model for SNMP . All of them are in WG last call and completion of them is expected soon. There is one missing WG documents for which already an individual draft exists. At this meeting it was agreed to accept this individual draft as a WG document. Discussion: 1. Agenda and WG Status No changes to the agenda were made. However, the discussion of the three existing WG drafts (agenda items 2-4) was done in a single agenda slot. JQ explained that all core ISMS documents are in WG last call. Two documents had a WG last call earlier, but because of the number of changes applied after receiving comments they are in WG last call again. 2. Discussion of Core ISMS Drafts David Harrington presented the status of the three documents in WG last call and explained the changes applied since the last meeting. JH and WH raised questions concerning the mapping of transport model specific identifiers into the securityName. It was agreed that the simplified identity mapping is deterministic and appropriate for the SSH transport model. WH commented on the recent change to not reject non-empty securityParameters. After some discussion, it was concluded that not checking the securityParameters is the right approach. 3. Discussion of RADIUS Draft David Nelson, co-chair of the Radius Extensions (RADEXT) WG, presented the state of the individual draft on RADIUS Usage for SNMP Transport Models. The WG accepted this draft as a WG document. The next version of it will be submitted as WG document. The document describes how the SSH transport model can be used with Radius. It references another individual document . This defines new RADIUS attributes for ISMS authorization and other purposes. It was discussed whether this should also become an ISMS WG document or if it should become a WG document of the RADEXT WG. Since its scope is more general than ISMS, the consensus was to ask the RADEXT WG to include the document into their charter. A suggestion was made by JH to improve the abstract. Otherwise, JH believes that document seems to be doing the right thing. JH plans to go back an do a full review of the document. 4. Wrap Up JQ steps down as ISMS co-chair and SH thanks him for his contributions to the ISMS working group. SH asks for volunteers to step in as an ISMS WG co-chair. --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --mYCpIKhGyMATD0i+-- From isms-bounces@lists.ietf.org Wed Aug 29 17:35:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQVAt-000064-Cu; Wed, 29 Aug 2007 17:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQVAm-0008VK-T3 for isms@ietf.org; Wed, 29 Aug 2007 17:34:01 -0400 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQVAl-0003R9-Lr for isms@ietf.org; Wed, 29 Aug 2007 17:34:00 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc15) with SMTP id <20070829213358m1500t8akpe>; Wed, 29 Aug 2007 21:33:58 +0000 From: "David Harrington" To: , References: <20070828195243.GB12461@elstar.local> Subject: RE: [Isms] ietf69 wg meeting minutes Date: Wed, 29 Aug 2007 17:34:07 -0400 Message-ID: <021301c7ea84$5524db90$6702a8c0@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: <20070828195243.GB12461@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcfprUWeULcvCjy4S+iT8tuJ/opPDAA1we3Q X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 these minutes look accurate to me. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, August 28, 2007 3:53 PM > To: isms@ietf.org > Subject: [Isms] ietf69 wg meeting minutes > > Hi, > > attached please find the minutes from the meeting in Chicago. Let me > know is something needs to be changed. I will upload the minutes to > the proceedings server tomorrow or so. > > /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