Re: [Isms] #2: is server authentication a requirement that SNMP willrequire
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isms] #2: is server authentication a requirement that SNMP willrequire
On Mon, Oct 17, 2005 at 10:24:23AM -0700, Kaushik Narayan (kaushik) wrote:
> Although management applications have a human involved, the
> communication with the device might not happen in real time. Almost all
> changes to the network (configuration) and all collection (inventory,
> fault, performance) of data from the network happens at a time that is
> least disruptive to the network. Also there are cases wherein devices
> need to be pre-provisioned where the operator might not be in the loop
> when the sign-of-life shows up from the device.
>
> This does raise the requirement for the public keys being available to
> the NMS before communication to the device happens, this will have to be
> done manually for a start and X.509 certs support in SSH will reduce
> this administrative burden. Again these may well be seen outside the
> realm of SSHSM but I think we need to make sure that operators are aware
> of the administrative chores required to deploy SSHSM since deployment
> was a key barrier to entry for USM and a main reason why ISMS was
> created.
My primary goal is to enable secure SNMP in with zero additional costs
in environments where operators already use ssh as a means to securely
transport device configurations.
I am happy with any concrete proposal which makes ISMS work in a
broader context as long as it does not make reaching my primary goal
stated above more difficult.
So please write up what you think needs to be changed in the IDs to
support X.509 certs and then lets look at the cost/benefit ratio.
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.