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

["David Harrington" <[e-mail]>]

 

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

SNMP is deliberately built to work even when network connectivity is
impaired. There are a number of design decisions based on this
requirements, including having UDP as a mandatory-to-implement
transport, messages sizes that do not require fragmentation, and local
authentication. SNMP is designed to use a local authentication model
(two-party - the manager and agent) rather than a three-party
authentication model, because it might be impossible to reach the
third party due to network impairment. Any solution that requires a
third party authentication server, or a CA, or any other third-party
security functionality does not meet all the requirements of SNMP.

The USM model combined with the UDP/IPv4 transport model meets the
SNMP "reachability" requirements and the SNMP message security
requirements. We can **supplement** USM with secure transport models,
and centralized authentication and authorization, that are easier to
use but do not meet the "reachability" requirement, as long as USM and
UDP transport are still mandatory to implement.

I don't think we can break the ties to USM until we either 
1) design a new security model that provides this non-reliance on
third-parties at runtime, or
2) decide that the ability for SNMP to work when network connectivity
is impaired is no longer a requirement of SNMP design.

Dbh

> 
> > Another way to approach the problem would be to use a MIB
> > to store the transport&security information in a local 
> > configuration database addressable by 
> > securityName/securityModel/securityLevel and 
> > transportDomain/Address. Another RADIUS-specific MIB could 
> > contain RADIUS information, and that MIB could AUGMENT the 
> > transport&security MIB.
> 
> So, maybe that is one way to address the issue.  I'll need a 
> bit to time to
> absorb all this...
> 
> 
> 
> 
> _______________________________________________
> Isms mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/isms
> 



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