Subject: RE: [Isms] Working Group Last Call - securityName

From: "Jeffrey Hutzelman" <[email-masked]>
Date: 16 Sep 2007 09:10:00 -0400

>From: "Wijnen, Bert \(Bert\)" <[email-masked]>
>
>Thanks Juergen. I understood it that way too.
>
>The issue is that in the SNMPv2c and SNMPv1 community-based security 
>models (in RFC3584) we have define that the securityLevel MUST always
>be set/assumed to be noAuthNoPriv. And so in the VACM tables, one would
>probably NEVER allow write access to any MIB object instances.

I don't know about that.  People used those versions for years before SNMPv3 came along, and surely some of them must have permitted some write access.  It is possible to have a deployment in which granting write access is safe even for noauthnopriv.  For example, you could have a network in which all hosts are trusted.

>So this SNMPv1/v2c over SSH does not help then, does it?

Sure it does.  You could configure an agent such that ssh is the only permitted transport.

>I understand, that in order to fix it, we need to update RFC3584
>I guess. Such is life. It would have been nice if this would have
>come sort of automatic.

I think it does, to a limited extent.  And of course, there's nothing to prevent implementers from doing something we haven't specified that breaks the abstraction.  One option that comes to mind is to reject SNMPv2c messsages received over ssh unless the community string is the same as the ssh username, and for such messages which are not rejected, set the securityLevel higher.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms