Re: [Gen-art] [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
Juergen, Scott, Do you have enough feedback to declare WG consensus on this issue? Can we expect a new I-D before the pre-Dublin submission cutoff on Monday? Thanks and Regards, Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juergen Schoenwaelder Sent: Thursday, June 26, 2008 11:00 AM To: David Harrington Cc: 'General Area Review Team'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-disco very-02.txt On Thu, Jun 26, 2008 at 08:56:14AM +0800, David Harrington wrote: I think the benefit to operators is greater than the risk of giving the same benefit to attackers. I am not convinced this information is sensitive. I though security considerations should spell out potential risks so that people deploying technology can think about them and take an informed decision. How can we claim that we understand the benefit risk trade-offs? An an editor, I need to understand the WG consensus. I currently see three options on the table: a) document the potential information leakage associated with snmpEngineID discovery b) declare that this potential information leakage is a feature that is RECOMMENDED to support c) remove all discussion about this issue and simply stay silent, following the spirit of the USM standard /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/opsawg ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG] Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
On Thu, Jun 26, 2008 at 08:56:14AM +0800, David Harrington wrote: I think the benefit to operators is greater than the risk of giving the same benefit to attackers. I am not convinced this information is sensitive. I though security considerations should spell out potential risks so that people deploying technology can think about them and take an informed decision. How can we claim that we understand the benefit risk trade-offs? An an editor, I need to understand the WG consensus. I currently see three options on the table: a) document the potential information leakage associated with snmpEngineID discovery b) declare that this potential information leakage is a feature that is RECOMMENDED to support c) remove all discussion about this issue and simply stay silent, following the spirit of the USM standard /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
Speaking as a contributor I support option b) - (actually a+b) Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juergen Schoenwaelder Sent: Thursday, June 26, 2008 11:00 AM To: David Harrington Cc: 'General Area Review Team'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-disco very-02.txt On Thu, Jun 26, 2008 at 08:56:14AM +0800, David Harrington wrote: I think the benefit to operators is greater than the risk of giving the same benefit to attackers. I am not convinced this information is sensitive. I though security considerations should spell out potential risks so that people deploying technology can think about them and take an informed decision. How can we claim that we understand the benefit risk trade-offs? An an editor, I need to understand the WG consensus. I currently see three options on the table: a) document the potential information leakage associated with snmpEngineID discovery b) declare that this potential information leakage is a feature that is RECOMMENDED to support c) remove all discussion about this issue and simply stay silent, following the spirit of the USM standard /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ OPSAWG mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/opsawg ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
a+b dbh -Original Message- From: Juergen Schoenwaelder [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 4:00 PM To: David Harrington Cc: 'Randy Presuhn'; 'General Area Review Team'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-disco very-02.txt On Thu, Jun 26, 2008 at 08:56:14AM +0800, David Harrington wrote: I think the benefit to operators is greater than the risk of giving the same benefit to attackers. I am not convinced this information is sensitive. I though security considerations should spell out potential risks so that people deploying technology can think about them and take an informed decision. How can we claim that we understand the benefit risk trade-offs? An an editor, I need to understand the WG consensus. I currently see three options on the table: a) document the potential information leakage associated with snmpEngineID discovery b) declare that this potential information leakage is a feature that is RECOMMENDED to support c) remove all discussion about this issue and simply stay silent, following the spirit of the USM standard /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
Hi - From: Juergen Schoenwaelder [EMAIL PROTECTED] To: David Harrington [EMAIL PROTECTED] Cc: 'Randy Presuhn' [EMAIL PROTECTED]; 'General Area Review Team' gen-art@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 26, 2008 12:59 AM Subject: Re: [OPSAWG]Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt ... An an editor, I need to understand the WG consensus. I currently see three options on the table: a) document the potential information leakage associated with snmpEngineID discovery perhaps with a note that this information can get out in other ways b) declare that this potential information leakage is a feature that is RECOMMENDED to support I'd quibble with the to support - we're not talking about an implementation decision, but rather a deployment / usage decision, since the VACM configuration is what would determine how much leaks, beyond what the protocol itself exposes. c) remove all discussion about this issue and simply stay silent, following the spirit of the USM standard ... So I agree in spirit with a+b Randy ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG] Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt
Hi, Just a touch of perspective. I joined the SNMP community because SNMPv2-party was so secure, network management applications would no longer be able to do autodiscovery of SNMP-capable devices. The autodiscovery we wanted to be able to do included being able to detect what type of device it was we were talking to, so we better understood how to monitor and manage it. An attacker might benefit from knowing the type of device as well, so they can better understand how to attack it. When doing autodiscovery, we typically used sysObjectID, not snmpEngineID. I think the system group is still recommended to be accessible via noAuthNoPriv, so I can already learn most of what an snmpEngineID might reveal via other accessible objects. From my point of view, and I think it was consensus, the snmpEngineID is meant to be accessible via noAuthNoPriv so even SNMPv1/2c implementatins that implement this MIB could be identified independent of the currently-assigned IP address. (I know the reality is that all the application developers who identified nodes by IP address did not change their applications to use engineIDs, but that was part of the original purpose). I think the benefit to operators is greater than the risk of giving the same benefit to attackers. I am not convinced this information is sensitive. How about Making this accessible via noAuthNoPriv will benefit legitimate tools that try to algorithmically determine some basic information about the device. This information may also benefit attackers trying to fine-tune their attacks. The information exposed can usually be gotten through traffic analysis. For interoperability, we RECOMMEND making this information accessible using noAuthNoPriv. dbh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Randy Presuhn Sent: Thursday, June 26, 2008 6:07 AM To: General Area Review Team; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [OPSAWG] Gen-ARTLCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt Hi - From: Juergen Schoenwaelder [EMAIL PROTECTED] To: Randy Presuhn [EMAIL PROTECTED] Cc: General Area Review Team gen-art@ietf.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, June 25, 2008 1:02 PM Subject: Re: [OPSAWG] Gen-ART LCreviewofdraft-ietf-opsawg-snmp-engineid-discovery-02.txt ... The recommended VACM configuration in appendix A of RFC 3415 gives noAuthNoPriv read access to this information anyway. Not necessarily if you choose an initial-no-access-configuration (or I am misreading the A.1 item 5). True, though the initial-no-access-configuration is in some ways a pathological case. It begs the question of how the system *ever* comes to be managed. :-) I'm still not persuaded that SnmpEngineIDs should be regarded as sensitive information in general. With USM, they show up on the wire in the clear, perhaps revealing the most in the case of notifications. (msgAuthoritativeEngineID in the UsmSecurityParameters carried as msgSecurityParameters of SNMPv3Message) Randy ___ OPSAWG mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/opsawg ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
