RE: [Isms] SSHSM RADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt) submitted

Party #1: an snmp engine (e.g., a manager) 
Party #2: another snmp engine (e.g., an agent)
Party #3: anybody else not co-locaetd with #1 or #2 that needs to be
involved.

With USM, only #1 and #2 need to be able to reach each other.

dbh

> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com] 
> Sent: Thursday, March 15, 2007 11:16 AM
> To: David Harrington
> Cc: 'David B. Nelson'; isms@ietf.org
> Subject: Re: [Isms] SSHSM 
> RADIUSIntegrationdraft(draft-narayan-isms-sshsm-radius-01.txt)
>  submitted
> 
> David Harrington wrote:
> >  
> >
> >   
> >> The modularity of the current SNMP architecture seems to be 
> >> predicated upon
> >> the notion that passing around securityName is all that is 
> >> ever needed.
> >>     
> >
> > Roughly, that's true. 
> > The other model-dependent details should be hidden within 
> the specific
> > models.
> >
> >   
> >> That seems to be predicated on the notion that there is a local
> >> configuration store that contains useful information addressed by
> >> securityName. 
> >>     
> >
> > That's not quite true. 
> >
> > In fact, the goal of the modularity is to NOT share model-specific
> > information in the background through a LCD; that type of sharing
is
> > one of the problems that was so hard to fix in SNMPv2. We 
> had problems
> > because different operators/implementers want different
capabilities
> > for different reasons, and different SNMPv2 designs kept
overwriting
> > each other in the "global memory" that is the LCD. The modular
> > approach allowed us to specify model-specific LCDs (MIB modules),
> > modifiable only by the defining model, to prevent volatile 
> changes to
> > the data. 
> >
> >   
> >> That seems to imply USM or something very much 
> >> like it.  If
> >> we really want to break the ties to USM, we're going to need 
> >> to address this
> >> issue.
> >>     
> >
> > So far, I have not seen any proposals, either written or 
> just proposed
> > verbally, that provides a secure transport with all the security
> > characteristics of USM. A critical feature of USM, not 
> provided by SSH
> > or TLS or RADIUS proposals so far, is local authentication with NO
> > ties to a third party authenticator.
> >   
> 
> Well define 3rd party.  BEEP with TLS+SASL does the job quite
nicely, 
> but when one uses TLS one must of course take some care 
> regarding trust 
> anchors.  If you're doing CRL checks then you are probably going off

> box, unless YOU signed the cert.  But most people don't do 
> CRL checks at 
> all.
> 
> Eliot
> 

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