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
