Re: [Isms] Comments on the BTSMS proposal

["Tom Petch" <nwnetworks at dial.pipex.com>]

David

Thank you for your comments; I am glad we are in the same ballpark about small
changes to the RFC3411 Architecture.  I think recognition of this is rather
important.

The only minor point I would like to add to is about including the actual
security level in the information passed to the engine.  I have no problem with
the requested security level being handled as it is.  I cannot currently produce
a compelling reason why we need the actual security level when we are using SSH
security at the transport layer but have a nagging feeling we will, perhaps for
security audits, logs, exploitation by the engine itself (eg it knows it has
priv and so can afford to send information it otherwise would not),.... so I
would rather see it passed betwen transport and engine if it reasonably can,
rather than find out later it is needed and we don't have it.

If those on this list with a security background say that knowing the actual
security level used (authentication, encryption, integrity - not the particular
algorithm) in a data transfer is not needed for security purposes, I would feel
reassured (ie would shut up about it). eg if a security breach is detected, does
it matter that we do not know at the application level whether the message was
encrypted or not?

Tom Petch

----- Original Message -----
From: "David B Harrington" <ietfdbh at comcast.net>
To: "'Tom Petch'" <nwnetworks at dial.pipex.com>; <j.schoenwaelder at iu-bremen.de>
Cc: <isms at ietf.org>
Sent: Wednesday, August 03, 2005 2:44 PM
Subject: RE: [Isms] Comments on the BTSMS proposal


> Hi Tom,
>
> You're making assumptions about what is required in SNMPv3 processing,
> and I don't agree with some of your assumptions.
>
> > > > When security is outside SNMP, at the transport layer, then
> > > > somewhere in the SNMP engine needs to tell TMSM or
> > transport what is
> > > > wanted, which then says yes or no; and the level on the wire may
> > > > exceed what is requested (eg authPriv v authNoPriv) which, IMHO,
> > > > needs recording in the packet (where?) and needs passing up the
> > > > stack of the recipient (how?).
>
> Why does this need to be included in the PDU? When I send an SNMP
> message (or a FTP packet, or ...) over an IPSec network, should the
> PDU be modified to show what securitylevel IPSec used?
>
> There are two reasons msgflags are passed in SNMPv3 messages.
>
> The first reason is to ensure that the information is handled by the
> recipient with the same concern for data sensitivity. I don't see any
> problem with providing stronger security than requested. What happens
> if I use SNMPv3 noAuthNoPriv over a VPN that does authentication and
> encryption? Do we need to change the msgFlags in the SNMP message?
> What happens if we use USM AuthPriv and the message passes over a
> nonsecure network and a VPN that does authentication and encryption?
> The minimum security is still AuthPriv, regardless of the maximum
> level of security applied in transit, or the lack of security applied
> in transit.
>
> "The authFlag and privFlag portions of the msgFlags field are set by
>    the sender to indicate the securityLevel that was applied to the
>    message before it was sent on the wire. "
>
> If you want to argue for a literal interpretation of the requirements,
> then the sender who relies on a transport layer to provide auth and
> priv should set the message flags to noAuthNoPriv, since that's what
> was applied to the message before it was sent on the wire (i.e. sent
> to the lower layer in the communications stack).
>
> Obviously, the engine requests a securityLevel from the underlying
> transport and ensures that the transport protocol agrees to meet its
> minimum criteria before sending it on the wire. All the engine can do
> is assert that (at least) this level of security has been applied.
>
> The second reason msgFlags is included in the message is an artifact
> of USM security - msgFlags alerts the recipient's USM model about
> which lookups they need to do in the USM MIB to get the shared keys
> for authentication and encryption. SSH, TLS, SAL all have different
> mechanisms for determining how to get shared keys or other
> credentials; they don't need this passed in the SNMP message.
>
> > Same argument.  The security model is expected to derive a
> > securityName from the
> > msgSecurityParameters in the PDU.
>
> The USM security model does it this way, but this is not an
> architectural requirement.
>
> From RFC3411:
>    The transformation of model-dependent security IDs into
> securityNames
>    and vice versa is the responsibility of the relevant Security
> Model.
>
> From RFC3412:
> 6.6.  msgSecurityParameters
>
>    The msgSecurityParameters field of the SNMPv3 Message is used for
>    communication between the Security Model modules in the sending and
>    receiving SNMP engines.  The data in the msgSecurityParameters
> field
>    is used exclusively by the Security Model, and the contents and
>    format of the data is defined by the Security Model.  This OCTET
>    STRING is not interpreted by the v3MP, but is passed to the local
>    implementation of the Security Model indicated by the
>    msgSecurityModel field in the message.
>
>
> > I was
> > interested to be reminded by dbh of the SNMP 'WG consensus
> > requirements such as
> > "the mandatory-to-implement models should have no
> > dependencies on external
> > protocols" '.
>
> Yes, because one purpose of SNMP is to troubleshoot broken networks,
> and the mandatory-to-implement protocol needs to work (if possible)
> even when the network is broken; having a dependency on an external
> authentication server increases the likelihood that SNMP will not
> function when the network is broken.
>
> While desirable, (I believe) this is not a requirement for
> supplemental security models, since USM can provide the
> troubleshooting capability. Some have argued that USM should not be
> replaced by a new security model; if that occurs, the replacement
> security model would be faced with this requirement.
>
> > We are now introducing a greater dependence on external
> > protocols - SSH et al - albeit for non-mandatory models and
> > for me, that puts
> > the architecture under strain.
>
> It in no way puts the architecture under strain. It has long been
> considered a desirable thing to tie into existing security
> infrastructure, and the architecture was designed to allow different
> security models to be developed that could utilize various approaches
> to security. If you can locate the old SNMPv2 archives, you can see
> the debates about how to leverage IPSec to secure SNMP. This was
> definitely recognized as a potential approach to security.
>
> I will agree we didn't do a very good at providing a layered
> architecture so we could utilize lower layers for security easily, but
> the use of external security definitely was considered. Note that the
> SNMPv3 architecture reached standards track before most of the
> transport layer security protocols (and SecSH hasn't gotten there
> yet); it's hard to plan the architectural fit with external protocols
> still in development.
>
> >
> > dbh also says
> > 'If the TMSM is going to pass transport information from the
> transport
> > mapping to the SM subsystem, either through a cache or an ASI
> > parameter, we need to standardize how this is done, how it affects
> > existing models and MIB modules, and how to document these changes
> > within the IETF.'
> >
> > Again, a matter of judgment, but I see this as close to
> > suggesting a small
> > change to the architecture as defined in RFC3411 caused by a
> > dependency on
> > external protocols.
>
> I don't see this as close to suggesting a small change in the
> architecture as defined in RFC3411; I see this as definitely
> suggesting a small change to the architecture as defined in RFC3411,
> but in a way that is consistent with the precedents of the
> architecture defined in RFC3411.
>
> This change is required because the RFC3411 ASIs were knowingly made
> inadequate to support transport security.  There was a political
> battle in the SNMPv2/v3 WGs over whether SNMPv2/v3 should support the
> use of source address as an authentication mechanism. Despite its
> popularity with operators, and the strong insistence of one of the
> "major players", given the ease of address spoofing, the WGs decided
> to not pass the transport info into the security subsystem, and to not
> allow the transport mapping to provide authentication, to encourage
> operators to use the stronger authenticatino mechanisms supported by
> USM and other expected security models. This political decision has
> come back to haunt us.
>
> >
> >
> > Tom Petch
> >


_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms