search

markabrahams / node-net-snmp

JavaScript implementation of the Simple Network Management Protocol (SNMP)
207 stars 97 forks source link

AES 256 option for privacy protocol #154

Closed gavinaiken closed 3 years ago

gavinaiken commented 3 years ago

Any plans to support this encryption option? I know it's somewhat non-standard but it seems quite common in the Cisco world, and net-snmp supports it from 5.8 onwards. http://net-snmp.sourceforge.net/wiki/index.php/Strong_Authentication_or_Encryption

markabrahams commented 3 years ago

Hi @gavinaiken - gotta be honest - implementing AES256 is not something I have a burning passion for. (1) If the IETF can't get AES256 standardised after 18 years, how am I meant to take this seriously? (2) Like 640 KB RAM, 128 bits should be enough for anybody, right? :-)

Would definitely accept a PR for this, or alternatively there may come a day when I find some motivation for it!

Is AES256 something you're using currently? Maybe I'll get inspired by a real-world use case :-)

gavinaiken commented 3 years ago

We are talking to someone about managing & monitoring a bunch of Cisco devices which are currently using AES256, and they don't want to step down to AE128. So yes it's a real world need.

I started looking into specs and so on this morning, slightly daunted by it but I might be able to have a stab at a PR for it if things progress, and you don't suddenly develop a burning desire to implement it ;)

markabrahams commented 3 years ago

In our obvious favour here is a working AES128 implementation, so hopefully the 256 variant won't deviate too much from that, and might not be too difficult?!? But yeah I hear ya - wading through the specs for this kinda stuff can be a little daunting! And testing is usually pretty hit-and-miss. Or more correctly, usually miss-miss-miss-miss-miss-miss-miss-miss-miss-miss-miss-HIT!!!

gavinaiken commented 3 years ago

Yep absolutely - since you have done all the hard work of the initial SNMP v3 implementation I was hoping that adding the extra option would be somewhat straightforward and therefore something I can tackle. I'm getting access to a device with this option configured so I do have something to test against which should help with all the miss-miss stuff...!

markabrahams commented 3 years ago

OK so I did have a look at this today, and it looks like a non-standard minefield. Some notes for any future implementer:

(1) My default testing Linux distribution at this time (Ubuntu 20.04 LTS) doesn't have AES256 support compiled into the provided Net-SNMP agent (version 5.8). This is a potential problem for other distributions as well. As well as a telling signal on how unpopular AES256 is. Confirmed by adding this to snmpd.conf: createUser test256 SHA "maybeitsok" AES256 "maybeitsok" and getting this error: Jan 10 23:29:26 hope snmpd[1310532]: /etc/snmp/snmpd.conf: line 20: Error: unknown privProtocol

(2) So if you're using Net-SNMP to test under such a distribution, you'll have to compile your own (version 5.8) with an "--enable-blumenthal-aes" configure option to get AES256 support. Would have been a useful note to add to this page: http://net-snmp.sourceforge.net/wiki/index.php/Strong_Authentication_or_Encryption

(3) The last IETF draft on the way to RFC 3826 that has AES256 in it (before it was removed) was: https://tools.ietf.org/html/draft-blumenthal-aes-usm-04

(4) However, Cisco have apparently not implemented key localization according to that ^^^ draft, but this one: https://tools.ietf.org/html/draft-reeder-snmpv3-usm-3desede-00 Reference: https://community.cisco.com/t5/network-management/snmpv3-with-aes256-not-working-in-cisco-routers/td-p/2864795

(5) To get Cisco compatibility with Net-SNMP, apparently you need "AES256C" not "AES256". Reference: https://sourceforge.net/p/net-snmp/mailman/message/36289830/

@gavinaiken - if you're testing newly developed library code directly against a Cisco device, the Net-SNMP stuff won't be relevant, but posted it just in case you or someone might be using Net-SNMP as a reference (I often do!)

gavinaiken commented 3 years ago

Thanks for the above info. I had also uncovered similar points but you have more details there than I had found.

Based on my research we talked again to the customer and have persuaded them of the non-standard nature of the AES256 encryption option, and as a result they have agreed to switch to standard AES128. So for now my need for this option has gone away. I suspect it will come up again, but we could close this issue for now and re-open it if so when I have to look into implementing it, or keep it open anyway if you like.

markabrahams commented 3 years ago

Yep - I would recommend exactly the same advice to customers contemplating AES256 for SNMP: don't do it! Would have been a great idea if it was standardised. No idea why it wasn't. Using it nowadays just limits your tool choice to a much narrower set that supports AES256. And Cisco going rogue-ish on the key localization didn't help matters any.

What I'll do is keep this issue open for a bit and see if there is any appetite out there for it. Ultimately it's still a valid feature, and who knows - it might get some surprise attention at some point?

markabrahams commented 3 years ago

So @gavinaiken - surprise attention! I got reading the two drafts on the train today, and it looked reasonably straight-forward. Ended up implementing it, and fortunately it indeed turned out to be pretty straight-forward. I've supported both key-localization variants:

Can't say it's very widely tested. I compiled a Net-SNMP with AES256 support and tested both algorithms against the Net-SNMP agent successfully. Nothing further than that, but the drafts are specific enough that it should work with Cisco, etc. devices.

This is on master now and published in version 3.4.0 of the npm.

gavinaiken commented 3 years ago

Wow that's impressive work, thank you! I'm slightly hesitant to ask our customer to test this against their devices given that we talked them out of using AES256... but it's great to know that it's there as an option, and if they do raise the question again we will give it a shot and let you know how it flies.

markabrahams commented 3 years ago

Yeah, no obligation at all - curiosity just got the better of me! I still think you've done the right thing by your customer - I still wouldn't recommend AES256 to anyone despite having just implemented it :-)

I'll close this as done now anyway - it's probably had as much testing as its going to for now :-)