RE: SNMPv3 security
"Fleischman, Eric" <[email protected]> Thu, 7 Aug 2003 15:02:59 -0700
| Newsgroups | gmane.ietf.snmpv3 |
|---|---|
| Message-ID | <5B58696DB20B9140AD20E0685C573A6402992DCB@xch-nw-09.nw.nos.boeing.com> |
>I have no idea why you don't think a simple application can't be written that >will update SNMP passphrases as often as you want to on your network. Yes it >will take protocol overhead time, but then so does renegotiating IPsec >session keys in IPsec. For that matter you can make it a simple policy on >either end of the control that automatically initiates a keychange when a >certain crypto quantia happens (up to after every other message, once for the >key exchange, once to get data). This is simple software that has nothing to >do with the underlying protocol - other than the underlying protocol allows >keys to be negotiated over it. Sending passwords out to thousands of devices on a small quantum basis consumes large amounts of bandwidth, which is very limited in many wireless systems. Automatically initiating key changes after the quantum expires would eliminate this objection, but it would need to be well thought out to eliminate possible coordination problems. I think that this is an appropriate topic for the SNMPv3 working group to address because, if it is not done here, then we would not have a consistent and interoperable solution spanning many implementations. >Now I want to know who you are talking to that says proprietary algorithms >are trusted more than publicly available ones. I know of no serious crypto >researcher that believes this. That said, you might be using other supplied >crypto for your custommers, if so, just plug the algorythm into your SNMPv3 >implementations and you are off to the races (I plugged in the AES candidates >many years ago for fun, guess what it worked w/out an RFC, and the eventual >AES RFC looks just like my implementation of AES did, of course I had to >throw out the other candidates) I never once used the word "proprietary". I did use the word "classified" once. Changing topics, I remain interested in any insights this group may care to offer me on approaches to supplement SNMPv3 security by protocols operating at a different layer. It does not appear that my postings have resonated with this group, perhaps because the group would have a tremendous lot of new work cut out for it should it admit to the validity of these concerns. Doubtlessly, everyone is already exceedingly busy, as I am, and so the prospect of additional work is unattractive. Thus, it does not appear that anything constructive will be achieved by continuing this discussion. I will try to privately respond to anyone who wishes to continue a private discussion with me, however. --Eric