That is a huge security hole. In fact knowing this, we will have to add some kind of extension to explicitely disallow Any packet that is not authenticated.
If we think about it, without this extension, anyone could set a mib when we were expecting to only accept authenticated packets. Vacm does not solve this either because anyone could spoof the user name in the un-authenticated packet. Adam -----Original Message----- From: Dave Shield [mailto:d.t.shi...@liverpool.ac.uk] Sent: Tuesday, February 16, 2010 4:13 AM To: Szudy Brett-CBS035 Cc: net-snmp-coders@lists.sourceforge.net Subject: Re: question on net-snmp privacy On 15 February 2010 23:48, Szudy Brett-CBS035 <brett.sz...@motorola.com> wrote: > It > looks like in the code that in a message received the sec level bits > only matter for validation when they are set --in other words, privacy > & auth protocols are only checked when the appropriate secLevel is set > (specifically in > usm_check_secLevel() - snmpusm.c). But if the bits are not set, then > the noAuthnoPriv message is accepted no matter what. Wes is the expert on SNMPv3 security, so he may want to chip in with corrections. But as far as I understand it - yes, that's correct. Remember that usm_check_secLevel() is only validating that the security settings for the message are appropriate for the given user. It's part of validating the message - which is only one aspect of granting access. For each given user, there will be an associated authentication protocol (which may be null) and an associated privacy protocol (which may also be null). So for any message involving that user, _if_ the message is encrypted, then it _must_ use that user's privacy protocol. (And if that user's privacy protocol is null, then that user cannot send/receive encrypted messages). Similarly, _if_ the message is authenticated, then it _must_ use that user's authentication protocol. (And if the auth protocol is null, the user cannot sent authenticated messages) If the message is not encrypted, then it doesn't matter which privacy protocol that particular user is configured for - there's no need to check this. (And similarly for authentication). A user is not forced to _always_ use the full strength of security that they are configured for. But if they do, then this must match their settings. > > It seems like it would defeat the purpose of a user setup for privacy > if the parsing/validation allowed noAuthnoPriv messages to be > validated successfully as well. I would expect a noAuthnoPriv message > sent to a user setup with SHA/AES to be rejected, but I'm seeing it accepted. It's accepted by the Security Model, which means that the message is regarded as valid. Whether that message is then _accepted_ is the role of the Access Control Model. The default access control configuration for SNMPv3 tends to require authNoPriv (or higher). So a noAuth message would pass the validation checks (USM), but then be rejected by the access control code (VACM). Does that make any sort of sense? [Wes - feel free to correct any errors in the above] Dave ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
