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

["Kaushik Narayan \(kaushik\)" <[e-mail]>]

Hi David,

Please find my reply inline. 

<snipped>

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


<Kaushik> I think one of the issues being out here is that we still
require the securityName(s) to be defined on every SNMP engine (similar
to USM) and that creates a manageability issue. The reason
administrators deploy external authentication mechanisms such as RADIUS
is to avoid having to manage securityName(s) on every SNMP engine. 


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


<Kaushik>  It is very common in authentication systems to chain a set of
authentication methods, I can think a similar capability is what is
required. This is supported by PAM configuration that is typically used
by SSH implementations. Alternatively we can build this into the
security model and allow fallback to a local user database in case
reachability is not available.

regards,
   kaushik



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

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