On Thu, 2021-08-05 at 09:32 +0100, Stuart Henderson wrote: > On 2021/08/03 23:46, Martijn van Duren wrote: > > On Tue, 2021-08-03 at 21:58 +0100, Stuart Henderson wrote: > > > On 2021/08/03 22:07, Martijn van Duren wrote: > > > > On Tue, 2021-08-03 at 18:24 +0100, Stuart Henderson wrote: > > > > > On 2021/06/15 17:39, Stuart Henderson wrote: > > > > > > > Then again, I don't get the feeling many people use snmpd at this > > > > > > > time > > > > > > > and maybe it's a good moment to bite the bullet and go for safest > > > > > > > defaults possible at this time. But if that's the case I would > > > > > > > like to > > > > > > > follow up with a diff to changes the default auth to hmac-sha512, > > > > > > > because snmp drops trailing bytes of the result and enc to aes > > > > > > > instead > > > > > > > of des. > > > > > > > > > > > > This is the change that feels most likely to affect existing SNMPv3 > > > > > > users. > > > > > > Support in management software beyond aes/sha1 is a bit lacking and > > > > > > prone > > > > > > to incompatibility (I had issues with net-snmp and snmpd using > > > > > > hmac-sha256 > > > > > > though it seems it will work with hmac-sha512..) > > > > > > > > > > BTW, having updated a few machines now, I am finding the change to > > > > > sha2-256 by default to be a complete pain, especially considering that > > > > > /etc/examples/snmpd.conf uses "enc aes" but has no setting for auth > > > > > so relies on defaults for that.. > > > > > > > > > I can't do a lot with "a complete pain". > > > > > > > > Does something like the diff below make things more intuitive? If not, > > > > could you be a little more concrete? > > > > > > > > martijn@ > > > > > > > > Index: snmpd.conf > > > > =================================================================== > > > > RCS file: /cvs/src/etc/examples/snmpd.conf,v > > > > retrieving revision 1.1 > > > > diff -u -p -r1.1 snmpd.conf > > > > --- snmpd.conf 11 Jul 2014 21:20:10 -0000 1.1 > > > > +++ snmpd.conf 3 Aug 2021 20:05:53 -0000 > > > > @@ -18,7 +18,9 @@ system services 74 > > > > oid 1.3.6.1.4.1.30155.42.3.1 name testStringValue read-only string > > > > "Test" > > > > oid 1.3.6.1.4.1.30155.42.3.4 name testIntValue read-write integer 1 > > > > > > > > -# Enable SNMPv3 USM with authentication, encryption and two defined > > > > users > > > > -#seclevel enc > > > > -#user "user1" authkey "password123" enc aes enckey "321drowssap" > > > > -#user "user2" authkey "password456" enckey "654drowssap" > > > > +# Create two SNMPv3 USM users: > > > > +# User with default crypto values > > > > +#user "defaultuser" authkey "password123" enckey "321drowssap" > > > > +# User with backwards compatible crypto: > > > > +# Only enable and use when client absolutely can't deal with modern > > > > defaults. > > > > +#user "compatuser" authkey "password456" auth hmac-md5 enckey > > > > "654drowssap" enc des > > > > > > > > > > > > > > Given the lack of support for SHA2-256 in much management software until > > > recently AES+SHA is a pretty common configuration. And given the old > > > snmpd.conf > > > example I think that is often done by copying/editing so just "enc aes" > > > is there > > > with no auth setting. Wondering if that part might not have been such a > > > good > > > change and what anyone else thinks.. > > > > > I think that these management software applications should join 2016 and > > start > > implementing it and until then its just two or four minor keywords per user. > > But I'm not a heavy user of 3rd party mangement software. > > "Given the lack of support for SHA2-256 in much management software > _until recently_". What they do now is only relevant to new > configurations, it's what they did in the past when they were configured > that determines what people are using in existing config and whether > they'll have to reconfigure things to cope with the default changing.
Fair enough, I overlooked that part. However is it sane to rely on the defaults of application for a protocol that doesn't dynamically adapt to changes to the underlying crypto? > > Since even hmac-md5 is still AFAIK not considered unsafe (hmac is a > very different thing to using the algorithm for file integrity checks) > and there are clearly still issues with sha2-256 in SNMP I think we're > probably better off reverting that part of the defaults change and > go back to hmac-sha1. hmac-md5 might not be vulnerable, but snmp doesn't use pure hmac-*; in the case of md5 and sha1 it strips the result back to 12 bytes (for sha256 it's 24 bytes). I'm not saying that is insecure because of it; I haven't seen any research on the truncation of HMAC, but when combined with known problematic hashing algorithms it doesn't increase my confidence level. > > Diff for that below - it also fixes some text missed in the previous > change des->aes, A yes, missed that one. Thanks for spotting that. Regardless of anything else: that part is OK martijn@ > and adds explicit auth setting to examples/snmpd.conf. I think that making enc and auth explicit for all examples is a good idea. But the current phrasing might be a bit clutchy since seclevel now only applies to SNMPv3 and enc is now the default. > Another option might be to remove the default algorithms altogether, > requiring that they are specified explicitly instead. That would mean > users would still have to change config but then we don't run into > the situation again (it doesn't really seem sensible to rely on > a default for a protocol like this which is not 'agile' with respect > to algorithms). I agree with this sentiment to a degree. The downside is that people will need to decide themselves which algorithm to use and if any of them are known broken at some point it's harder to alert people of the issue. What about something like the phrasing below? It puts a heavy emphasis on not relying on the defaults (currently the auth and enc keyword aren't marked as optional in the syntax anyway), but keeps the current defaults as a strong hint on what is adviced. I also downscaled the example a little by setting seclevel auth, so it gives a little more substance to how seclevel can be used. Don't know if that's needed. > > Also note that the first time I suggested changing the defaults[0] I offered > > to help with getting perl's snmp into shape. That offer still stands with > > the > > same caveats. Similar for other open source software that I'm not aware of. > > > > [0] https://marc.info/?l=openbsd-tech&m=157226549212943&w=2 > > I think the bits which you were having trouble with for the Perl > implementation are the same bits that most of us would have trouble > with! I don't know where others would get stranded, just offering to help with the protocol bits if anyone with sufficient perl knowledge wants to step up. > Also Net-SNMP typically has quite slow update cycles so even > when it's written and landed there, it's likely to be some time before > it's in the hands of most users (and especially on the type of machine > used as management station, I don't find they are usually updated > very often). Maybe, but if we can fix it it could be worth having it as a local patch until upstream incorperates it. *shrugs* not a heavy user, so just throwing out some ideas that might help > btw monitoring-plugins' check_snmp is in C and just calls snmpget > with the user-supplied string in the -a flag. It's the manubulon-snmp > scripts which are written in perl and use Net::SNMP. Hence I was talking about check_snmp_* and not check_snmp. But fair enough, I could've been a little more explicit. martijn@ Index: snmpd.conf.5 =================================================================== RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v retrieving revision 1.50 diff -u -p -r1.50 snmpd.conf.5 --- snmpd.conf.5 20 Jun 2021 19:59:42 -0000 1.50 +++ snmpd.conf.5 6 Aug 2021 12:14:27 -0000 @@ -262,15 +262,16 @@ defined in the configuration file: .Op Ic enckey Ar key Ic enc Ar cipher .Xc Defines a known user. +.Pp The .Ic authkey keyword is required to specify the digest key used to authenticate messages. -If this keyword is omitted then authentication is disabled -for this user account. -Optionally the HMAC algorithm used for authentication can be specified. +If this keyword is omitted then authentication is disabled for this user +account. +The .Ar hmac -must be either +algorithm should be specified and must be either .Ic hmac-md5 , .Ic hmac-sha1 , .Ic hmac-sha224 , @@ -278,23 +279,21 @@ must be either .Ic hmac-sha384 , or .Ic hmac-sha512 . -If omitted the default is +If omitted the current default is .Ic hmac-sha256 . .Pp -With -.Ic enckey -the encryption key used to encrypt and decrypt messages for privacy is defined. -Without an +The .Ic enckey -specification the user account will neither accept encrypted incoming -messages nor will it encrypt outgoing messages. +keyword is required to specify the encryption key used to encrypt and decrypt +messages. +If this keyword is omitted then privacy is disabled for this user account. The .Ar enc -algorithm can be either -.Ic des +algorithm should be specified and must be either +.Ic des , or -.Ic aes -and defaults to +.Ic aes . +If omitted the current default is .Ic aes . .Pp Any user account that has encryption enabled requires authentication to @@ -343,19 +342,24 @@ oid 1.3.6.1.4.1.30155.42.1 name myName r oid 1.3.6.1.4.1.30155.42.2 name myStatus read-only integer 1 .Ed .Pp -The next example will enforce SNMPv3 with authenticated and encrypted +The next example will enforce SNMPv3 with authenticated and optionally encrypted communication and the user-based security model. The configuration defines two users, -the first one is using the +the first one is using the current default +.Ic hmac-sha256 +authentication algorithm and .Ic aes -encryption algorithm and the second one the default +encryption algorithm and the second one the +.Ic hmac-sha1 +and .Ic des -algorithm. +algorithm for legacy applications. .Bd -literal -offset indent -seclevel enc +listen on 127.0.0.1 +seclevel auth -user "hans" authkey "password123" enc aes enckey "321drowssap" -user "sophie" authkey "password456" enc des enckey "654drowssap" +user "hans" authkey "password123" auth hmac-sha256 enckey "321drowssap" enc aes +user "sophie" authkey "password456" auth hmac-sha1 enckey "654drowssap" enc des .Ed .Sh SEE ALSO .Xr snmp 1 , Index: snmpd.conf =================================================================== RCS file: /cvs/src/etc/examples/snmpd.conf,v retrieving revision 1.1 diff -u -p -r1.1 snmpd.conf --- snmpd.conf 11 Jul 2014 21:20:10 -0000 1.1 +++ snmpd.conf 6 Aug 2021 12:25:05 -0000 @@ -18,7 +18,8 @@ system services 74 oid 1.3.6.1.4.1.30155.42.3.1 name testStringValue read-only string "Test" oid 1.3.6.1.4.1.30155.42.3.4 name testIntValue read-write integer 1 -# Enable SNMPv3 USM with authentication, encryption and two defined users -#seclevel enc -#user "user1" authkey "password123" enc aes enckey "321drowssap" -#user "user2" authkey "password456" enckey "654drowssap" +# SNMPv3 USM users +#user "username" authkey "password123" auth hmac-sha256 enckey "321drowssap" enc aes +# User with backwards compatible crypto: +# Only enable and use when client absolutely can't deal with modern defaults. +#user "compatuser" authkey "password456" auth hmac-sha1 enckey "654drowssap" enc des
