From midcom-bounces@ietf.org Tue Jul 03 14:53: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 1I5nVG-000716-69; Tue, 03 Jul 2007 14:53:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5mx2-0004qf-GY for midcom@ietf.org; Tue, 03 Jul 2007 14:18:12 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5mwo-0007xG-NY for midcom@ietf.org; Tue, 03 Jul 2007 14:18:01 -0400 Received: from localhost (kobe.netlab.nec.de [195.37.70.60]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 468D513CF82; Tue, 3 Jul 2007 20:17:49 +0200 (CEST) Date: Tue, 03 Jul 2007 13:33:21 +0200 From: Juergen Quittek To: midcom@ietf.org Message-ID: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Tim Polk Subject: [midcom] security recommendations in MIDCOM MIB draft X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Dear all, The MIDCOM MIB is progressing and currently under IESG review. Tim Polk made a comment that I would like to discuss here on this list. In the draft, we explicitly state hat a MIDCOM MIB implementation MUST support SNMPv3. However, we pass the responsibility of switching on SNMPv3 to the operator. The operator may still run SNMPv1 or SNMPv2 if security is provided otherwise: "Compliant MIDCOM MIB implementations MUST support SNMPv3 security services including data integrity, data origin authentication and data confidentiality. It is REQUIRED that the implementations support the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 3414 [RFC3414] and the View- based Access Control Model RFC 3415 [RFC3415] is RECOMMENDED. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them." Now, Tim suggests to explicitly deprecate the use of (insecure) previous versions of SNMP, for example with a phrase like "Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security." Are there any opinions about adding such a phrase to the security considerations? Thanks, Juergen -- 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Wed Jul 04 02:30:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5yNZ-00039n-Ve; Wed, 04 Jul 2007 02:30:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5yNZ-00039h-3K for midcom@ietf.org; Wed, 04 Jul 2007 02:30:21 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5yNY-00067O-Hd for midcom@ietf.org; Wed, 04 Jul 2007 02:30:21 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l646TfvP006630; Wed, 4 Jul 2007 09:30:02 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 09:29:59 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 09:29:59 +0300 Received: from [172.21.34.161] (esdhcp034161.research.nokia.com [172.21.34.161]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l646Tv7t015474; Wed, 4 Jul 2007 09:29:57 +0300 In-Reply-To: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D> References: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <01D6CAF6-5E1F-413B-843C-20BFB3D38F79@nokia.com> From: Lars Eggert Subject: Re: [midcom] security recommendations in MIDCOM MIB draft Date: Wed, 4 Jul 2007 09:29:51 +0300 To: ext Juergen Quittek X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Jul 2007 06:29:59.0429 (UTC) FILETIME=[BED78350:01C7BE04] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: midcom@ietf.org, Tim Polk , ops-ads@tools.ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0968832431==" Errors-To: midcom-bounces@ietf.org --===============0968832431== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-17--935038175; protocol="application/pkcs7-signature" --Apple-Mail-17--935038175 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-7-3, at 14:33, ext Juergen Quittek wrote: > Now, Tim suggests to explicitly deprecate the use of (insecure) > previous > versions of SNMP, for example with a phrase like > > "Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. > Instead it is RECOMMENDED to deploy SNMPv3 and to enable > cryptographic security." > > Are there any opinions about adding such a phrase to the security > considerations? This is a general applicability statement on the use of various SNMP versions and extensions, which IMO isn't for MIDCOM to make, at least not without prior review by the OPS area. But given the well-known problems with older versions of SNMP, maybe there already is a statement by the OPS area to that effect that the MIDCOM draft can simply point to? Lars --Apple-Mail-17--935038175 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA3MDQwNjI5NTJaMCMGCSqGSIb3DQEJBDEWBBRckNeifKap/Jx6 JUSrfdcSIqoVCTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAnHPjAhsF+QvvGx+6EEYGHeZwTGakm87pyP+cf8tdp9p52R+aEfMv m/DmObvpkn0Uk/sm5lgHrBWgiSEWaWG9mGYYP6tHEiDvE92NfykZUGciVSQVKfi2zgfNYRCSLIrx 1DR5oEzv17k4mS6042XjOS7D/bZRCHs8ZWhiNp0uH0a60pUOD8cGIieshHvJDfo/9iswMKGXHxM4 SM5KvZH0LSaCcBmuVMDaXuKvE9Y8C9U7Ry0/cBoI0L+8w+Rm+YixUAymoGgUQnu4nWXMpxLzSVHq gC/5ATUIflbeqKLxHKaE9QNFpuXxh38vDaAmyMh//S4EW0hH5BopQqT4zPyGbAAAAAAAAA== --Apple-Mail-17--935038175-- --===============0968832431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom --===============0968832431==-- From midcom-bounces@ietf.org Wed Jul 04 02:49:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ygU-0001No-Lg; Wed, 04 Jul 2007 02:49:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ygT-0001Hp-FP for midcom@ietf.org; Wed, 04 Jul 2007 02:49:53 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5ygN-0004pD-6W for midcom@ietf.org; Wed, 04 Jul 2007 02:49:53 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l646nf5W014250; Wed, 4 Jul 2007 09:49:42 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 09:49:39 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 09:49:38 +0300 Received: from [172.21.34.161] (esdhcp034161.research.nokia.com [172.21.34.161]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l646naN0030327; Wed, 4 Jul 2007 09:49:37 +0300 In-Reply-To: References: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D> <01D6CAF6-5E1F-413B-843C-20BFB3D38F79@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [midcom] security recommendations in MIDCOM MIB draft Date: Wed, 4 Jul 2007 09:49:31 +0300 To: "ext Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Jul 2007 06:49:39.0046 (UTC) FILETIME=[7DF2C860:01C7BE07] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: midcom@ietf.org, Tim Polk , ops-ads@tools.ietf.org X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1809116438==" Errors-To: midcom-bounces@ietf.org --===============1809116438== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-19--933858878; protocol="application/pkcs7-signature" --Apple-Mail-19--933858878 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-7-4, at 9:43, ext Romascanu, Dan (Dan) wrote: > So, I am not sure that I see the problem. The MIDCOM MIB document > seems > to be OK in adopting a strict secure mode SNMPv3 requirement. There is not a problem then. I just wanted to make sure that the MIDCOM MIB doesn't make statements it shouldn't make. > If we need > to discuss a change in the security considerations for other MIB > documents we should discuss this separately. No, that's not what this was about. Thanks! Lars --Apple-Mail-19--933858878 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA3MDQwNjQ5MzFaMCMGCSqGSIb3DQEJBDEWBBTGTEbQ3pIpJ5g1 BwwPSdoIjqbhUzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEALYVyvlMRnWPabbKWP/NDavLEB3Y4686TMkjEwa+hsaYN9uQdXXX4 wR83vnZ/WxjHyPCm05j9huMrnGW+BE8ibhawVt3n5ZrsGwNR4Sg+4C3iFAC7hgKUEAOh4oFtAXie 8Cz5jUzGSlru/JiqYeczak1ig7/yWXbuRNgbllLniqwyyhRw06v7OUdXwMk4uttglVt/jUQJvMvc 89OP4s81bBTK9Mu0s92eiXqCJ8+gmtVvBflcaSTueU+X1cb27ry7ID0qy6ZcP92HeRgljNgC4COF 0OBG1xHffEcEpL1vqiqYCablK2RHztruCrBh+sjqitJiNGVwZBI6aXdMcIi5NgAAAAAAAA== --Apple-Mail-19--933858878-- --===============1809116438== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom --===============1809116438==-- From midcom-bounces@ietf.org Thu Jul 05 07:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6PNy-0006Yi-MP; Thu, 05 Jul 2007 07:20:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6PNx-0006YV-4c for midcom@ietf.org; Thu, 05 Jul 2007 07:20:33 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6PNt-0006eD-Ad for midcom@ietf.org; Thu, 05 Jul 2007 07:20:33 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AE72120C5C; Thu, 5 Jul 2007 13:20:28 +0200 (CEST) X-AuditID: c1b4fb3c-b0e80bb0000007e1-56-468cd3fce704 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9E5C720AF3; Thu, 5 Jul 2007 13:20:28 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 13:20:28 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 13:20:28 +0200 Message-ID: <468CD3FB.4040203@ericsson.com> Date: Thu, 05 Jul 2007 13:20:27 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [midcom] security recommendations in MIDCOM MIB draft References: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D> In-Reply-To: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 11:20:28.0114 (UTC) FILETIME=[7D8F8B20:01C7BEF6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: midcom@ietf.org, Tim Polk X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Juergen Quittek skrev: > Dear all, > > The MIDCOM MIB is progressing and currently under IESG review. > Tim Polk made a comment that I would like to discuss here on this list. > > In the draft, we explicitly state hat a MIDCOM MIB implementation > MUST support SNMPv3. However, we pass the responsibility of switching > on SNMPv3 to the operator. The operator may still run SNMPv1 or SNMPv2 > if security is provided otherwise: > > "Compliant MIDCOM MIB implementations MUST support SNMPv3 security > services including data integrity, data origin authentication and > data confidentiality. > > It is REQUIRED that the implementations support the security features > as provided by the SNMPv3 framework. Specifically, the use of the > User-based Security Model RFC 3414 [RFC3414] and the View- based > Access Control Model RFC 3415 [RFC3415] is RECOMMENDED. > > It is then a customer/operator responsibility to ensure that the SNMP > entity giving access to an instance of this MIB, is properly > configured to give access to the objects only to those principals > (users) that have legitimate rights to indeed GET or SET > (change/create/delete) them." > > Now, Tim suggests to explicitly deprecate the use of (insecure) previous > versions of SNMP, for example with a phrase like > > "Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. > Instead it is RECOMMENDED to deploy SNMPv3 and to enable > cryptographic security." > > Are there any opinions about adding such a phrase to the security > considerations? > To make sure I understand this correctly. Without SNMPv3 and its security functions the MIDCOM MIB will not reach the security requirements identified? If this is true, I think it is quite clear that MIDCOM MIB should only be used with SNMPv3. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Thu Jul 05 14:36: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 1I6WBU-0002kb-Jj; Thu, 05 Jul 2007 14:36:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6W0Z-0008EF-Af for midcom@ietf.org; Thu, 05 Jul 2007 14:24:51 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6W0Y-0001ju-Ao for midcom@ietf.org; Thu, 05 Jul 2007 14:24:51 -0400 Received: from [192.168.1.144] (HSI-KBW-085-216-081-102.hsi.kabelbw.de [85.216.81.102]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 74BB413CF81; Thu, 5 Jul 2007 20:24:25 +0200 (CEST) Date: Thu, 05 Jul 2007 20:24:29 +0200 From: Juergen Quittek To: Magnus Westerlund Subject: Re: [midcom] security recommendations in MIDCOM MIB draft Message-ID: In-Reply-To: <468CD3FB.4040203@ericsson.com> References: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D> <468CD3FB.4040203@ericsson.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) 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: 825e642946eda55cd9bc654a36dab8c2 Cc: midcom@ietf.org, Tim Polk X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Using SNMPv3 is a good way (probably the best) to achieve the level of security required for the MIDCOM MIB. This is why the current draft says that all compliant implementations MUST support it. However, there are scenarios, where an operator may have good reasons for providing the required security by other means. Here are two potential reasons for doing so. - If you already run a logically or physically separated management network that is sufficiently secured against access from the operational network, it may be considered and overhead to also deploy SNMPv3. - Configuring SNMPv3 in a secure way is a complex task and can be really tricky. I did it already in the past and my memory of it is not a pleasant one. Also this is one of the core motivations for the work done in the ISMS WG. So, as an operator, running a few gateways implementing the MIDCOM MIB and a few SIP servers that configure the gateways using the MIDCOM MIB, it might be worth to think about whether to use SNMPv3 for securing it or to apply other means, such as a separate management network (or just secured tunnels between SIP servers and gateways). Sometimes it might be - easier - less error-prone - better matching the skill set of the acting network administrators not to use SNMPv3 (or use SNMPv3 with security disabled), but deploy other means. Even though saying this, I would not like to add a recommendation to the draft stating that in some situations is would be better to provide other means for securing the MIDCOM MIB. I see these scenarios rather as exceptions that may occur and a discussion of other means might be misleading for many readers. But the security considerations section in the drafts leaves the door open to alternatives by just stating "It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them." Please consider also that there are many ways to configuring SNMPv3 security. For example, a security model needs to be chosen. The currently dominating one is the User-based Security Model (USB), but others are under development, for example in the ISMS WG. I don't think it would be appropriate to mandate in the MIDCOM MIB draft a specific way of achieving a sufficient level of security. Thanks, Juergen --On 05.07.07 13:20 +0200 Magnus Westerlund wrote: > Juergen Quittek skrev: >> Dear all, >> >> The MIDCOM MIB is progressing and currently under IESG review. >> Tim Polk made a comment that I would like to discuss here on this list. >> >> In the draft, we explicitly state hat a MIDCOM MIB implementation >> MUST support SNMPv3. However, we pass the responsibility of switching >> on SNMPv3 to the operator. The operator may still run SNMPv1 or SNMPv2 >> if security is provided otherwise: >> >> "Compliant MIDCOM MIB implementations MUST support SNMPv3 security >> services including data integrity, data origin authentication and >> data confidentiality. >> >> It is REQUIRED that the implementations support the security features >> as provided by the SNMPv3 framework. Specifically, the use of the >> User-based Security Model RFC 3414 [RFC3414] and the View- based >> Access Control Model RFC 3415 [RFC3415] is RECOMMENDED. >> >> It is then a customer/operator responsibility to ensure that the SNMP >> entity giving access to an instance of this MIB, is properly >> configured to give access to the objects only to those principals >> (users) that have legitimate rights to indeed GET or SET >> (change/create/delete) them." >> >> Now, Tim suggests to explicitly deprecate the use of (insecure) previous >> versions of SNMP, for example with a phrase like >> >> "Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. >> Instead it is RECOMMENDED to deploy SNMPv3 and to enable >> cryptographic security." >> >> Are there any opinions about adding such a phrase to the security >> considerations? >> > > To make sure I understand this correctly. Without SNMPv3 and its security functions the MIDCOM MIB will not reach the security requirements identified? If this is true, I think it is quite clear that MIDCOM MIB should only be used with SNMPv3. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM/M > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- -- 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 _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Fri Jul 06 13:11: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 1I6rKi-0008S1-OP; Fri, 06 Jul 2007 13:11:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6rKh-0008QT-Fy for midcom@ietf.org; Fri, 06 Jul 2007 13:11:03 -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 1I6rKd-0004tP-4G for midcom@ietf.org; Fri, 06 Jul 2007 13:11:03 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id EDC2B39A134; Fri, 6 Jul 2007 10:11:25 -0700 (PDT) From: Wes Hardaker To: Juergen Quittek Subject: Re: [midcom] security recommendations in MIDCOM MIB draft Organization: Sparta References: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D> <468CD3FB.4040203@ericsson.com> Date: Fri, 06 Jul 2007 10:11:25 -0700 In-Reply-To: (Juergen Quittek's message of "Thu, 05 Jul 2007 20:24:29 +0200") 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.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: midcom@ietf.org, Tim Polk X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org >>>>> "JQ" == Juergen Quittek writes: JQ> I don't think it would be appropriate to mandate in the MIDCOM MIB JQ> draft a specific way of achieving a sufficient level of security. I believe the wording I've seen doesn't do this. It uses RECOMMENDED and SHOULD to specify which particular implementation and deployment details are the best at this time (and maybe adding "at the time of this writing" is a good way forward as well). But, the important REQUIRED that should stay a REQUIRED is this one: It is REQUIRED that the implementations support the security features as provided by the SNMPv3 framework. Which merely says you must implement the security features in the framework. I believe the framework implies "a security model" and "an access control model", but not necessarily USM and VACM. The recommendations for USM and VACM come in the next sentence, which is relaxed to a RECOMMENDED to allow for other choices. It does also say that: In the draft, we explicitly state hat a MIDCOM MIB implementation MUST support SNMPv3. That's the only protocol-secure alternative at this time at least, and require implementations to support it makes sense. At this time. In the future if netconf or some other new protocol has the ability to access the MIDCOM MIB through a secure means, then it seems reasonable to let them not implement SNMPv3. At this time, however, that's not possible and SNMPv3 should be a MUST. Again, wording that allows for future deviations is a way around this. -- Wes Hardaker Sparta, Inc. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Thu Jul 12 11:12: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 1I90LI-0003xC-1J; Thu, 12 Jul 2007 11:12:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90LG-0003uX-7E for midcom@ietf.org; Thu, 12 Jul 2007 11:12:30 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I90LB-0005EV-Gd for midcom@ietf.org; Thu, 12 Jul 2007 11:12:30 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C33D9217FD; Thu, 12 Jul 2007 17:12:24 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-ae-469644d8c435 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A5E0E217ED; Thu, 12 Jul 2007 17:12:24 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 17:12:10 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 13:51:13 +0200 Message-ID: <469615B1.6040309@ericsson.com> Date: Thu, 12 Jul 2007 13:51:13 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Wes Hardaker Subject: Re: [midcom] security recommendations in MIDCOM MIB draft References: <6AFFE92CEE03A3E6C2E61771@753F3B888A9969457862729D> <468CD3FB.4040203@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2007 11:51:13.0538 (UTC) FILETIME=[F2692620:01C7C47A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: midcom@ietf.org, Tim Polk X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org Wes Hardaker skrev: >>>>>> "JQ" == Juergen Quittek writes: > > JQ> I don't think it would be appropriate to mandate in the MIDCOM MIB > JQ> draft a specific way of achieving a sufficient level of security. > > I believe the wording I've seen doesn't do this. It uses RECOMMENDED > and SHOULD to specify which particular implementation and deployment > details are the best at this time (and maybe adding "at the time of this > writing" is a good way forward as well). But, the important REQUIRED that > should stay a REQUIRED is this one: > > It is REQUIRED that the implementations support the security features > as provided by the SNMPv3 framework. > > Which merely says you must implement the security features in the > framework. I believe the framework implies "a security model" and "an > access control model", but not necessarily USM and VACM. The > recommendations for USM and VACM come in the next sentence, which is > relaxed to a RECOMMENDED to allow for other choices. > > It does also say that: > > In the draft, we explicitly state hat a MIDCOM MIB implementation > MUST support SNMPv3. > > That's the only protocol-secure alternative at this time at least, and > require implementations to support it makes sense. At this time. In > the future if netconf or some other new protocol has the ability to > access the MIDCOM MIB through a secure means, then it seems reasonable > to let them not implement SNMPv3. At this time, however, that's not > possible and SNMPv3 should be a MUST. Again, wording that allows for > future deviations is a way around this. Can we please come to consensus on this topic. And if there are text changes to implement the consensus, please provide them as RFC-editor notes to me. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Thu Jul 12 11:40: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 1I90md-00050l-0W; Thu, 12 Jul 2007 11:40:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90mc-0004xB-EO for midcom@ietf.org; Thu, 12 Jul 2007 11:40:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I90mX-0006MC-Mf for midcom@ietf.org; Thu, 12 Jul 2007 11:40:46 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2007 11:40:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAITnlUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,533,1175486400"; d="scan'208"; a="65010298:sNHT48915879514" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6CFeNWn011799; Thu, 12 Jul 2007 11:40:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6CFeFsa009751; Thu, 12 Jul 2007 15:40:23 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 11:40:18 -0400 Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Jul 2007 15:40:18 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 12 Jul 2007 11:40:15 -0400 Subject: Re: [midcom] security recommendations in MIDCOM MIB draft From: Melinda Shore To: Magnus Westerlund , Wes Hardaker Message-ID: Thread-Topic: [midcom] security recommendations in MIDCOM MIB draft Thread-Index: AcfEmvD1L783JDCOEdyO5AAKleNSdA== In-Reply-To: <469615B1.6040309@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Jul 2007 15:40:18.0778 (UTC) FILETIME=[F33653A0:01C7C49A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1109; t=1184254823; x=1185118823; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[midcom]=20security=20recommendations=20in=20MIDCOM=2 0MIB=20draft |Sender:=20 |To:=20Magnus=20Westerlund=20, =0A=20=20=2 0=20=20=20=20=20Wes=20Hardaker=20; bh=Tj/WPR+ildcrYWwd8OUhFh+ggdGNnrwwP0InVMa9lgM=; b=V+Zvv2bR5TjXC2Tj894whgV1elxl3Uedx2LWLikOUeuUMRtEf6MAzDJCzMtBJ/Ad2pktf64K P+ktNmi4fKrBWz48FRg4bqi34YDaf1SeG9kCwYQfTzxUcWfdXrGtyFjP; Authentication-Results: rtp-dkim-1; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: midcom@ietf.org, Tim Polk X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org On 7/12/07 7:51 AM, "Magnus Westerlund" wrote: > Can we please come to consensus on this topic. And if there are text > changes to implement the consensus, please provide them as RFC-editor > notes to me. The starting point is: requesting services from a middlebox must be secure. If that's to be done cryptographically, it requires SNMPv3. If it's not to be done cryptographically it suggests that the protocol is being run over a "secure" network. The latter was not considered acceptable by the responsible area director at the time that the work was ramping up, and it seems to me the question of whether or not SNMPv3 is to be required hinges on whether or not we can now permit an assumption of a "secure" network (for example, running it over an IPSec tunnel). It seems to me that if we can't assume the use of a secure network in some deployments then SNMPv3 has to be required, since sending firewall requests and NAT answers insecurely is obviously unacceptable. Do you think the assumption of a secure network would pass review? Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Fri Jul 13 09:57:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9LeE-00037t-T6; Fri, 13 Jul 2007 09:57:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9LeD-00036x-5X for midcom@ietf.org; Fri, 13 Jul 2007 09:57:29 -0400 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9LeC-0002oB-RO for midcom@ietf.org; Fri, 13 Jul 2007 09:57:29 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 609F62C3604; Fri, 13 Jul 2007 06:58:03 -0700 (PDT) From: Wes Hardaker To: Melinda Shore Subject: Re: [midcom] security recommendations in MIDCOM MIB draft Organization: Sparta References: Date: Fri, 13 Jul 2007 06:58:03 -0700 In-Reply-To: (Melinda Shore's message of "Thu, 12 Jul 2007 11:40:15 -0400") 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: midcom@ietf.org, Tim Polk , Wes Hardaker X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org >>>>> "MS" == Melinda Shore writes: MS> On 7/12/07 7:51 AM, "Magnus Westerlund" MS> wrote: >> Can we please come to consensus on this topic. And if there are text >> changes to implement the consensus, please provide them as RFC-editor >> notes to me. MS> The starting point is: requesting services from a middlebox must MS> be secure. If that's to be done cryptographically, it requires MS> SNMPv3. I think the text needs to require one method be available to operators consistently across all the devices they purchase. If they choose not to use it because they have other methods of securing their traffic they're comfortable with, then so be it. But at least they should be sure they can use one method. Something like: MIBCOM devices MUST implement SNMPv3 to allow for operators to rely on it's features in order to protect their traffic. Operators should use make use of SNMPv3, other protocols providing cryptographic protection or physical separation to to ensure MIBCOM traffic is secured. -- Wes Hardaker Sparta, Inc. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Fri Jul 13 10:39:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MJF-00061t-JJ; Fri, 13 Jul 2007 10:39:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MJC-0005z3-QY for midcom@ietf.org; Fri, 13 Jul 2007 10:39:50 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9MJ7-00048s-Kt for midcom@ietf.org; Fri, 13 Jul 2007 10:39:50 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2007 10:39:29 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGMrl0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,537,1175486400"; d="scan'208"; a="125982028:sNHT369795476" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6DEdS81015580; Fri, 13 Jul 2007 10:39:28 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6DEdF6o022143; Fri, 13 Jul 2007 14:39:28 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 10:39:15 -0400 Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Jul 2007 14:39:12 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 13 Jul 2007 10:39:10 -0400 Subject: Re: [midcom] security recommendations in MIDCOM MIB draft From: Melinda Shore To: Wes Hardaker Message-ID: Thread-Topic: [midcom] security recommendations in MIDCOM MIB draft Thread-Index: AcfFW5Lc0TXISDFOEdyO5AAKleNSdA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 14:39:16.0101 (UTC) FILETIME=[967FEB50:01C7C55B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=501; t=1184337568; x=1185201568; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[midcom]=20security=20recommendations=20in=20MIDCOM=2 0MIB=20draft |Sender:=20 |To:=20Wes=20Hardaker=20; bh=PAYO52b0rNvhFSsGAHBbtItlDrcXDQtsSoxiM1M8UmU=; b=TKQTMCX4rWKKamu7kIqsXyi/j5ym3YDylWCjYxzt4S6UdcFnBcjDdANve2RM9PU9pxrGNE3t uzvy1UBWS9KWQrKeFcE02gNBQh4iaa4r+BkI615Jvyjo2umkYPWDAHdX; Authentication-Results: rtp-dkim-2; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: midcom@ietf.org, Tim Polk X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org On 7/13/07 9:58 AM, "Wes Hardaker" wrote: > MIBCOM devices MUST implement SNMPv3 to allow for operators to rely on > it's features in order to protect their traffic. Operators should use > make use of SNMPv3, other protocols providing cryptographic protection > or physical separation to to ensure MIBCOM traffic is secured. Yes, that's pretty much where I am, too (note that it's actually "midcom," although "mibcom" is a pretty great portmanteau jobbie). Melinda _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom From midcom-bounces@ietf.org Fri Jul 13 15:56: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 1I9RFP-00006e-SD; Fri, 13 Jul 2007 15:56:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9RFO-0008Pi-2k for midcom@ietf.org; Fri, 13 Jul 2007 15:56:14 -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 1I9RFK-0005FQ-OS for midcom@ietf.org; Fri, 13 Jul 2007 15:56:14 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 7DBE02C3604; Fri, 13 Jul 2007 12:56:53 -0700 (PDT) From: Wes Hardaker To: Melinda Shore Subject: Re: [midcom] security recommendations in MIDCOM MIB draft Organization: Sparta References: Date: Fri, 13 Jul 2007 12:56:53 -0700 In-Reply-To: (Melinda Shore's message of "Fri, 13 Jul 2007 10:39:10 -0400") 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.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: midcom@ietf.org, Tim Polk , Wes Hardaker X-BeenThere: midcom@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: midcom.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: midcom-bounces@ietf.org >>>>> "MS" == Melinda Shore writes: MS> On 7/13/07 9:58 AM, "Wes Hardaker" wrote: >> MIBCOM devices MUST implement SNMPv3 to allow for operators to rely on >> it's features in order to protect their traffic. Operators should use >> make use of SNMPv3, other protocols providing cryptographic protection >> or physical separation to to ensure MIBCOM traffic is secured. MS> Yes, that's pretty much where I am, too (note that it's actually MS> "midcom," although "mibcom" is a pretty great portmanteau jobbie). Drat (I know that of course). You know I fixed that a few times before rearranging what I was saying again? You can tell what 3 letter acronym I type too often ;-) sigh... -- Wes Hardaker Sparta, Inc. _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom