RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?

Hi,

SNMPv3 has RFC2786 "Diffie-Hellman USM Key MIB" to automate key distribution. This approach has been in use in DOCSIS environments for a while now. I wouldn't call that nothing.

dbh

> -----Original Message-----
> From: Michael Thomas [mailto:[email protected]]
> Sent: Saturday, December 07, 2002 2:47 PM
> To: Chris Elliott
> Cc: Michael Thomas; Wijnen, Bert (Bert); Harrington, David;
> [email protected] (E-mail)
> Subject: RE: [midcom] SNMPv3 as MIDCOM protocol: Opinions?
> 
> 
> Chris Elliott writes:
>  > On Fri, 6 Dec 2002, Michael Thomas wrote:
>  > > I think you can factor out crypto of any stripe
>  > > because it's a requirement regardless of which
>  > > layer you implement it at.
>  > 
>  > I disagree--there are many applications for SNMP where 
> encryption isn't
>  > required. I don't think we'll see general use of 
> encryption for every
>  > frame inside Enterprise networks for many years. 
> Authentication is just
>  > catching on there and I belive that most Enterprises will 
> be quite happy,
>  > and rightly so, with just strong authentication for SNMP.
> 
> We're talking about Midcom specifically here. I
> assume that the Midcom requirements will have at
> the very least auth/authz and probably
> confidentiality requirements. As such, it doesn't
> really make a huge difference when you talk about
> performance whether its done at app layer ala
> SNMPv3 or transport/network as TLS/IPsec.
> 
>  > I think that making v3 easier to deploy for large environments by
>  > supporting external authentication servers 
> (Radius/Kerberos/Diameter/etc.)
>  > would go far toward convincing implementers to deploy it.
> 
> This is actually a distinct negative for SNMPv3:
> complete abdication of the problem of key
> distribution. With COPS and MEGACO you get TLS
> and/or IKE/KINK. SNMPv3 has nothing. For Midcom,
> I'd think this is a significant problem.
> 
> 	    Mike
>