Subject: RE: [Isms] Mandatory-to-implement

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 27 Aug 2005 16:21:01 +0200

I would say that an implementation that wants to claim
compliance with SNMPv3 (STD62) MUST implement USM.
If such an implementation at the same time wants to
claim compliance with an ISMS developed standard, then
that standard can require that it MUST implement X (SSH
for example).

It is then up to the user/customer of such an SNMP implementation
as to what he/she wants to deploy.

Or so is my thinking.

Bert

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of David B Harrington
> Sent: Wednesday, August 24, 2005 23:52
> To: [email-masked]
> Subject: [Isms] Mandatory-to-implement
> 
> 
> Hi,
> 
> There has been some mention of mandatory-to-implement. I have concerns
> with what that means relative to SNMPv3. Is there intention in this WG
> to make the ISMS security model mandatory-to-implement for SNMPv3
> compliance? 
> 
> I think that would be a mistake, especially since the data gathering
> done by this WG has shown that there are no existing security
> infrastructures that meet the requirements of all (or even most)
> segments of the SNMP community.
> 
> SNMPv3 already has a mandatory-to-implement security model - USM -
> which meets a variety of requirements we haven't been discussing in
> the WG, and I am not convinced SSH can meet them - 
> 1) USM provides a solution that works even if no third party
> authentication server is accessible (say in a partially broken
> network), 
> 2) USM uses UDP, which reputedly can get through in some instances
> when TCP isn't viable, 
> 3) USM supports auto-discovery of SNMP-capable devices by NMS
> applications, and
> 4) USM is defined to be viable in a resource-contrained environment
> (that doesn't have such things as RADIUS support).
> 
> In addition, using a TCP-based transport presents opportunities that
> may not be backwards compatible, such as defining managed objects that
> can be passed via TCP, but wouldn't fit into a 484-byte UDP packet.
> The IETF SNMP community needs to decide whether a MIB module not
> compatible with the UDP transport mapping is allowed or not, and if it
> is, whether there is some boilerplate text that will need to included,
> and whether the MIB module needs to have some NMS-accessible object
> that identifies the need for TCP transport capabilities.
> 
> I'm fairly sure there are other issues we haven't been discussing.
> 
> I think it would be a mistake to think that the ISMS security model
> will be able to REPLACE USM as the mandatory-to-implement security
> model. 
> 
> Given that, we might want to consider a "coexistence" document or
> appendix that describes how to configure USM in a simple manner to
> permit these additional functions to be performed via the USM security
> model. Such an appendix might be appropriate for the Applicability
> Statements document, describing for which uses the SSH/RADIUS/TCP
> approach is applicable, and for which uses the USM/UDP approach is
> applicable. If we assume USM will always be available, new security
> models, including the ISMS security model, may not need to support all
> the requirements supported by USM.
> 
> David Harrington
> [email-masked]
> 
> 
> 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

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