Subject: Re: [Isms] Comments on the BTSMS proposal

From: "Tom Petch" <[email-masked]>
Date: Tue, 2 Aug 2005 11:48:19 +0200

Yes but ... <inline>

Tom Petch

----- Original Message -----
From: "Eric Rescorla" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Cc: "Tom Petch" <[email-masked]>; <[email-masked]>
Sent: Saturday, July 30, 2005 6:20 PM
Subject: Re: [Isms] Comments on the BTSMS proposal

> Sam Hartman <[email-masked]> writes:
>
> >>>>>> "Tom" == Tom Petch <[email-masked]> writes:
> >
> >     Tom> What the SNMPv3 architecture exposes is the level of security
> >     Tom> on the wire as (RFC3411 3.4.3. p.29) securityLevel - without
> >     Tom> authentication and without privacy (noAuthNoPriv) - with
> >     Tom> authentication but without privacy (authNoPriv) - with
> >     Tom> authentication and with privacy (authPriv)
> >
> > These seem like reasonable things for the encapsulation layer to
> > communicate to the rest of SNMP.
> >

Trouble is, as dbh has pointed out, there is no provision for this in the
architecture i.e. these securityLevel are requirements that the application
passes to the dispatcher to the message processing subsystem to the security
model which makes them happen on the wire and embeds flags to that effect in the
ASN.1 which are then extracted by the recipient engine.

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?).  None of this is in the
architecture or ASIs.  And recall that the PDU is ASN.1 so the transport layer
cannot readily set or reset flags in it, even in the space set aside for
security parms ie we are in a sense modifying the SNMPv3 PDU format by moving
the securityParms outside the ASN.1 SEQUENCE.

Even the idea of a securityModel in a sense has to be modified in that by the
time the securityModel is decoded from the ASN.1 by the recipient SNMP engine,
it is too late; the security has already been done in the transport layer.

> >
> > I anticipate no problem with doing this for Ssh, Beep, SASL, TLS or
> > DTLS.
>
> Agreed.
>
> Though it's worth noting that as far as I know all of these establish
> a single connection-level set of security parameters. This contrasts
> with the current USM, which lets you set per-message parameters.
>
> -Ekr

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Aug 2005 13:20:18 +0200

On Tue, Aug 02, 2005 at 11:48:19AM +0200, Tom Petch wrote:

> 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?).

The TMSM document discusses this in some detail. I fail to see why you
think it is necessary to touch the flags in the SNMP packet. Can you
please elaborate?

> None of this is in the architecture or ASIs.  And recall that the
> PDU is ASN.1 so the transport layer cannot readily set or reset
> flags in it, even in the space set aside for security parms ie we
> are in a sense modifying the SNMPv3 PDU format by moving the
> securityParms outside the ASN.1 SEQUENCE.

The TMSM document currently proposes to pass this information between
the pieces of the split security model via a cache referred to by a
cache reference. Again, I like to understand why you think it is
necessary to change the SNMPv3 PDU format.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 3 Aug 2005 10:57:31 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: "EKR" <[email-masked]>; "Sam Hartman" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 02, 2005 1:20 PM
Subject: Re: [Isms] Comments on the BTSMS proposal

> think it is necessary to touch the flags in the SNMP packet. Can you
The auth priv flags in the SNMP PDU reflect the request of the application and I
do not see these as being changed by SSH (not wanted, not feasible).  The
reality on the wire may be different; I think that that should be passed to the
SNMP engine but that that cannot be done in the SNMP PDU.  I see this as at best
a fudge of the architecture, perhaps even a change.  We no longer have in the
PDU information we should have.

> necessary to change the SNMPv3 PDU format.
Same argument.  The security model is expected to derive a securityName from the
msgSecurityParameters in the PDU.  When security is done at transport level,
this information never makes it into the SNMP PDU.  There are security
parameters but they are outside the remit of the SNMP engine and architecture.
Same conclusion.

I accept that this is a judgment call and you see it differently.  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" '.  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.

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.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Aug 2005 14:29:43 +0200

On Wed, Aug 03, 2005 at 10:57:31AM +0200, Tom Petch wrote:

> The auth priv flags in the SNMP PDU reflect the request of the
> application and I do not see these as being changed by SSH (not
> wanted, not feasible).  The reality on the wire may be different; I
> think that that should be passed to the SNMP engine but that that
> cannot be done in the SNMP PDU.  I see this as at best a fudge of
> the architecture, perhaps even a change.  We no longer have in the

I don't think the security parameters of the session must be exchanged
over the network and hence I don't thing they have to be in the PDU.

> Same argument.  The security model is expected to derive a
> securityName from the msgSecurityParameters in the PDU.  When
> security is done at transport level, this information never makes it
> into the SNMP PDU.  There are security parameters but they are
> outside the remit of the SNMP engine and architecture.  Same
> conclusion.

Please point to the RFC from which you derive this requirement for all
security models.

> I accept that this is a judgment call and you see it differently.  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" '.  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.
>
> dbh also says

I guess you have seen my recharter proposal and it in particular
allows for updates that describe how security state information is
passed around. I am actually not sure what your problem really is.

/js

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 3 Aug 2005 08:44:27 -0400

Hi Tom,

You're making assumptions about what is required in SNMPv3 processing,
and I don't agree with some of your assumptions.

> > > 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.

> 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
> 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

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.

> change to the architecture as defined in RFC3411 caused by a 

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.