Re: [Isms] Comments on the BTSMS proposal (fwd)

["David T. Perkins" <dperkins at dsperkins.com>]

HI,

oops, forgot to copy the list.

Regards,
/david t. perkins

---------- Forwarded message ----------
Date: Wed, 3 Aug 2005 03:38:41 -0700 (PDT)
From: David T. Perkins <dperkins at dsperkins.com>
To: Tom Petch <nwnetworks at dial.pipex.com>
Subject: Re: [Isms] Comments on the BTSMS proposal

HI,

On the question about what to put in the security param
field (and security type) when using encapsulated security -
I suggest either:
1) nothing - a zero length string (and the security model (SM)
   session ID would be determined by the "SSH session"; or
2) a session ID pair - the security model (SM) processing code
   would take the session ID pair and verify that the
   "SSH session" matches.

I assume that there is a "table" (conceptual) of SM sessions.
Each entry is identified by a session ID pair. Other info
in the entry would include:
 1) "encapsulation transport" info (for example, the info
    for the "SSH session")
 2) the security level provided by the encapsulating transport
    (the values would be authNoPriv and authPriv, but maybe
     also noAuthNoPriv)
 3) the SM identity and the security name of the session
     initiator
 4) possibly, the SM identity and security name of the
     session listner
 5) possibly, the VACM group name
 6) possibly, other values for "overrides" and other session
     related attributes.

When an "encapsulation transport" session is created, entries
would be added to the table. And when a session is terminated,
then entries are removed from the table.

I believe that the above approach works for and SSH "encapsulation
transport" session, and will also work for other session
based SMs. And I believe that it resolves the issue about
how the values from SNMP messages for flags to security level
is determined, and how to use the values in the security params
field.


On Wed, 3 Aug 2005, Tom Petch wrote:
>    <inline>
> Tom Petch
> 
> ----- Original Message -----
> From: "Juergen Schoenwaelder" <j.schoenwaelder at iu-bremen.de>
> To: "Tom Petch" <nwnetworks at dial.pipex.com>
> Cc: "EKR" <ekr at rtfm.com>; "Sam Hartman" <hartmans-ietf at mit.edu>; <isms at ietf.org>
> Sent: Tuesday, August 02, 2005 1:20 PM
> Subject: Re: [Isms] Comments on the BTSMS proposal
> 
> 
> > 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?
> >
> 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.
> 
> > > 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
> >
> 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

Regards,
/david t. perkins



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